Where do Microservices fit in the evolutionary scheme of Enterprise Software Architecture?
Software Architecture can be described as an evolutionary process. Successive iterations of software development results in increasingly better designs, better technologies, and better approaches. Natural selection weeds out weaker solutions and promotes those that are best suited to fulfilling expectations. The evolution of architecture is not only natural but necessary.
The need to change can be due to the availability of new technologies, new ideas, new methods, or evolving consumer expectations or tastes. Change may be regulatory, social, economic, or a combination of factors. They can be small and incremental, or large and revolutionary.
So, under this pretext, where do Microservices fit in the evolutionary scheme of Enterprise Software Architecture?
At first glance, Microservices are strikingly similar to Service Oriented Architecture (SOA). Some will argue that Microservices are simply a subset of SOA and that they are conceptually identical. At face value this appears to be mostly true.
Technically, nothing radically new is being introduced in Microservices. Both Microservices and conventional SOA style services are integration techniques that are platform-agnostic and based on mature protocols and conventions like HTTP. Microservices are actually less technically sophisticated than traditional SOAP-based web services since they lack the contract decoupling feature that is provided by WSDL. So, if the rise of Microservice Architectures is not due to a revolutionary, or even an evolutionary change in technology, then what?
It is being driven by a change in philosophy.
The promise of SOA in the eyes of Enterprise Architecture was to create a unified, complete, consistent, and predictable software ecosystem modelled by the business, for the business. Here’s the problem: enterprise environments are seldom unified; understanding of future needs is never truly complete; finally, customer expectations are neither consistent, nor predictable. Priorities and expectations have drastically shifted. Responsive, adaptive, and quicker – These adjectives are not usually synonymous with SOA.
Two examples of Microservice architectures (aka “Deathstar Diagrams”) for Amazon.com and Netflix.
So what is the difference?
One of the most important differences between Microservices over SOA is the granularity of functionality and scope for a given service. Where a single SOA service component might perform several operations in a single package, a Microservice architecture may break this up into dozens of individual and tiny service components. The assumption many are making is that smaller is better.
Increasing the granularity and the number of services to make things easier sounds counter-intuitive. The “Deathstar Diagrams” illustrated above shows exactly how much complexity results when there are dozens, hundreds, or thousands of tiny components interacting across a system. How is this an evolutionary step forward from a traditional SOA approach and its emphasis on structure, abstraction, and encapsulation?
Enterprise Architecture lost its monopoly on software design long ago.
The pre-occupation of architecture to achieve structure, abstraction, and encapsulation actually came at the expense of providing developers the freedom to implement software quickly and efficiently. What Microservices do is take the concept of loosely coupled service based system to an extreme and provides developers with far more control over the applications they build.
When a service is deconstructed to a granular level, it begins to resemble an application programming interface (API). APIs are the fundamental building blocks from which all software is constructed. So, under a Microservice paradigm, developers can pick and choose individual programming elements with a much higher degree of precision, granularity, and ease. It’s far easier for developers to code, test, and deploy individual components. This allows software to be delivered more quickly and more reliably – which is exactly what people want and expect.
Much of excitement around Microservices is actually the associated technologies which make development, testing, deployment, and management of Microservices code significantly easier.
The rise of DevOps, ChatOps, Continuous Integration, Continuous Delivery, Containerization, and API Gateways is not coincidental. Along with Microservices, each of these software delivery concepts are consistent with the principles of agility, flexibility, and ease of delivery.
The rise of Microservices is an evolutionary improvement over SOA. Its rise is a direct response to the need to deliver software more quickly and reliably and coincides with the growth of enterprise web/mobile/IoT based systems. It moves the emphasis away from prescriptive architecture and empowers developers with a greater degree of freedom and control over software delivery. Architects should definitely take notice; developers are beginning to have more influence over the enterprise.
