The history and origins of microservices are a continuing effort to provide better communication between different platforms, greater simplicity, and more user-friendly systems. Microservices are typically thought of as a software development technique which organizes an application as a group of loosely coupled services. It is, however, any kind of small service which interacts with other services to operate a software application. Microservices architecture uses services that are fine-grained and protocols that are lightweight.

Dr. Peter Rodgers used the term “Micro-Web-Services” in 2005 during a presentation on cloud computing. Rodgers argued against conventional thinking and promoted software components supporting micro-web-services. In the presentation, he established a functional model of microservices which eventually became a reality. Explaining how complex service-assemblies work behind simple URI interfaces, he suggested, “Any service, at any granularity, can be exposed.” He went on to describe how a well-organized micro-web-services platform “applies the underlying architectural principles of the Web and REST services together with Unix-like scheduling and pipelines to provide radical flexibility and improved simplicity in service-oriented architectures.”

Enterprise Java Beans to Service Oriented Architecture

IBM released enterprise java bean (EJB) in 1997. It was one of the earliest efforts to provide “small” service or microservice working with web-related software components. EJBs were designed to allow developers to write code in a standardized way and automatically handle many common issues. They were the first specification that offered an easier way to “encapsulate and re-use” business logic for enterprise Java applications.

However, there were still frustrating issues with the use of enterprise java beans. They could only be used while working in Java and could not communicate with other systems. They were still complicated, not terribly user-friendly, and extremely difficult to debug. The limitation of working only with Java and not being able to extend communications to other platforms brought about the solution known as service-oriented architecture (SOA) which became the next evolutionary step for the existence of microservices.

A service, in SOA context, is a “self-contained” software program performing a specific task. SOA allows these services to communicate with one another across different languages and platforms by using a loose coupling system. (Loose coupling continues to be used for web services.) Loose coupling describes the ability of the client to maintain independence from the service it requires. Two platforms can communicate even if they are not closely related. This is accomplished through the use of a special interface capable of translating the data. (Some consider microservices to be a subdivision of SOA, but SOA and microservices each have their own strengths and weaknesses, and can be categorized separate systems.) SOA services are built primarily on simple object access protocol.

Simple Object Access Protocol (SOAP)

SOAP was essential to the development of microservices. The philosophy “Do the Simplest Thing Possible” is at the heart of SOAP, released in 1999 by Microsoft. SOAP can be described as a way to utilize object methods using HTTP (or hypertext transfer protocol). It is a way to transfer small amounts of information, or messages, over the Internet. These messages use an XML format and are usually sent using HTTP. The use of HTTP, a protocol employed by Web pages, has the advantage of bypassing most network firewalls. (Firewalls typically don’t block HTTP traffic, allowing most SOAP messages to pass through with no problems.) This solution took advantage of two trends in the computing world during the early 2000s:

• The growing trend for using HTTP in corporate networks.
• The support provided by automatic logging and debugging mechanisms for text-based Internet communications.

SOAP messages are contained within an “envelope,” which includes a body and a header. The header may contain the message’s ID and the sending date, while the body holds the actual message. SOAP messages each use the same format, making them compatible with a variety of different protocols and operating systems. For instance, a SOAP message can be sent to a Unix-based web server from a Windows XP computer without concerns the message will be distorted. The Unix server can then open the file or redirect this message to the most appropriate location.

Though SOAP does have its own strengths, it does not scale well, nor does it support error handling, two features microservices perform automatically. Additionally, though SOA and SOAP started off simply enough, efforts to expand their usefulness – by adding layers – made them clumsy and difficult to work with.

SOA continues to be used used as a basic tool, and there are continuing efforts to make SOAP more efficient.

REST

As a whole, the computer tech community began to reject the concepts required by SOAP in roughly 2005 through 2007. They shifted toward Representational State Transfer (REST) in 2008 through 2010, as it gained in popularity. This architectural style defines constraints that are used to create web services and supports use of the cloud to develop software apps. Web services conforming to REST’s architectural style are referred to as RESTful Web services, and such services support interoperability between computer systems communicating through the Internet.

REST using HTTP is a very common practice in modern microservices development. A RESTful API describes an application program interface (API) using HTTP requests to POST, GET, PUT, and DELETE data. APIs are portable, scalable, easy-to-use, and easy to integrate. A website’s API uses code that supports the communication between two software programs.

Roy Fielding worked on developing the REST architectural style from 1996 to1999, and he discussed it during his 2000 PhD dissertation, Architectural Styles and the Design of Network-based Software Architectures. Fielding was not an advocate for rigidness, but for flexibility. REST’s primary theme stated that for each portion of data, the URL stays the same, but depending on the method used, the operation would change. For example, ordering “http://theirsite.com/posts” to GET may return a list of posts, but a POST order to the same URL would create a new post.Asked about the development of REST, Fielding responded,

“Throughout the HTTP standardization process, I was called on to defend the design choices of the Web. That is an extremely difficult thing to do within a process that accepts proposals from anyone on a topic that was rapidly becoming the center of an entire industry. I had comments from well over 500 developers, many of whom were distinguished engineers with decades of experience, and I had to explain everything from the most abstract notions of Web interaction to the finest details of HTTP syntax. That process honed my model down to a core set of principles, properties, and constraints that are now called REST.”

REST is often used with microservices.

Microservices Become a Reality

In May, 2011, people in a workshop near Venice for software architects used the word “microservice” to describe an architectural style several of them had recently explored. In May, 2012, they decided microservices was the most appropriate name for the work they were doing and formally adopted it. They had been experimenting with building continuously deployed systems, while incorporating the DevOps philosophy. This form of architecture quickly gained popularity.

DevOps is a series of software development practices which combine development (Dev) and operations (Ops) in an effort to shorten the development life cycle. Microservices architecture effectively brings both departments together, allowing them to produce applications that are more reliable and have better performance and greater resilience. As a process, it allows developers to provide updates more often, ensuring the software stays aligned with the business’s objectives. Microservices architectures have quickly become the standard for DevOps. These services are especially useful for continuously releasing software.

The benefits of microservices architecture include:

• Support: Microservices have become popular and are supported by many technology and cloud vendors. With the combination of efficiency and support, many businesses are adopting microservices because of their easy availability.
• Language Independence: Microservices can work with almost any technology with only minor tweaks.
• DevOps: The architecture of microservices are designed to support DevOps philosophies. In turn, DevOps helps guide the development of applications based on microservices.
• Resources Are Not Shared: Earlier service architecture designs focused on shared resources. Shared resources tended to make the work unnecessarily complicated. The architectural design of microservices allows each service to be encapsulated. This provides developers with the ability to tweak the microservices without influencing other services.

The Future of Microservices

The Cloud Microservices Market Research Report of February of 2020 has predicted the size of the global microservice architecture market will increase with a compound annual growth rate of 21.37 percent from 2019 to 2026 with the market reaching a value to $3.1 billion by 2026.