What Should You Choose – SOA or Microservices Architecture?
There is a growing debate among the IT specialists and the enterprises that which out of SOA and Microservices architecture is the best, and which one to deploy. Many even say that Microservices architecture is far better than SOA and SOA has become a lame approach these days. There are several IT specialists and decision makers who believe that Microservices are an improvement over the SOA architecture and there is no point in using the age old SOA approach now.
What Are Microservices?
Microservices allow the enterprises to approach the development of a single application in the form of a suite of the smaller applications. This approach for developing applications has been garnering great popularity and adoption from the organizations spanning the globe. Nike and Netflix are among the top names who have recently adopted the Microservices architecture approach for developing the applications.
However, it is always wise to consider and understand the overall impact of the Microservices on the network and the underlying architecture before adopting these. Microservices can change the composition and the speed of the virtual networks along with the services which support these networks. Thus, it is important that the operations team and developers must consider that how to approach the network decomposition into the network services into those services which are more application centric, such as caching performance, load balancing, app monitoring and security and the ones which are not application centric such as VPNs, DDoS protection and others.
The services which are application centric become easily tied to the application and it results in per- application service model. Thus, we can make out that every Microservices can be provisioned with a set of Application services which go along with it. Enterprises are not required to configure and provision that set of application services and the application itself during the release process.
Implementing the Service Discovery
The key principle behind the Microservices architecture is the “Loose Coupling”. In this approach, the individual components require a separate service discovery infrastructure in order to find the IP address of the service with which they need to get connected. The service discovery layer should be as dynamic as the infrastructure is, in a cloud environment where the creation and destruction of VMs is a common phenomenon.
Differences between SOA and Microservices
From the perspective of technology stack, the three key points which bring out the differences between the SOA and Microservices architecture are:
- Microservices will most likely involve substantial automation of the infrastructure processes
- One is less likely to encounter the use of any heavyweight application servers in Microservices architecture
- One is completely unlikely to find out anyone advocating the service-enablement platform use in a Microservices architecture
The usage of the service-enablement platform is a definitive indicator that you may be more emphasizing on achieving the integration benefits instead of operational management benefits. However, the use of the term ESB might not be appropriate in this situation as ESB term is often used as a pure intermediary for the organizational, operational flexibility such as routing management to the ever-changing deployments. Similarly ESB may be used for perimeter security. But, ESB may continue to play a significant role in the Microservices architecture.
The Case of Application Servers
Again, as far as the application servers are concerned, these are often used in todays’ context as the legacy of the past, the days when the large servers were a trend. The days when there was slow infrastructure provisioning, no virtualization and the only technology choices that were available were .Net or Java EE.
Today with fully automated provisioning, small commodity servers, pervasive use of virtual machines, advanced open source libraries and scripting based server side development, the requisite to possess an Application Server capable of running and supporting multiple applications is not there anymore. Furthermore, when you want to scale up the particular operations and everything is pointing towards a highly fine-grained unit of management, do not get attracted to the application server. In fact, the operating system that you will need is not doing much with other than facilitating a solid set of comprehensive libraries for providing communication facilities with the other systems. You can simply throw Docker into this mix in order to achieve the required of decoupling from the physical infrastructure which allows the right amount of flexibility for the deployment.
I would recommend that there is no point obsessing over whether you have Microservices or SOA architecture or a hybrid of the two. Unless your requirements are specifically stringent or require only a specific type of service, it is always better to apply the most current and advanced “Industry Best Practices”.
Considering the existing systems, the utilization and deployment of the functionality provided and changes which have occurred or may occur to the functionality over time, you must take the decision about what to use or deploy. If splitting things apart makes sense as some of the portions of your application system are deployed or utilized significantly as compared to the others, or changed more considerably in comparison to the others, then it would be best to use the principles of Microservices in doing so as it presents a finer and much granular approach for doing things when compared with SOA architecture.
However, if your system requires or tends to change as a complete system in one go with the utilization and deployment spread across the entire functionality, the concept of breaking it in different parts may add to its complexity as the moving parts will increase. In such scenario, a service-enablement platform such as ESB would be the right way to leverage the technology to satisfy your integration requisites.
For the things which are completely new and have nothing to do with applications or settings, which are being rolled over from the past, I would recommend using the Microservices architecture approach as it is the best architecture for using the flexibility in this scenario. The prime reason for this is that it is always easier and better to build and deploy in at the beginning is much easier than retrofitting it later on in the systems.