Microservices vs SOA
Microservices have become a trend in recent years, as developers look to achieve the same success that large enterprises such as Amazon, Netflix, Uber, and Ebay have had in decoupling their monolithic applications. By adopting microservices, these enterprises were able to increase scalability, and deployment speed and frequency. However, microservices are not the best fit for many organizations or their applications. It is important for all companies to be familiar the advantages of a microservices architecture as well as the disadvantages of microservice, as they seek to evaluate if this type of architecture is a good fit. If this is your first exposure to microservices vs SOA, we recommend you start your journey at our microservices overview.
SOA Gave Microservices a Bad Rap
SOA busted onto the scene in the 1990’s, it was heralded as a revolutionary. When microservices appeared, developers were skeptical and were hard pressed to distinguish the difference between microservices and service oriented architecture. Unfortunately, this relationship did not do microservices any favors, as SOA had failed in its mission to address the issues that it was intended to. In all honesty, SOA was a scapegoat. Implementers were quick to blame SOA for failures. However, as is common with trends and new ideas, people jump in without fully understanding the journey on which they are embarking. The source of these failures really came down to people. People failing to implement SOA correctly by:
- Not aligning services to business objectives
- Not having the right organization culture. (Our white paper on Making Microservices Work for Your Organization covers the cultural requirements of SOA and Microservices in depth.)
- Failing to get business leaders on board
- Lacking the necessary skills, including architects, DevOps, and automation
- Poor planning practices
- Not fully understanding the complexity and scope of a distributed application
These are just a few reasons that SOA initiatives failed. However, the fundamental concept of SOA and loosely coupled applications composed of multiple business function oriented services is sound, and has been refined over the years. These refinements have culminated into a new buzzword, microservices. The truth of the matter is that microservices are really just a form of SOA. As such, microservices and SOA architecture patterns do share many similarities. However, this should not sway your thinking when determining if microservices are a good fit for your application. Microservices are the spawn of every failed and successful SOA initiative. Developers and architects learned from their SOA initiatives and succeeded with fine-tuned microservices to be what SOA was supposed to be.
This brings us to the reason you are really here, the showdown of microservices vs soa. In the following article we will compare the traditional SOA view with its current manifestation, microservices. We will cover a general overview of what each architecture is, their similarities, and in turn, how they differ.
What is SOA?
SOA or service oriented architecture is an architectural design style that was intended to be a way to break monolithic applications into smaller modules that are oriented towards business objectives. These modules can range in size from small application services to large enterprise services. SOA relies on messaging protocols such as (AMQP or SOAP) to communicate between services.
Why Did SOA Fail?
SOA was unable to fulfill its mission of addressing various issues associated with monolithic architectures. In many senses, a SOA is still a monolith. While composed of several services, SOA architectures are still relatively course grained, and possess a high level of interdependencies. As such, they are prone to many of the same issues as monolithic architectures. These interdependencies require that the entire application be rebuilt and redeployed each time a change is made, limited the speed at which companies can deploy new features. Also, communication in SOA passes through an enterprise service bus or ESB. An ESB promotes a monolithic structure, is characterized by slow communication speeds, and often times become a single point of failure. These issues, along with the various implementation issues presented above, all led to SOA’s inability to be succeed.
What is Microservices?
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 utilize language agnostic API’s such as REST for communication.
These features of Microservices help to address several of the issues relating to deployment, scalability and fault resistance that SOA was unable to address.
How are Microservices and SOA Similar?
Service oriented architectures are like microservices in the way that both are a collection of services that each focus on business goals, and are much smaller in scope then an entire monolithic application. Both architectures also require organizations to undergo a cultural transformation that embraces decentralization and empowerment of cross-functional development teams. Developers are also free to choose a different programming language for each service in both SOA and microservices. This allows them to leverage the programming language that possess the best features for those services specific goals.
How are Microservices and SOA Different?
While microservices and SOA were both designed to solve the same issues associated with monolithic architectures the differences between microservices and SOA are many. Some of the key differences between microservices and SOA are:
SOA are similar to monolithic applications in the sense that they typically share a single RDMS database. As an application grows and its data characteristics and processing requirements can be heterogeneous. At which point, a one size fits all data solution is no longer ideal. In contrast, in a microservices architecture, each service can utilize its own data store, allowing developers to choose the storage type that best meets the storage and processing requirements of the data being utilized by the service.
Size and Scope
Microservices focus on achieving one function, and performing that function very well. As such, microservices tend to be much smaller in size and scope when compared to SOA services. This creates a major benefit when on boarding new talent. Services are easy to understand, and are independent. Therefore, it is not necessary for new developers to understand the entire scope of the entire applications. In contrast, SOA services can be composed of multiple functions with many interdependencies, a single database, and ESB. This requires new talent to understand not only the service, but also the application interdependencies in full.
The way that microservices and SOA services communicate is also very different. Microservices communicate through language agnostic protocols, typically over the network. While this increases the number of remote calls, and in turn overhead, it results in faster communication, with a high degree of fault resistance. On the other hand, SOA communicates through an ESB. While this results in lower overhead, it does slow down communication, and presents itself as a single point of failure, with the potential to bring down all communication throughout the application.
Coupling and Cohesion
The reasons for the differences in coupling and cohesion are related to the size, scope, and communication differences presented above. Microservices feature extremely low coupling, and high cohesions. They achieve this by focusing on a single business function, and because all of the components necessary to handle its function, messaging, and data storage, including the operating system required to deploy them, are encapsulated in a container. This results in services that can be independently built, deployed, and tested. Another major benefit of microservices low coupling and independent design is that a failure in one service are unlikely to cause a failure elsewhere in the system. In addition, when errors do occur, it is simple to locate and isolate the source of the failure. These features become extremely helpful at deployment time, as buggy updates can easily be rolled back, resolved, and redeployed.
SOA services are much larger in scope, have more interdependencies, and communication and data storage is handled outside the services. This requires the entire application to be rebuilt, and redeployed, leading to slow deployment times and cascading failures.
Microservices vs SOA in a Nutshell
|Granularity||Course grained services||Fine grained services|
|Ease of Deployment||Requires recreating and redeploying entire application||Each service can be built and deployed independently|
|Remote Call Overhead||Low communication overhead||High communication overhead due to increase in remote calls|
|Speed of Deployment||Slow deployment speeds||Rapid, continuous, and automated deployement|
|Persistence||All services in SOA share data storage||Each service is free to choose its own data storage|
|Ease of On-Boarding||Semi-difficult to on-board new developers as scope of entire application may need to be understood||Easy to on-board new developers, as there is no need to understand the scope of the entire application|
|Polyglot Programming||Can utilize different programming languages for each service||Can utilize different programming languages for each service|
|Communication Method||Communicates through an enterprise service bus||Communicates via API layer with lightweight protocols like REST|
|Scalability||Can be challenging to scale||Extremely scalable through use of containers|
We hope that you are now able to put aside any past feelings you may have about SOA. As you can see, microservices have come a long way to mitigating the issues SOA experienced in its infancy. However, a microservices migration still carries many of the same cultural and planning requirements as SOA. Organizations considering adopting microservices should do their due diligence in determining if microservices is a good fit for its application.
Check out this micriservices webinar, "Microservices are here. Are you ready?" to see how a client of Tiempo; CBT Nuggets, made a successful transitioned to microservices.
If you are interested in learning more about microservices please download our 11 page white paper "Making Microservices Work for Your Organization."