Microservices can have a major impact on organizations looking to increase automation and deployment speed. The biggest companies in the world – Amazon, Netflix, Google, etc. – all work on this architecture model and release at lightning speed. So why is using microservices so effective? The easiest way to understand microservices architecture is by comparing it to its counterpart – the monolith.
With a monolithic architecture, all of the components are part of a single unit: Everything is developed, deployed, and scaled together. In comparison, microservices have each component broken out and deployed individually as services, and these services communicate with each other via API calls. For complex applications that need to run at scale, microservices can offer greater flexibility, reliability, and a faster pace of innovation than monoliths.
No, monoliths aren’t inherently bad, but teams stuck in a monolith system often sacrifice speed for simplicity, and that could haunt them in the long term. So what do you do when you want to make the switch to microservices and start implementing faster? Consider these options.
The strangler method
Martin Fowler’s strangler method was inspired by a trip he took to Australia:
“One of the natural wonders of this area [Australia] is the huge strangler vines. They seed in the upper branches of a fig tree and gradually work their way down the tree until they root in the soil. Over many years they grow into fantastic and beautiful shapes, meanwhile strangling and killing the tree that was their host.”
It sounds brutal based on this description, but it’s actually one of the gentlest and most effective transitions for an organization. Essentially, parts of the monolith become microservices little by little until eventually the monolith is cut out completely. The benefit is that this transition is much more gradual, so uptime and availability are largely unaffected while the organization modernizes. The con? Speed.
The Lego strategy
Let’s say you don’t necessarily want to ditch the monolith completely. Maybe it has a valuable use for a certain product or facet of the organization, or maybe you just don’t have the resources to dismantle it or don’t want to. The Lego strategy could be the right choice.
The team at Kong use this term because you’re essentially building on top of what you already have (like Lego blocks). Instead of switching over to microservices completely, you commit to building new features as microservices while still keeping the existing monolithic codebase. While this approach doesn’t fix current issues, it will help with future expansions and buy much-needed time. This hybrid environment can exist relatively pain-free but has some risks: Increased technical debt, navigating code versions between the monolith and the new microservices features, and maintenance costs.
The nuclear option
Imagine: Your monolith is kaput, finito, dunzo. It can’t be fixed and it can’t stay. What now? As the name suggests, going nuclear is the riskiest and rarest option of all. The upside is that you can start from scratch. The downside is... you start from scratch. This approach is risky because you do run the risk of downtime when everything shifts over to microservices – which is a real no-no for user experience. Infrastructure is best when it’s invisible, and a new microservices architecture won’t win back the favor of users that were inconvenienced. Then again, maybe your new microservices architecture was built perfectly and cloud, software, and staff are perfectly in place and users will never know the difference. That’s the risk of a full rip-and-replace.
A successful transition to microservices
The team at Verizon was able to reduce its data center deploys from 30 days to under eight hours by utilizing microservices, and their application modernization strategy centered around four key goals:
- Architecture
- Automation
- Extensibility
- Being proactive
By having clear goals throughout the process, the Verizon team was able to remove manual deployments and streamline their processes. When adopting a microservices model, it helps to have some clear objectives about what you would like to achieve, and prioritize certain outcomes over others. Modernization projects almost never go according to plan, and if you have to make tough decisions, having a list of ‘must-haves’ can guide the conversation.
The oldest argument for monoliths has always been their simplicity: They’re easy to build and easy to run. While it was once difficult to develop applications with a microservices architecture, over the past five years it has become considerably easier with container orchestration tools like Kubernetes, comprehensive CI/CD tools that automate testing and deployments, and APIs that update automatically. Developers can focus on innovating rather than completing manual tasks and maintaining legacy systems. Organizations that adopt microservices get their simplicity through automated processes, and while it’s not as simple as a monolith, the benefits far outweigh the cons.
Regardless of which method you choose, the willingness to modernize to the latest DevOps architecture is the most important first step. Ready to dive into microservices?
