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.
What is 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.
4 Types of Service Oriented Architecture vs Microservices
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.
What is Microservices Architecture?
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 vs Monolithic Architecture
Microservices have demonstrated an ability to deliver flexibility at scale, but controversy continues as teams weigh their benefits against the traditional monolithic structure that has reliably proven to enable rapid development.
Monolithic applications are relatively quick to stand up, easier to deploy and are well-known entities that most tools, frameworks, and IDEs are designed to deal with.
Monolothic Application Cons
The weaknesses of a monolithic application tend to show as it matures. Even the most carefully modularized application has the potential to stifle continued development and onboarding of new engineers as it increases in size and age. In this industry engineers come and go and each wave will add new interdependencies and then leave; taking critical and intimate system knowledge with them. Frameworks and style guides are built specifically to help address this, however the pressure to deliver inevitably leads to technical debt. Large applications can become a burden for deployment, as one change anywhere in the application requires a full rebuild and size impacts time to deploy. At the point where the team identifies a new technology that can provide features and functionality more efficiently, it can be a seemingly impossible task to take your mature product and migrate to a new platform. Despite these downsides, many companies continue to rely on the monolithic model and successfully extend their applications with varying levels of efficiency.
Microservices vs Monolithic Applications
Microservices require a different kind of commitment from the engineering team in how they orchestrate, maintain, and extend an ecosystem of services. By breaking an application down into components you have more moving parts and this complexity requires additional monitoring and management. Each service will require a monitoring and logging solution that will enable the team to assess performance and proactively address issues. Tools need to be built or configured to handle service replication as well as discovery when individual services scale up and down. Messaging layers will likely be required to address network latency and allow for true independence.This means more work for the devops team, as they have to manage a much larger ecosystem. If you are a smaller startup that doesn’t have a devops team this additional overhead will slow delivery. Good engineers are good at delivering code, but documentation and testing are organizational behaviors that are harder to uphold and maintain. Microservices necessitate high quality documentation and sufficient testing or implementing features that require communication between services becomes complex and fragile. All applications should be properly documented, but monolithic applications leverage frameworks that at least provide a base layer of documentation.
Examples of Microservices vs Monoliths
Organizations that support several mature applications can also implement microservices to handle shared functionality and cross-monolith communication or events as a first step. The intent is to DRY your codebase at the application level.
How can you prepare for a microservice-based architecture without taking on the additional overhead up front? One strategy that has worked well is to start by decoupling the application from the database. By creating an API service that interfaces with the model a developer can become comfortable writing APIs and properly documenting them, while assessing the latency inherent with a network service. Additional advantages include having the foundation prepared for additional clients (i.e. native mobile), maintaining a relatively small footprint early in the product lifecycle, and retaining a quick development cycle.
As your application, funding, and team grow you can build larger features as fully independent services. Depending on the application they can be injected between the data service and the main app or built with their own database. With further development you can break the remaining capabilities out as additional services that independently scale and be placed behind an API gateway to centralize communication between clients and services.
There is no single best strategy for architecting an environment of microservices as requirements of the application will determine the ideal infrastructure. Defining best practices early in the application lifecycle is extremely beneficial to smooth the switch from the MVP monolith to microservices. Onboarding engineers into a team with a culture that supports the care and feeding of microservices is easier than shifting the thinking and operation of a well-established team. At each phase of growth, careful consideration should be made to ensure the scale of the application does not exceed the scale of the team.
Two Types of Microservices vs SOA
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.
Microservices vs SOA Use Cases
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.
SOA vs MSA: Similarities and Differences of Service Oriented Architecture and Microservices
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.
Compare SOA and Microservices
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
Summary: SOA vs MSA
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.