Microservices are all the rage these days. But are they really a new idea?
If you were around and kicking in the 2000s, you may also remember when Service-Oriented Architecture, or SOA, was the cool way to design apps. In some respects, SOA is very similar to microservices.
But it would be a mistake to conflate SOA with microservices. Yes, the design and philosophy behind each architecture approach share some traits, but SOA and microservices are fundamentally different in other key ways. Below, I explain what these two approaches to software architecture share in common, and what sets them fundamentally apart.
What’s the Same?
Let’s begin by talking about the similarities between the two architectures. Both SOA and microservices allow a complex workload to be broken down into smaller, more manageable, and somewhat independent pieces. Let me give you an example that is not based on the software world.
Today, I spent the better part of the afternoon mowing the lawn. Although mowing the lawn might seem like a completely straightforward task, there are a number of smaller tasks that have to be performed. These smaller tasks might include things like putting fuel into the lawn mower, starting the lawn mower, and pushing the mower. Each of these small individual tasks have to be performed in order to complete the bigger task of mowing the lawn. If we were to develop a software application for mowing the lawn (not that it would actually be possible), each of the subtasks might be broken out into a SOA component or into a microservice.
Given the fact that dividing a workload into smaller parts could be handled by either SOA or microservices, it is hardly surprising that there are those who insist that there is absolutely no difference between the two architectures. In fact, the topic of whether SOA and microservices are different architectures (or two different names for the same thing) has been hotly debated on more than one Internet message board. But there are actually some crucial differences between the two architectures, and these differences play into the ways in which the architectures should be used.
I am assuming that most developers are probably already familiar with SOA, but I want to give a brief description of the architecture for the benefit of anyone who might not be familiar with the finer points of service-oriented architectures.
The SOA architecture is based on the idea that the components that make up an application do not necessarily have to be running on the same box. The components can communicate with one another through a network protocol (although a variety of communication protocols can be used).
Because SOA components communicate with one another using a protocol, they depend on an Enterprise Service Bus (ESB) to facilitate communications between the individual services.
In contrast, microservices are individual services that are able to communicate with one another through APIs. One thing that makes microservices different from SOA components is that microservices are truly independent of one another. It might be possible, for example, to upgrade a microservice without upgrading any of the other application components. Similarly, it is possible to shut down microservices that are not currently being used,without impacting the microservices that continue to run.
Individual microservices often run in containers. Even so, it is possible to look to the Windows Server operating system and Microsoft Exchange Server for an example of how microservices behave.
These services are actually classified as monolithic services, because they are developed and deployed as a single unit. In contrast, microservices are developed independently, and can even be built using different tools and different languages, so long as the microservices conform to the standards set forth by the API. The services that make up Exchange Server can give us a glimpse into the way that microservices behave.
Each service that makes up Exchange Server performs a specific function. Depending on how Exchange Server is configured, you might not necessarily need every service to be running. It is possible to shut down unused services without impacting Exchange Server as a whole.
Microservices tend to be far more granular than monolithic services. They do one thing, and do it well. Generally speaking, there is physical separation between microservices. Whereas the Exchange Server services might all run on a single server, microservices often run in containers. Microservices also tend to be easier to develop and test than monolithic services, because they only perform a single function, and are designed to work independently.
About the Author
Brien Posey is a Microsoft MVP with over two decades of IT experience. Prior to becoming a freelance tech author, Posey was CIO for a national chain of hospitals and healthcare facilities. He also served as a network engineer for the United States Department of Defense at Fort Knox, and has worked as a network administrator for some of the largest insurance companies in America. In addition to Posey’s continued work in IT, he is in his third year of training as a commercial scientist-astronaut candidate.
We’re hiring! Check out the careers page for open positions in Amsterdam, London and San Francisco.
As usual, if you want to stay in the loop follow us on twitter @wercker or hop on our public slack channel. If it’s your first time using Wercker, be sure to tweet out your #greenbuilds, and we’ll send you some swag!