Mike HahnIn the move away from monolithic application development, Service Oriented Architecture (SOA), which burst onto the scene in the 1990s, was heralded as revolutionary. This architectural design style was intended to break monolithic applications into smaller modules oriented towards business objectives.
It relied on messaging protocols such as AMQP and SOAP to communicate between services, and the service modules ranged in size from small application services to large enterprise services. However, SOA was not wholly successful in addressing various issues associated with monolithic architectures.
In many senses, an SOA is still a monolith. While composed of several services, architectures are relatively coarse-grained and possess a high level of interdependencies. This makes them prone to many of the same issues as monolithic architectures. These interdependencies require the entire application to be rebuilt and redeployed each time a change is made, which limits the speed at which companies can deploy new features.
Planning Mistakes Cause SOA to Fail
In addition, communication in an SOA passes through an Enterprise Service Bus (ESB), which essentially promotes a monolithic structure. An SOA is also characterized by slow communication speeds and oftentimes becomes a single point-of-failure. These issues, along with the various implementation challenges presented above, all led to SOA’s inability to succeed.
Failures in implementation of SOA made it an easy scapegoat, even though many of these failures came down to people neglecting to implement SOA correctly. Common major mistakes included:
- Not aligning services to business objectives;
- Failing to get business leaders on board;
- Lacking the necessary skills—including architects, DevOps and automation;
- Poor planning practices; and
- Not fully understanding the complexity and scope of a distributed application.
Despite these issues, the fundamental concept of SOA and loosely-coupled applications composed of multiple business-function services was, and still is, sound. From the refinement of this concept, microservices has been born.
Microservices is a refinement of the SOA approach and the two share many similarities. Both are a collection of services that focus on business goals and are much smaller in scope than an entire monolithic application. Each architecture also requires organizations to undergo a cultural transformation that embraces decentralization and empowerment of cross-functional development teams.
Microservices Offer Enhanced Form of SOA
With both SOA and microservices, developers are free to choose a different programming language for each service, allowing them to leverage the programming language with the best features for the specific goals of each service.
Microservices are a collection of loosely coupled, independently deployable services. Services are designed around a specific task or business function, and contain all the necessary components required to fulfill that function. The services within a microservice architecture are fine grained and use language-agnostic APIs such as REST for communication.
However, microservices is not SOA and many of the shortcomings of SOA have been addressed in microservices. Developers and architects have learned from their SOA initiatives and succeeded in fine-tuning microservices so that they have become what SOA was supposed to be.
While microservices and SOA were each designed to solve the same issues associated with monolithic architectures, there are many key differences as can be seen from the table below:
Snapshot View: Microservices vs. Monolithic and Service-Oriented Architectures
| Microservices | Monolithic | Service Oriented | |
| Size | Very small, function-oriented, independent services | Highly-interdependent services | Smaller, interdependent services |
| Granularity | Loosely coupled with high cohesion | Single, tightly-coupled unit with low cohesion | Moderately coupled with moderate cohesion |
| Ease of Deployment | Can independently build and deploy each service | Must build and redeploy entire application | Requires modifying the monolith |
| Remote Call Overhead | High communication overhead; many remote calls | Low/no communication overhead | Low communication overhead |
| Speed of Deployment | Rapid and continuous deployment | Very slow deployment speeds | Slow deployment speeds |
| Persistence | Each service is free to choose its own data storage | All services share data storage | All services share data storage |
| Ease of On-Boarding | Easy to onboard new developers | Difficult to onboard new developers | Semi-difficult to onboard new developers |
| Polyglot Programming | Can utilize various technology stacks per service | Utilizes a single technology stack | Can utilize different technology stacks per service |
| Communication Method | Communicates with lightweight protocols like REST | Many methods exist | Communicates through enterprise service bus |
| Scalability | Extremely scalable through use of containers | Can be very challenging to scale as applications become larger | Can be challenging to scale |
A microservices migration still carries many of the same cultural and planning requirement as an SOA initiative, but it has come a long way in mitigating the issues that SOA experienced in its infancy.
For more on making the move to microservices, join Nearshore Americas’s special special webinar presentation on April 3rd at 2pm EDT – registration is now open. Mike Hahn will be one of the panel members and will offer insight into how senior IT leaders can best leverage the flexibility and modularity of microservices for their businesses.
Add comment