Depending on where you are in the microservice adoption cycle, you may just be starting with your microservices journey. Or maybe you’re further along and are now feeling the pain of moving to microservices too quickly. You might be questioning the costs and benefits of monolithic vs. microservices.
For all of us, it’s important to remember that the software industry flows in cycles. As part of this cyclical flow, we also see monoliths and microservices fall in and out of fashion. The idea of having small, independent executables isn’t new. In fact, it’s been a part of good programming practices for decades. However, with the recent push to the cloud, architects have felt the pressure to move everything to microservices as quickly as possible. And we don’t always know if we’re making the right decision until it’s too late.
Despite the pressure to move to microservices, remember that architectural styles are not a one-size-fits-all solution. Instead, consider what’s best for your organization, your product, and your teams.
Today we’ll look at why you may choose one over the other. We’ll also cover the tools you need to monitor both architectural styles so that you can make adjustments when your business goals change.
Monolithic vs Microservices: The Case for Monoliths
To start, let’s talk about our old friend the monolith. The recent movement to make everything into a microservice has highlighted frustration with our existing monolithic systems. They’re large, difficult to change, and slow to test and deploy. In today’s market, you need to be able to get features out to your customers quickly. And old monoliths often make that difficult.
However, when first starting out, monoliths can provide a lot of benefits. You only need to worry about one deployment pipeline. You can learn about monitoring and observability on one application instead of having multiple teams try to implement similar solutions across the board. When debugging an issue, you just have one place to go. And operations folks can maintain one application instead of a large distributed system with many points of failure.
Additionally, when first writing an application, your team doesn’t fully understand the domain yet. Having everything within a monolith makes it easy to move components around while learning about the domain.
Why does the domain matter? If you don’t fully understand the domain yet, you may divide your monolith in a way that doesn’t make sense. And you may incur a significant cost of moving things around if features are in the wrong microservices.
So make sure you can change your understanding of the domain without having to redesign your microservices. One easy way to do that results in a monolithic design to start. Then, once you and your teams fully understand the problem, you can start to look for opportunities to break off microservices.
You should consider monoliths first for their simple deployment, debugging, and operations. And later you can look for opportunities to introduce microservices.
When Do Microservices Make Sense?
At some point, your monolith will become unwieldy. People are using your application and you’re starting to run into issues with the architecture. Congratulations! That means your product is successful, and you can now spend resources on improving the design.
So, when you’re debating using monolithic vs. microservices, what signs would indicate a need for microservices?
Different Rates of Change
If your application has some portions that change more frequently than others, then it may be time to split them up. For example, in a large legacy monolith, you may notice that some parts of the application never change. Therefore there’s no reason to split them out into separate services. However, if there are portions that still require a lot of change and maintenance, you may want to split those portions out into microservices.
Also, if you have one part of an application where the deployment is often slowed by deployments in another part, you have a great opportunity to split things up and take advantage of the different change rates. For example, if your ERP system requires additional audits and approvals for deploying new features in the accounting-related components, then it may make sense to have those separate from parts of the application that you can deploy quickly with minimal approval.
In order to determine if this applies, look at how often the code changes in different modules. Consider which portions of your application could use separation due to different rates of change.
Different Scalability Requirements
Another reason to take on microservices involves scalability. For example, for one application that I worked on long ago, we had a process that required a lot more memory than other processes. We made the easy decision to split that process out into its own microservice. We were able to give the appropriate memory to the part of the system that needed it while also saving operational costs on the parts that didn’t.
When looking at scalability requirements, measurement is key. Without proper monitoring, you won’t be able to determine where your memory or CPU hogs live. Or you may not know which APIs receive more traffic. You may believe that one part of the application requires more resources than others, but without actual numbers, you’re just guessing. To get started, try out Scalyr for free to see what application insights can tell you about your system.
Measure and monitor your application to determine where scalability requirements can affect your need for microservices.
Different Reliability Needs
The next reason to separate functionality into microservices regards reliability. Some parts of your system may not have the same service level agreements (SLAs) or service level objectives (SLOs) as others. And some processes could be critical to your business, while others are helpful but don’t need to be up all the time.
For example, if you have an e-commerce application, perhaps your recommendations engine doesn’t need to be available with five nines of reliability. But your shopping cart functionality does, because without it, you’re losing sales on items that customers know they want. Split things out so that critical components can be monitored and supported separately from components that you can temporarily live without.
As a different example, have you ever had a noncritical system bring down an entire application? That’s a great opportunity to pull out microservices to protect critical components from less important or experimental components.
Reliability needs differ across systems and applications. Aim to protect your critical systems with microservices when appropriate.
Different User Base
And finally, when considering whether you want to start using microservices, look at your user base.
When you consider various businesses and their systems, you will notice different user bases for applications. You’ll have external users or customers, internal sales or purchasing folks, and perhaps even plant personnel in a manufacturing setting. All of these customers have different needs.
You may want to separate applications based on those needs. These are very clear divisions that can be taken advantage of when considering your microservice strategy.
So How Do You Choose?
After considering the points above, you should have a better understanding of what needs will drive you to implement microservices. Ultimately, it will be up to you and your specific domain and system knowledge to determine your needs.
Then if you’re still in doubt, start with a monolith. This will give you the opportunity to learn about the features and components that could be separated based on the guidelines above.
And finally, monitor your system to see where you could split functionality apart.
What Do You Need to Get Started?
Whether you’ve decided to start with a monolith or microservices, make sure that you have the following in place.
- Well-defined DevOps. Don’t make every team re-learn CI/CD for each microservice they build. Automate and iterate on tools and processes that make microservices easy.
- Tested observability. Begin with observability of your monoliths. Figure out what works and doesn’t. Improve logging and monitoring so that you will be able to trace failures in your microservice ecosystem.
- Strong technical vision. Develop discipline around sharing the vision through documentation and training. Make sure everyone understands appropriate application boundaries and those boundaries exist.
These facets will help with development, operations, and maintenance, and ultimately will aid you in your quest to split your monolith into microservices once the time is right.
Putting It All Together
You may make mistakes when deciding between monolithic vs. microservices. But with good practices and tools in place, you’ll be able to see where you need to correct your course. Start with monoliths, measure your problem spots, and pull microservices out where it makes sense.
By adapting your architecture and strategically using monoliths and microservices, you won’t be swept away by the next architectural trend that could send you in the wrong direction. Instead, you will provide the right amount of flexibility and reliability based on application and business needs.
Monolithic vs. microservices: which is for you?
