Microservices: A Passing Architectural Fad or a New Standard?

What are Microservices and how is it different than Software Oriented Architecture (SOA)?

Microservice architecture dictates that software should be composed of multiple, individually deployable services each running in their own process space and communicating with each other using lightweight, language-agnostic application programming interfaces. On the surface, this may not sound all that different from SOA, so why do we need a new architectural term to guide system development?

Conceptually, SOA touches on some of the same ideas such that a system’s architecture should be a collection of well-defined services. Over the years, the interpretation of what this actually means has become muddier and less clear. While OASIS and Open Group have worked to better define SOA, Martin Fowler and others feel that the architectural concept of SOA is beyond saving.

The combination of over a decade worth of monolithic SOA implementations and confusion about what SOA really looks like in practice has led many to seek new architectural means of designing and developing software systems. For the last few years, Microservices has been hailed as a sort of replacement to SOA. While some view Microservices as SOA done right, and others view it as a smaller-scale form of SOA, the truth is likely somewhere in between.

Enter Microservices

With the advent of cloud computing, infrastructure-as-code, containers, and cross functional agile teams, organizations find themselves in position to spin-up environments and deploy code to production faster than ever before. These changes have in part given birth to the Microservices architecture. Using a more stripped down method of communication (e.g., REST) and processing, Microservices’ aim is to be as decoupled as possible and to act as an independent service providing a very specific piece of business functionality. By creating these granular and individually deployable services, teams can now create systems with less risk of an introduced bug causing a catastrophic system failure thanks to the isolation of business functionality.


Trade-offs of Microservices

No design decision comes without its shortcomings however, so it’s important to understand some of the pitfalls of Microservices before deciding if using them is the right approach for your project.

The distributed nature of the Microservices architecture leads to a whole host of networking related issues that need to be addressed such as network latency, versioning, and fault tolerance. While many of these issues can be addressed during development, it’s important to realize that the mindset of the developers creating these services must be uniquely different from the developers who have spent their entire careers developing more monolithic applications. Additional consideration must be given towards how these services will live within the operating environment.

Keeping everything running is also a challenge. Since you are now deploying more services, or mini-applications running in their own process space, a more mature operating model for maintaining these services in production is required. Your developers and operations teams will need to be more tightly coupled than ever before. If DevOps is not in your vocabulary, then Microservices may not be for you.

Testing is a unique challenge when developing Microservices. Since services will be developed and deployed at a difference pace, and since they are also more asynchronous in nature, testing complex transactions between services can be difficult. Understanding and debugging interactions between services can be time consuming and a challenge for teams. By adding detailed monitoring, we can hope to alleviate some of this complexity, but the added risk brought to mission critical systems is worth noting and should be explicitly addressed.