Ready to jump on the microservice bandwagon?
If you are, you’re not alone.
Microservices came out of companies like Facebook, Google, and Netflix and have quickly become a popular architectural style for structuring applications for fast delivery. They provide a lot of benefits, allowing teams to gain autonomy and manage their own codebases and release cycles.
But are they the ideal choice for startups?
Both monoliths and microservices have their benefits, so deciding between the two requires a measured approach as you evaluate the pros and cons of each.
Keep reading for tips on how to make the best choice based on your startup stage.
Table of Contents:
What are the Pros and Cons of Monoliths and Microservices?
The Advantages of Monoliths:
One of the strongest arguments for choosing a monolith architecture is that it’s simpler to spin up from day one, enabling you to start developing business value from an early stage. This makes it easier to test new features as you build them out.
For a small or early-stage startup, this is valuable because the team is freed up to focus on the key business questions and the problems they’re solving.
Monoliths also allow consistency across your codebase since everything is in a single application.
The structure can lead to straightforward code releases with less overhead which is especially helpful for small engineering teams.
The Disadvantages of Monoliths:
One of the biggest downsides of monoliths is that dependencies can occur. As an example, you might ship Feature A, and start building Feature B on top of it. Later on, when you find out Feature A has a bug, you have to delay changes you wanted to ship in Feature B until the bug is fixed in Feature A.
Mike Gruen, Director of Engineering at Cherre, explains that with a monolith “it can be hard not to step on toes when you have a lot of people working on it. You can end up with conflicts about who can make changes.”
Head of Product Engineering at Coiled, Rami Chowdhury, explains that monoliths can make it difficult to divide responsibilities among engineers since everyone is working on the same application.
The Advantages of Microservices:
A microservice architecture has its benefits.
Jonathan Sage, Director of Engineering at Aledade, explains, “There’s massive benefits in the separation of a microservice because you can deploy part of your application rather than the entire thing. Since there’s less dependency built in, it allows you to do quicker deploys that require less coordination between teams.”
Mike points out that another advantage of microservice is that “you can separate things and have a smaller team working on a smaller part of the project.” There’s team ownership with responsibility split between teams.
Rami shares that “you can have a fast and independent release cycle, as well as flexibility of implementation and team ownership.”
The Disadvantages of Microservices:
Microservice architecture comes with some costs since it adds a new layer of complexity.
Mike summarizes, “You change where you want the complexity. Do you want the complexity at the code level where the engineers have to negotiate conflicts or do you want to move it to the product management level?”
If you’re considering a microservice architecture, here are some dynamics that you should be aware of:
- You’re going to need some concept of where the lines lay between services and how they communicate with one another. This can be difficult to achieve if you work for a startup that’s still in its early stages.
- You may need a DevOps team to focus on Continuous Integration/Continuous Delivery (CI/CD). At the very least, you’ll need to build an engineering team that embraces the concepts of CI/CD and moves away from the traditional operations team, which dealt more with physical hardware and networking.
- You’re adopting a much higher complexity across your entire system. It requires more people and more coordination. You’ll need to focus on project management to succeed.
- The increased complexity means that things such as testing can become more difficult. If you ever want to test how things fit together, you’ll likely have to spin up multiple microservices to be able to test whether or not the platform is doing what you think it’s going to do.
- Managing a microservice architecture is expensive, at least in the sense that it can be inefficient for lots of different reasons related to scale – whether that’s the scale of the information you’re trying to process, the scale of your users, or the scale of features you’re trying to build. It can also be expensive due to the increased number of employees needed to keep things running.
Any of these downsides can potentially slow you down if you’re not prepared to face them.
However Jonathan points out, “I think you can move faster with a microservice architecture, but upfront there’s a bunch of tax that you have to pay.”
How Can Startup Engineering Teams Make the Right Choice?
Knowing the advantages and disadvantages of monoliths and microservices, how do you choose the right architecture for your startup?
Microservices are a very popular option these days, so it’s easy to jump on board. However, Jonathan warns that “some teams choose to go all in on microservices from day one, create a system that’s complicated to navigate, spend time and resources navigating that system, and then run out of money before they have the opportunity to shift back to a monolithic approach to simplify things. Once you go that route it’s difficult to pull back. Unless they know they’re immediately going to need the separation and scalability of microservices, I would encourage teams to start with the monolith approach so they can first prove the business’ worth.”
Mike also argues that “going straight to microservices can be a premature optimization. If your project is in early stages, you don’t fully know what problems you’re going to face. You could end up introducing a bunch of complexity to solve a problem you don’t yet have. If you’re spending too much time making the same changes in multiple systems, that’s a flag that maybe you’ve jumped to breaking things down too early in the process before you really knew what you needed.”
But that doesn’t mean you should stick with a monolith for too long. Here are some warning signs that it’s time to move away from the monolith:
- If your features are so tightly coupled that your team is constantly trying to figure out how to prioritize work and how to work independently, then that’s a sign that you need to take a step back. It’s probably time to figure out how to break up your architecture to better match your team structure.
- If your team has compliance requirements or if you host data or workers in separate environments with tight access controls, then a microservice architecture will allow you to enforce those boundaries.
- If you have a bunch of legacy third party dependencies which might fail or stop whole processes, it’s likely better to separate them out using microservices.
- If your engineering team is getting slowed down because the entire code base lives in one monolithic system, then it may be time to take another approach. (As a rule of thumb, how you structure your code and your application should go hand in hand with how your team is structured. If you only have one team, a monolith probably makes a lot of sense. If you have multiple teams, a service-oriented approach works well. As your team grows and needs to add capacity, you’ll need the ability to scale and move quickly.)
- If your system can’t handle the load you’re putting on it and you can’t scale any further, then it’s time to consider other options. Note: Jonathan Sage recommends that you not only consider whether your system can handle the current load but also consider the future as well. What will your system load look like down the road? If you continued to grow at the rate you’re growing at right now, where will you be in a year? Look at your numbers every year to find out what timeframe you’re going to run out of room to scale.
Aside from these reasons, a monolith is likely the way to go.
Are Monoliths and Microservices the Only Option?
A lot of teams assume they have to go the microservice route right out of the gate. Before diving in, ask yourself, “Do we need this right now?”
It’s important to note that microservice architecture isn’t the only way to scale. It may be helpful down the road, but you don’t have to jump in immediately. Instead, you could start by choosing another service-oriented architecture.
Jonathan recommends that you first focus on proving that the business works. Then you can ask: Where am I failing to scale? Where is this monolithic architecture not living up to what I want my application to do?
He explains, “If you can see that a space has really suffered or been hit hard, then you could segment it off as its own service and keep the rest of the monolith for now. Once you’ve successfully scaled that piece of the application, you could ask, ‘What’s the next thing that’s struggling to keep up?’ From there, you could carve out that piece and segment it off as its own service.”
With that approach, you can break the monolith apart and slowly build out more services.
How Should Startup Teams Migrate from Monoliths to Microservices?
If you’ve done your homework and decided a microservice architecture is the right choice for your company, then it’s time to make sure you’re prepared to take the leap.
Here’s what you’ll need before migrating to a microservice architecture:
- A DevOps team, or at least an engineering team that has moved away from the traditional operations team (which deals more with physical hardware and networking).
- A business case for why you need a microservice. Without this, you could end up with a premature optimization, solving a problem you don’t necessarily need to solve.
- A clear idea of where you’re going to segment things. If you don’t have a clear idea of what each service needs to do, you can end up creating coupling in a dependency graph where you were trying to avoid that to begin with. Anytime you’re starting to make a tight coupling between services, step back and consider where the lines are between those services. To avoid a dependency, you may need to duplicate data across services.
What Resources Exist to Learn About Monoliths and Microservices?
If you want to take a deeper dive, we recommend checking out the following resources as a starting point.
- The Art of Scalability: Written by Martin Abbot and Michael Fisher, this book delves into scalable web architecture, processes, and organizations for the modern enterprise.
- This Hacker News post provides a succinct guide to choosing between monoliths and microservices.
- Martin Fowler’s articles provide a deep dive into microservice architecture and share the
motivation behind the trend.
As you research further, try to find resources that aren’t biased or look for multiple viewpoints to get a complete perspective. Ideally, find resources that support both sides of the argument, so you can make the most informed decision possible.
Conclusion
Many startups make a snap judgment when it comes to monoliths versus microservices.
But you don’t have to follow in their shoes.
Take a step back and gauge what your company needs now. If you’re still early-stage, you probably need to focus on just building out the business. If you’re a larger company or your system can’t handle the load that you’re putting on it, then it might be time to migrate to a microservice (or another service-oriented architecture).
Keep this information handy so you can easily analyze your options and make an informed decision.
