Once you’ve decided microservices are right for your organization, what’s next? While refactoring your application is a worthwhile decision, it is a long-term investment that depends on the size and nature of your monolith, business goals, organizational maturity, and existing development processes and skills. Keep the following strategies in mind as you make the switch.
1. Map and plan
How far do you want to go in breaking up your monolith?
When it comes to a major transition, there’s an inclination to start over with a Big Bang rewrite — a risky, often unnecessary option, especially for massive, legacy applications. The strategic alternative is to first create a plan according to your business needs. This could involve anything from extracting and independently scaling one or two microservices to supporting a main application or completely breaking apart the monolith. As an added challenge, refactoring old features is hardly a priority for investors intent on meeting their business goals. Therefore, it’s important to approach the transition as a long-term, technical debt task.
Regardless of how granular you choose to go, a key part of all roadmaps should be to stop building on your existing monolith. The bigger you make it, the harder it is to break down. Instead, all new features and functions should be implemented as microservices or miniservices.
2. Identify the seams
What loosely coupled components can you naturally pull out from your monolith?
To begin executing on your refactoring plan, you first need to fully understand your monolith, beginning with identifying where certain parts may be more loosely coupled. These natural seams provide a logical starting point for boxing off independent components. For some companies, it may make sense to stop at this miniservice or self-contained component layer. For others, these components will likely contain even more components that you can pull out into individual microservices.
This approach is particularly important for enterprises with extremely large and fragile monoliths. It’s a daunting task for any one team to understand how the system as a whole works. Instead, think of the monolithic application as a black box accessible via APIs. They don’t have to be only restful services — just any way you can interface with the application and start building microservices around it. Eventually, you’ll begin seeing some bounded contexts and can start whittling them down.
3. Build microservices around new features
What business units or projects have an immediate need for enhanced services?
How and which components you pull out should be guided by your product roadmap. To start, look for specific business units or projects that need enhanced services. Consider pulling out these components and building out a completely new microservice around them. You can then start de-commissioning features of your monolith as new projects are built. This is also a convenient way to clean up technical debt and still deliver immediate business value.
4. Invest in DevOps and organizational culture
Do you have the right people and processes in place to execute your plan?
Functionally and culturally, your teams must be built to own their microservices from the initial line of code, to deployment, to operations. Just as refactoring isn’t a Big Bang fix, there’s no need to completely restructure all teams at once. Focus on one “bounded context” — in this case, a group that’s experienced and understands how to work in an agile environment — and grow the team as you execute your plan.
From a process standpoint, it’s crucial to fully invest in DevOps, a trademark characteristic of microservices. The more you break up your monolith, the more you risk an explosion of microservices that lengthens your development process and hinders your ability to deploy rapidly. Increasing your tooling and team experience will enable your team to realize the full value of microservices.
5. Lay down some governance
What rules will help your organization avoid a Wild West situation?
While microservices offer the freedom to choose your database, programming language, frameworks, and more, lack of standardization will eventually cost you, requiring multiple versions and libraries. Languages and tools preferred by a two-person feature team, for instance, don’t scale in an enterprise production setting and are susceptible to employee churn. Think of your platforms, languages, and frameworks as a long-term investment.
For a deeper dive into microservices, read this interview with Tony Pujals, Director of Cloud Engineering at Axway.