Blog
August 7, 2020
In the last five years, the Java enterprise ecosystem has seen a massive shift from the traditional monolithic architecture to a more service-based approach. Accompanying this shift is a growing confusion on what defines a service-based application and what differentiates microservices vs. SOA.
In this article we hope to clear up some of that confusion. Join us as we look at microservices vs. SOA, what defines these service based architectures, how they work, their benefits, and the role they play in the overall Java ecosystem.
What Is Service-Oriented Architecture?
SOA is a development system in which services are designed to communicate with each other across different languages and platforms using a strategy called loose coupling.
Loose coupling is an extremely important concept to the understanding, and motivation to create, an SOA designed environment. Without it, one cannot create an SOA designed application. Not only does SOA need a use loose coupling, it also uses what is called an enterprise service bus (ESB) to communicate between the different services.
A loosely-coupled system is a collection of components or services where the function of each component remains independent of another required component. Therefore, if a loosely coupled system is designed properly each service would operate as a black box for each other service and would require little to no understanding of the inner workings.
Theoretically the relationship between the services that together make up the application architecture do not need to even share the same coding language. However, the communication between these services or components needs proper implementation in order to ensure that data and information can be used correctly. This implementation is also known as ESBs, in which integration of these different services are using communication buses between.
That allows for the services to communicate to the bus’s system and helps decouple the system because it needs no knowledge or dependencies of the bus’s system to use it. Therefore, information can be free flowing from each service when using protocols like SOAP or ActiveMQ.
Benefits of SOA for Java Applications
Typically for service oriented architecture designed Java applications we can see many benefits — from application flexibility to application testing improvements. As seen above, when applications use SOA it provides a ton of advantages, making it an attractive option for Java development teams.
| Benefit | Description |
|---|---|
| Reusability | Each service is designed to be loosely coupled therefore each service can be used in many scenarios. |
| Scalability | Services have limited functionality per service meaning services can be use with large or small applications. |
| Platform Independence | Services are designed with loose coupling allowing for services to be specific technologies or platforms that best suit the situation as long as the information used between each service is properly communicating to the ESB. |
| Easily Maintained | Components of the application can easily be taken down for maintenance without effecting the entire application. |
| Reliability | Services are self-contained allowing services to stay resistant to performance issues or bugs from other services. |
| Increased Testability | Each service can be tested independently allowing for increased for each function of application rather than testing an entire application with each iteration like monolithic designed applications. |
What Is Microservices Architecture?
A microservices architecture is a coding architecture style that relies on containers or services to provide a system of loosely-coupled services that, together, provide the function of a monolithic application. This style uses the term “Micro” to describe a core function of a traditional monolithic application.
At their heart, these microservices are just a monolithic application’s core functions, and are typically self-contained with complete web capabilities. Microservice applications are not beholden to using communication protocols with ESB. They can use language-agnostic communications giving microservices architecture (MSA) designed applications the ability to have more flexibility because they use APIs. The API communication tends to use HTTP/REST protocols to send and receive requests within the application.
Benefits of Microservices Architecture for Java Applications
When comparing the benefits of a MSA designed application, they closely align with many of the benefits of SOA. However, while the benefits may be similar, that does not mean they are accomplished the same way or even look the same in practice. The benefits below highlight some of newer, modernized coding practices that are used In mainstream development. Supporting agile and containerization go a long way in bringing MSA applications to the forefront of the Java enterprise space. That makes it one the more highly-considered architectural choices in modern Java development.
| Benefit | Description |
|---|---|
| Containerization | Helps promote technologies like Docker and Cloud development |
| Easier Deployments | Much easier to push new features of applications with less reliance on the entire application to be redeployed |
| Resilient | Services are self-reliant and do not depend on other services reducing the bottlenecks and failure points. |
| Scalability | Self-contained servers can be deployed to spread the requirements for the application |
| Agile development | MSA was designed to encourage short cycle times and faster development time for updates and creation. |
| More Flexibility | Using APIs to communicate means that teams have the ability to use the proper language or technology to best suit their needs. |
Microservices vs. SOA for Java Applications
They both have service in the name, so they can’t be that different, right? Yes, and no. The concept of designing a SOA based application has been around for the better part of decade, however the concept had never really achieved mainstream adoption. Microservices, on the other hand, have. That really has to do with microservices taking a more modern approach to the SOA style and learning from the existing style instead of redoing the entire design itself.
| Microservices | SOA |
|---|---|
| More relaxed messaging systems | Strict messaging systems with the use of Enterprise Service Bus messaging. |
| Stronger focus on agile development with strong focus of CD/CI pipelines | Not yet mainstream however that is increasing |
| Containerization support and focus | Limited support and focus |
| Smaller components with less functionality | Larger components with several functions per service |
| Lack the need for application servers | Need application servers to operate |
Many times, the distinction can be broken into more of a philosophy and not so much as a black and white answer. That’s why there is such a heavy debate between what the differences are. In essence, they are the same or just a refreshed newer version. Therefore, it can be hard to define that one is a microservices architecture vs. a service-oriented architecture solely based on the presence of a "microservice". This leads by a matter of exactly a microservice, which is why many people within the Java world use the term interchangeably. It is wrong to use them interchangeably, though, because they are different, and they do have defining differences.
When to Use Microservices vs. SOA
Deciding on whether to use microservices vs. SOA really comes down to the scale of the application and what you are planning your application to perform.
For instance, if you have a massive application, or have many functions that rely heavily on third party components, then an SOA approach may be the best option. That's because SOA is better equipped to handle some of the more complex business messaging because of the presence of a messaging middleware.
On the other hand, smaller applications, or ones with well-defined application workflows, tend to favor a more MSA style. In this style, developers now have greater control of the application because much of the functionally is easily tested in this stage. As technologies and containerization have grown in functionality and usability, more and more teams are sticking to a MSA designed system.
Amazon and Netflix are great examples of organizations that have revolutionized the way we think of MSA applications, since they rely heavily on Cloud development and frameworks like Spring Boot. Whether you are decoupling a monolithic or designing an application from the ground up, a microservices architecture may become the gold standard and may leave SOA in the dust for good no matter the situation.
Back to topFinal Thoughts
As discussed and shown above, both SOA and microservice architectures are designs cut from the same cloth. While both present similar benefits as well as drawbacks, they both have their place within the Java ecosystem. In addition, both approaches impact the space in a positive way — pushing technologies and code practices to reach new heights.
If you want to argue that the microservices architecture is just a subset of the SOA, you would have a very valid argument, since they share enough in common to say so. However, in my personal opinion, I find that microservice architecture is more of modernization and deviation of the SOA, on that provides some fundamental differences and improvement to the new Java world.
Additional Resources
One of the big struggles for teams working with service-based architectures is in tackling the complicated and unexpected performance issues that can arise without warning. This webinar looks at some of the ways to account for those issues and prevent them.
Want to continue learning about service based architectures and the Java technologies that make them work? These resources may provide you with some valuable insight:
- Blog - What Is Containerization?
- Blog - Pros and Cons of Java Containerization
- Webinar - Microservices vs. Miniservices vs. Monoliths
- Webinar - Making the Move to Microservices
Looking for ways to improve performance in your service based application? This white paper written by Rod Cope, CTO at Perforce software, looks at some of the major areas that developers can target for impactful performance and resilience improvements.