Imagine a giant, lumbering city bus trying to drive around narrow, winding roads versus a bunch of zippy little scooters that can navigate tight spots and zoom off quickly in different directions. That, in a nutshell, captures the difference between monolithic applications and microservices architecture.
Rather than working with one ginormous backend application to manage everything, microservices break things down into tiny independent pieces that focus on doing one thing really well.
When Monolith Outgrows Its Potential
Imagine you lead the engineering team for a growing startup. You had architected an online platform as a monolith — a single unified backend that allowed quick delivery of new features with a small team you had at a time.
However, as the company expands, the monolith turns against you. Your once agile codebase becomes bloated as different application pieces become more complex and coupled. Each new user request and regulatory change adds complexity debt.
Before long, your deployments turn risky and require days of coordination. You dread the prolonged planning needed for even minor upgrades. What used to be push-and-deploy releases now result in extensive integration testing.
Onboarding new engineers became challenging, too. The convoluted interdependencies make the codebase impossible to fully comprehend in a reasonable time. Your team is constantly firefighting production issues from parts nobody fully understands.
You long for the golden early period when your compact app could easily adapt to changing requirements. But your aging monolithic architecture has become an obstacle to the growth needed today. The technical burden makes your team nostalgic about the past flexibility.
Scaling Services to Meet Demand
Microservices have an advantage in flexibility when it comes to scalability. With monolithic applications, you have to scale everything all at once. But microservices allow you to scale only the parts that need scaling. And it doesn’t necessarily mean scaling the compute resources — scaling engineering teams is way easier with microservices as well.
In app terms, catalog browsing has much higher traffic and is more feature-rich than checkout functions. Microservices let you spin up more instances of the catalog to handle the browsing load without overdoing it for checkout, which needs fewer resources, and also expand the engineering team for rapid iteration on all of the things users need. The ability to right-size by service saves money and delivers better app experiences.
Freedom to Choose the Right Tools
With microservices, teams don’t have to conform to a single technology stack across the organization like traditional monolithic architectures. Since each microservice is its own independent app, developers can select the ideal languages, frameworks, and databases based on the specific needs of that service.
For example, complex statistical analysis services can use programming languages like R or Python designed to crunch numbers rather than being forced into a one-size-fits-all technology approach. Similarly, a media processing service has different data and performance requirements than an account management dashboard. Decoupling enables each team to optimize their choice of tools for their distinct use case.
This agility allows an organization to experiment with modern languages like Go for brand new services, while legacy Python code can be phased out over time from older functions without risking a hairy full-scale migration. No more wasting precious development resources by forcing square pegs into round holes.
The Power of Focus
Microservices teams have the luxury of hyper-focus on building and perfecting specific functions and features rather than dealing with the extensive cognitive load of monolith teams.
By concentrating efforts on narrow domains, developers get an intimate understanding of the problems they are trying to solve. They don’t waste mental bandwidth wrapping their heads around complexities unrelated to the immediate goal.
At the same time, the modular nature of microservices allows different teams to scale up or down as needed without creating bottlenecks. If a service requires more advanced coding expertise, specialized talent can be brought onto that team.
Code bases are easier to understand and modify when they stay small and focused. Combine this with test automation and streamlined deployment workflows, and suddenly, engineers can devote much more time to creative challenges.
Ultimately, the engineering team starts to develop faster and bring innovative features to market faster — wins for both the engineers and the end users.
Juggling Many Moving Parts
As much as I love microservices, they have a few drawbacks. One of the biggest ones is the overall complexity of the microservice-based system.
Keeping track of what all those services actually do and how they fit together is a challenge — especially when you join a new team or have to update some old code, and there’s little to no documentation.
Debugging is a nightmare, too. Issues can bounce around between different services, like a pinball machine, and you have to piece together the whole flow by digging through logs. Even a simple issue can turn into an elaborate domino chain of requests between services.
And testing everything is multiplying headaches. To simulate the real environment, you have to build a complex mock system integrating fake services. Performance testing at scale when things are distributed all over? Exponentially more frustrating.
In short, microservices take the complexity level way up compared to monoliths. There are more puzzles for your poor brain to figure out and more moving pieces to think about when planning changes.
More Work to Keep Things Running Smoothly
Adopting microservices means many more balls to juggle to keep things running smoothly. With so many decentralized teams working on different services, tracing a customer’s purchase that spans 10 different services becomes a tedious game of connecting the dots. For example, if a payment fails, figuring out what went wrong means gathering clues from the order service, inventory system, and billing software.
Reliability also becomes critical when services depend on each other to function. If the inventory system crashes, the ordering process gets stuck. Adding caching helps reduce disruptions if a service goes down temporarily, but caching means data duplication and comes with its own set of issues.
But calling 10 different services to complete one purchase can slow things to a crawl if the connections between them are unstable. Choosing robust communication protocols is crucial to prevent services from getting tangled up talking to each other.
And then there’s data sync. Copying customer data into multiple service databases for faster access leads to conflicts when things get out of sync. Developers devote significant effort to fixing disparities and determining which database has the right data. Guaranteeing all services have consistent, up-to-date data is quite a challenge.
These complications make it harder for teams to fully realize the scalability and agility promised by microservices. The complex coordination requires more rigorous systems management. There are upsides and downsides to both approaches. Every architectural decision involves tricky tradeoffs.
Small Services, Big Gains
The move to microservices can seem daunting at first. As developers, we get comfortable with our monolithic codebases — they feel like a warm, familiar blanket we can curl up in. But the truth is, those cozy blankets tend to get a bit heavy and unwieldy over time.
Splitting into microservices encourages us to spring-clean our systems and workflows. It’s like organizing your closet — you group shirts, pants, and dresses together. Code for shared functionality finds a common home.
At first, it seems like more work. More services to build, containerize, and connect. But once the foundations are laid, microservices enable us to build faster. We can put on our laser-focus goggles and concentrate on one use case. Make this service do one thing, and do it well. No more context switching.
Originally published on Medium.com