There is a lot of excitement and information around Microservices these days. But some have commented that much of the literature seems to be saying the same things that we have been saying about Service Oriented Architecture (SOA) for years. Much of the information is about related technologies (such as automated build, testing, and deployments) which are commonly used in Microservices projects, but which are not necessarily Microservices specific. This all leads to confusion and questions about just what is Microservices and why is it different (or better) than other approaches? I’ll attempt to clearly and succinctly answer those questions. To answer in this short space, I’ll need to make some generalizations and to not get too deep, but the important thing here are the concepts and not the details. So here is my take on the topic, tell me if it works for you or not.
Microservices is an evolution of SOA concepts that can provide additional benefits to adopting organizations. The benefit of Microservices over “traditional” SOA is speed and agility for making changes, and the ability to make changes with less overall cost and less impact on the existing infrastructure. Microservices involves a different approach, as well as some different uses of technology.
SOA is generally based upon WSDLs for defining interfaces. A WSDL is normally tied to an enterprise-shared data model XSD that can have complex hierarchies and relationships of data structures. A WSDL defines a service that can have many operations (sometimes called methods). For example, a customer service might define dozens of operations to lookup or modify data about a customer. There also might be a billing service that also defines dozens of operations, which also uses some of the same customer schema definitions from a shared corporate data model. Each service is deployed as a single program, or perhaps a single engine, like a JVM that hosts the service. In the enterprise SOA implementation, there might be hundreds of client programs that connect to the customer and billing services.
So what happens when you want to make a change to the data model? For example, let’s say we want to add an attribute called “elevation,” which is used by a location data structure, which is used in an address data structure, which is used in a few of the operations for the two services. But the elevation attribute may only be needed for one specific operation in the customer service.
The impact of this change can spread like wildfire through the SOA. A lot of the impacts are to components that have no interest in or use of the changed item. Any change to the data structure implies a WSDL change. All of the hundreds of client programs need to incorporate the new WSDL, even if they are not interested in the elevation attribute, even if the operations that they call do not use the address data structure. Incorporating a new WSDL requires a compile, rebuild, retest, and redeployment for the customer and billing services, as well as the hundreds of clients. Because all of the dozens of operations in the customer and billing service are bundled and deployed as a single executable, the entire service must be regression tested. Because the service has been changed, all of the clients of the service should be regression tested, or at least some lesser amount of testing to make sure there are no impacts. Because of this potential huge impact, organizations will hold off on making individual changes, and instead will bundle the changes into release cycles where everything gets a full regression test. A full regression test can require significant time, labor, and associated cost. In some large organizations the release cycle may only occur a few times a year.
From an operations perspective, what happens if there is a need to make a deployment change related to one of the operations for the service? That means the whole service must go offline, which means the hundreds of clients will experience an outage, even if they do not make use of the specific operation that is being changed. Because of the extent and impact of the outage, organizations are reluctant to make changes, and will only make changes in a few very small windows of time each month.
This description of SOA does not sound inexpensive, fast or agile!
What’s different about Microservices? In Microservices, each operation (or method) is developed separately. The single customer SOA service described above would be implemented separately as dozens of separate Microservices. No formal interface is defined, or perhaps a very flat and simple interface is defined. No central data model is defined with complex schema hierarchies and structures. Well, perhaps a common data dictionary may be defined, but that is not programmatically enforced on each Microservice; each Microservice is free to independently incorporate changes only when needed. Each Microservice can be independently deployed, stopped, or restarted. In many situations there is a common platform that executes the individual Microservices. For example, in TIBCO BusinessWorks 6, each Microservice is a deployment archive that can be independently deployed and managed on an AppNode (i.e. a JVM).
So what happens when there is a change? Consider the addition of the elevation attribute described above. With Microservices, we would find the specific interface that actually needs the new attribute, and only change that particular interface. And, because it’s so easy to change and deploy Microservices, we might just implement a new flavor of the interface and leave the prior interface untouched.
What does this mean to the organization? It means that changes can be implemented without rebuilding and retesting required for components that have no interest in the changes. It means that changes can be made and implemented with a fraction of the impact and cost. It means that the Microservices infrastructure can be fast, agile, and responsive—which is what the business wants.
I know that many of my technical colleagues are saying, wait a minute, this is not so much about technology and is mostly about approach. We could (can now) use our existing tools and SOAP to implement Microservices as described above (if we just did it differently). And there are lots of benefits from common data models and fully defined interfaces in WSDLs that we are throwing out. In many cases, these comments are absolutely true, however if you look closely at the capabilities of the existing tools, you may find that they are more suited for traditional SOA than a Microservices approach.
Others will point out that we have struggled with SOA governance and change management, and Microservices sounds like more components to manage with a bigger and more complex configuration management task. Actually, Microservices simplifies the configuration management task due to the fact that there are fewer dependencies and changes can be made independently with fewer impacts to existing systems. Modern tools like BusinessWorks 6 and API Exchange also have built-in implementations of the Swagger REST API management system, which provides automated and online capabilities for Microservices documentation, discovery, and integration testing, which further simplifies the API management task.
In the past we haven’t implemented in a Microservices style in most cases, probably because our thinking and the tools lead us to implementing Big Services (Macroservices?). BusinessWorks 6 and API Exchange provide tools and structure that support Microservices, but they can certainly also be used to build Macroservices. This is good because the Microservice approach is not the best way for every situation; there are situations where the older style of larger service is still the best way to go. Having powerful tools that allow the developer to choose on a case-by-case basis is much better than having separate tools for each style; it’s easier to use and manage the different types of source code in a single platform.
Distributed Applications are still better than Monolithic Applications. SOA (and an Enterprise Service Bus) is still significantly better than point-to-point integration (which leads to “Integration Spaghetti”). Microservices can provide even more benefits in the right situations. Yes, there are lots of shades of grey here, and there are many viewpoints and options—which is why there is so much confusion over this Microservices topic, and that’s why we need to have the discussion with our customers and stakeholders to explain it. Another opportunity to have a thoughtful (thought leadership?) discussion with our stakeholders is always a good thing.
What is your take on the Microservices and Service Oriented Architecture (SOA) debate?
