This article is based on an interview with Simon Maple, Java evangelist extraordinaire, who offers enterprises some advice on moving to microservices.
Digital businesses are rapidly adopting microservices to achieve scale and agility. A natural evolution of SOA and API trends, microservices power more efficient and resilient applications by breaking them into manageable components focused around logical business capabilities. Microservices clearly offer a number of advantages over their monolithic counterparts, but like any architecture, there are right and wrong reasons to make the move.
Microservices done wrong
Development teams are often all-too ready to jump on the microservices bandwagon because it’s seen as trendy. Making the transition just for the sake of it may cause enterprises to fall victim to something called Conway’s Law, which states the tendency is for architectural structures of applications to closely mimic the structure of the team that creates the app, not the needs of the users. Enterprises struggle with this because they tend to have very large teams, and aren’t adept at quickly changing the structure of those teams to meet the needs of new architectural strategies.
An unfortunate trend that is becoming more and more popular within enterprises is that, instead of individual teams dedicating themselves to one or two microservices, these large teams are each generating loads and loads of microservices, which are then based on the structure of the team and not the needs of the end users.
It is better to put the needs of the users in developers’ heads by having teams dedicated to one or two microservices each, to build for proper scale, load, quality of service, and other goals.
Microservices done right
Instead of blindly following what’s trendy, teams should base their architecture on the needs of their application. Developers should ask themselves, “What are we trying to achieve? Is it resilience? Is it scalability? What is key?”
A good reason to move to microservices is to rapidly scale specific aspects of your architecture. In examining the needs of your application, you may determine that not every aspect of that app needs to be scalable, just the most important capabilities. For example, a payment system connected to a banking app should, ideally, be very resilient and very scalable so that, if many people are using the app at the same time, you can scale it up massively to provide users with the service quality they expect. That one aspect of the app will have to be scalable, but everything else may not have to be.
Thinking about making the move?
If you’re thinking about making the move (hopefully for the right reasons), we’ve got plenty of resources to help you with the transition.