Make the Move Away From SOA Into Microservices
According to the 2016 RebelLabs report from ZeroTurnAround.com, a full 34 percent of developers have made the leap into microservice-oriented architecture, while over half of the remaining 64 percent are considering adopting this method. Another (perhaps more telling) statistic from the same report is that of those who have started using microservices, 40 percent state that their job has been made easier while only 18 percent claim it has made it harder.
But what does this mean in the context of your current architecture? If you are using a monolith style service-oriented architecture, you could be making your life more difficult in myriads of ways.
Improve agility by reducing coupling
Using highly coupled software greatly reduces the agility of applications, and that’s exactly one of the issues with service-oriented architecture. With a tightly coupled service, one failure can bring down the entire the solution. Changing minor aspects of a tightly coupled service without those changes having an impact on other aspects of the service is extremely difficult.
Traditionally, an SOA approach was one which included a high level of coupling. A lower level of coupling with a familiar monolithic approach to releases and builds was revealed as the needs of services changed, but even that more modern approach allowed for very little agility. With microservices, there are no more monolithic releases and no more tightly coupled services, resulting in a greater level of agility.
When service-oriented architecture was undergoing a conceptual redesign, many companies were starting to purchase SOA solutions. This approach was being taken as late as 2014, and may still be used today in some cases. Although there was a push for lower coupling in SOA, purchasing an architecture can still lead to that mistake.
Start speeding up development and deployment
Implementing microservices is a great way to gain freedom from aging technologies such as SOA. A boon of using microservices is that they are independently deployable, meaning that individual services can be swapped out with microservices gradually rather than having to replace the entire thing all at once.
The speed of deployment is only one aspect of the agility microservices offer. It’s also easy to make changes to a service that has a greatly reduced or non-existent level of coupling as compared to SOA. Each of the small processes that make up a microservice architecture are independent of each other.
Take note of these final boons and banes
Another pro for microservices and con for SOA is that of language agnosticism. Each of the services built in a microservice oriented architecture can be written in different languages. This provides a clearly defined and solid boundary between services, and also allows each service to be managed by different teams or even individual engineers. The small team approach means focusing on projects instead of products, so that an incremental pipeline approach is removed.
On the downside, microservices can present operational challenges. The proper implementation of microservices requires skilled teams to manage frequent deployments over a large number of services. Managing consistency across multiple teams is another difficulty if the solution is large enough to merit a lot of teams.
Using an SOA might have saved your solution in the past, but today it runs the risk of ruination. By implementing the more modern approach of microservices with a measured hand, you can improve development agility and deployment speed, resulting in a better overall product.