Technology has a way of circling around to the same ideas over time, but with different approaches that learn from previous iterations. Service Oriented Architecture (SOA) and Microservices Architecture (MSA) are such evolutionary approaches. Where lessons learned made sense, they were reused; and where painful lessons were learned, new methods and ideas were introduced.
Service Oriented Architecture
SOA was a reaction to the difficulty in extending traditional monolithic applications for both integration and functional reasons. As a monolithic application goes through its lifecycle, it becomes harder to address its technical debt and it becomes less able to quickly be adapted to new business challenges without a lot of refactoring.
The SOA method allowed for an enterprise to maintain a set of services that provide fine-grained functionality, and used those fine-grained services to assemble more complex composite services. These were all interconnected using an Enterprise Service Bus (ESB) and were then accessible to users through predefined consumer channels like an API Gateway, Web Portal, or other client-specific interfaces like EDI. There was no way to interact with a service independently; all requests entered through a defined entry point and traversed the ESB.
As business needs evolved, the fine-grained services could be easily extended – or new services added – without needing to refactor any existing composite business services. As any new services are connected to the Enterprise Service Bus (ESB) infrastructure, they would be automatically discoverable. The ESB would then handle all routing, data enrichment, and data transformation on requests to or from any services in the enterprise. In addition, since the service bus was centralized, and handled data enrichment and transformation, all services could rely on the service bus to provide all the data they needed to process a request.
SOA had four types of services that could be involved, and each had a different level of granularity. One was non-functional, and the other three were types of functional services.
- Infrastructure Services were autonomous services that would provide a complete set of functionality to support a non-functional requirement. Non-functional requirements are things like centralized logging, authentication, authorization, or encryption.
- Application Services are the individual components that provide a piece of fine-grained functionality that is specific to one application context. Some examples would be to retrieve a chequing account balance or to find the author of a book.
- Enterprise Services were a composite of application services that were defined to perform a function that was identified inside a business service.
- Business Services are usable by clients, employees, or partners as are often assembled into multistep process flows that would be frequently used by contact centers or other task-based workers.
The biggest positives from an SOA development model were that developers could focus on their specific piece of the puzzle and not have to care about anything else. Whether that was a piece of business functionality, or how to do data transformation, or how to map services through the ESB. In addition, every service had a defined and versioned interface.
The biggest negative was a result of forcing everyone to use the same set of tools to talk to the same ESB. The approach created a high level of bureaucracy and complexity in everything from templates to mappings within the ESB, as everything had to accommodate everyone. Part of this came around the strictly-defined interfaces that often only spoke XML and had to accommodate very verbose requests to fit within the taxonomy that ESB was managing. All these little details made the ESB become fragile, and operational teams leveraged frameworks like ITIL and COBIT to keep it safe.
As a result of all the bureaucracy. the promised increase in the speed of delivery of new functionality never really materialized.
Microservices were born out of yet another reaction. This reaction was to the centralization and standardization that developers were forced to live with in a SOA world. This can be seen in some of the basic building blocks that were defined – like using RESTful for services that are very lightweight and have no defined structure the developer needs to comply with.
MSA is based on the concept that every microservice is an independently developed self-contained functionality. There is no central repository to look up existing services, and connections are point-to-point. This doesn’t mean that a microservice won’t call another microservice, but that it has value on its own. An example would be that an inventory microservice could tell you a part number is in stock or not, but if you didn’t specify a warehouse to search, it could pass your location to another service to get what your closest warehouse is.
Microservices only have two types of services. Infrastructure services are the same as in SOA, where they provide a non-functional requirement like logging or authentication; and functional services, which support a business valuable function.
Any concepts around composite services or business process flows have been removed from the service layer. This functionality is now most often reproduced in the web or mobile application the client consumes, which results in a lot of service calls made to accomplish even simple tasks. The other approach has repurposed some technology from SOA to have a much more streamlined and valuable purpose.
Web and Mobile clients have enough intelligence that they can do their own coordination; but non-interactive processing still often has the need to combine data from multiple business functions. This is done by service bus products.
These products are usually streamlined descendants of the Enterprise Service Bus products, which were the core to any SOA infrastructure. Where these integration products thrive is in two distinct use cases. When combined with an API Gateway they provide translation to a format that an external partner is asking for whether that is to an SOA format like SOAP, or HL7 in healthcare.
The other use case is asynchronous processing where new information is received and needs to be sorted and stored across multiple services. This could be a new inventory in a warehouse, or a web sign-up form where the address goes in one service; and if they opted-in to receive any marketing, in another service.
The biggest positive to a microservices architecture is it really does speed up the innovation cycle in an organization, as it allows new services and client-facing interfaces to be created in whatever language and using whatever toolset the development team is most comfortable with. And, it is released on an independent lifecycle and can leverage whatever other existing services it needs to complete its purpose in life.
The biggest negative is ironically a result of the positive. Every development team is responsible for their own destiny and if they choose a hard-to-support toolset, then there may be no one else in the organization who can help them if they are stuck. In addition to no centralization, each application needs to track who its clients are on its own. There may be some centralized tooling like an APM to make this easier; but ultimately, if they want to retire v1 of a service, they need to contact all the users to migrate to v2, or risk shutting down a business-critical process they knew nothing about.
Similarity and Differences Between SOA and MSA
The real similarity is that both architectures have as their base, a service. These services are a black box of functionality. This means the components that rely on that service only access a set endpoint that is consistent so as long as that interface keeps its promise to support backwards compatibility, all its consumers never need to retest, and the service can be updated on its own schedule. If a major interface change is needed, then we get into versioning, which adds a lot of complexity in both worlds.
Essentially everything else about the architectures are different by design.
Service Oriented Architect
Share as much as possible
Share as little as possible
Standard enterprise messaging format, usually XML-based
Every service defines its own, usually JSON-based
Inter-service communication via ESB
Point-to-point is the standard way
HTTP (SOAP) and multiple messaging formats (almost one per vendor)
AMQP and HTTP (RESTful, gRPC, or WebHook)
Standard runtime platform used, typically based on Java or .NET middleware
Polyglot, and the trend is towards embedding the runtime like node.js or Spring Boot
Business changes result in updating existing business and enterprise services, plus the introduction of new application services
Business changes typically result in new microservices
Traditional SQL databases are most common
New datastores are typically noSQL-based
Enterprise and Business services are abstracted from data and rely on the standard data format, which provides more decoupling
Each service is responsible for its own data store, so even small tweaks can have big changes
Both SOA and Microservices have the same ultimate goal to address changing business requirements faster and easier. They started out at different ends of the central vs distributed pendulum swing. As time passes, Microservices have become less dogmatic against centralization and have started to steal the best and proven ideas from SOA and other Web Services frameworks. In addition, they are proving they will likely continue to be the dominant architecture for the current and next generation of infrastructure.
Complete visibility for DevSecOps
Reduce downtime and move from reactive to proactive monitoring.