With all the talk and content praising the microservices design approach, you might think the monolithic architecture is outdated and inefficient, but don’t limit your options when it comes to your application and, indeed, your company. In certain circumstances, a monolithic design is ideal, said Steven Czerwinski, a former Google employee and current head of Engineering at Scalyr, a server log metrics and monitoring systems developer.
“Even though we had had these positive experiences of using microservices at Google, [at Scalyr’s beginning] we went the monolithic route because having one monolithic server meant less work for us as two engineers,” he said.
In other words, because his team was small, a unified application was more manageable in comparison to splitting everything up into microservices.
A monolithic architecture is built as a single, unified unit. Often, a monolith consists of three parts: a database, a client-side user interface (consisting of HTML pages and/or JavaScript running in a browser), and a server-side application. The server-side application will handle HTTP requests, execute domain-specific logic, retrieve and update data from the database, and populate the HTML views to be sent to the browser.
In contrast, a microservices architecture is where an application is built as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and are independently deployable by fully automated deployment machinery.
The allure of microservices
Despite the advantages a monolith offers for startups, microservices have become a hot deployment method among them, and several companies have shown that using microservices out of the gate is a viable path to success.
“We have always started with a microservices approach. The main goal was to be able to use different technologies to build our service, for two big reasons,” said Julien Lemoine, CTO at Algolia, a hosted search engine API developer.
“First, we want to use the best tool for each service. Our search API is highly optimized at the lowest level, and C++ is the perfect language for this. That said, using C++ for everything is a waste of productivity, especially to build a dashboard. Second, we want the best talent and using only one technology would limit our options. This is why we have different languages in the company,” she said.
However, if your team is prepared, starting with microservices is wise because they can get get used to the rhythm of developing in a microservice environment immediately.
Monolith versus microservices
Clearly, startups can use either approach with success. I’ve interviewed dozens of startup CTOs for our upcoming eBook, which has helped me discern the key pros and cons to consider when deciding which architecture to use.
Monolith pros
- Fewer Cross-cutting Concerns: A major advantage associated with monolithic architecture is that you need only to worry about cross-cutting concerns, such as logging or caching, for one application.
- Less Operational Overhead: Focusing your finances on one application means that there’s only one application for which you need to set up logging, monitoring, and testing. A monolith is also generally less complex to deploy because you aren’t organizing multiple deployments.
- Easier Testing: With a monolith, automated tests are easier to setup and run because, once again, everything is under the same roof. With microservices, tests will need to accommodate for different applications on different runtime environments, which can get complex.
- Performance: A monolith can also provide performance advantages when compared to microservices. This boost is often down to a monolith using local calls instead of an API call across a network.
Monolith cons
- Overly Tight Coupling: While a monolith can help you avoid entanglement as previously mentioned, it becomes more vulnerable to entanglement the larger it grows. Because everything is coupled so tightly, isolation of services within the monolith becomes arduous, making life difficult when it comes to independent scaling or code maintenance.
- Harder to Understand: Finding that monoliths are more difficult beasts to understand in comparison to microservices is common, and this is a problem that rears its head when onboarding new team members. This difficulty is sometimes a direct result of the tight coupling, as well as that you may find dependencies and side-effects that are not obvious when you’re looking at a particular service or controller.
Microservices pros
- More Organization: Microservices are separated by function, making them easier to organize because each microservice has a specific job and location. Plus, if your team is large enough, you’ll ideally allocate a small team to each microservice, giving you better control over each service.
- Decoupled Services: With microservices, you can wave goodbye to tightly coupled applications. Instead, your services are decoupled, making life easier when you have to reconfigure them to serve different apps (for example, serving both the web clients and public API). They also allow for rapid, independent delivery of individual applications or services within larger systems
- Enhanced Autonomy: You can craft each service using different technologies and frameworks, giving you more freedom to innovate. With a monolith, you have to design everything using the same tech stack.
- Performance: Because isolating hot services and scaling them independently of the rest of the app is possible, microservices architecture can give you better performance, under the right circumstances.
Microservices cons
- Cross-Cutting Concerns: Whereas there are fewer cross-cutting concerns with monoliths (see above), they are a disadvantage when it comes to microservices. You’ll need to worry about issues such as logging or caching for every service.
- Higher Operational Overhead: Microservices frequently are deployed on their own virtual machines or containers, causing a proliferation of VM wrangling work. These tasks are automated frequently with container fleet management tools.
Deciding your best path
To arrive at a reasoned decision, apply these pros and cons to your specific context.
Are you in familiar territory?
At Gamut, the eCommerce effort from industrial products supplier Grainger, Senior Platform Engineering Lead Darby Frey and his team could delve directly into microservices because he had experience with eCommerce platforms. They bolstered this experience with their wealth of knowledge concerning the needs and demands of their customers. If on the other hand, microservices represented an unknown path for them, a monolith may have actually been the safer option.
Similarly, startups are often born out of pains experienced at previous companies. In those scenarios, developers will see how scaling is going to be a primary requirement, especially in infrastructure-based services like cloud log management.
Is your team prepared?
Does your team have experience with microservices? What if you quadruple the size of your team within the next year — are microservices ideal for that situation? Evaluating these dimensions of your team is crucial to the success of your project.
If your team is prepared, starting with microservices is wise because they get used to the rhythm of developing in a microservice environment, right from the start.
How is your infrastructure?
In reality, you’re going to need a cloud-based infrastructure to make microservices work for your project.
“[Previously], you would start with a monolith because you wanted to deploy one database server. The idea of having to set up a database server for every single microservice and then scale out was a mammoth task. Only a huge, tech-savvy organization could do that,” said David Strauss, CTO of Pantheon, a developer of a website management platform for Drupal and WordPress.
“Whereas today with services like Google Cloud and Amazon AWS, you have many options for deploying tiny things without needing to own the persistence layer for each one,” he said.
Evaluate the business risk
You may think microservices is the “right” way to go as a tech-savvy startup with high ambitions, but microservices do pose a business risk.
“A lot of teams overbuild their project initially. Everyone wants to think their startup will be the next unicorn and that they should, therefore, build everything with microservices or some other hyper-scalable infrastructure — but that’s usually wrong, almost all the time,” Strauss said.
One example of this from his early days at Pantheon was a system that was limited to a single VM, he said. They thought it would be only a month or two until they’d be forced to scale it, but that timeframe ended up being over a year, and they ended up scaling it a completely different way than they had anticipated.
Strauss explained that, in these cases, the areas that you thought you needed to scale are probably not the parts that will need to scale first, and that could result in misplaced effort, even for the systems that will need to scale.
Honestly evaluate your situation
Make your decision whether to use a monolith or microservices not by following industry trends, but rather by your circumstances. Here I provide some good rules of thumb for using a monolith or microservices, based on my aforementioned interviews of seasoned startup CTOs:
When to start with a monolith
Let’s look at some scenarios that indicate that you should start your next project using a monolithic architecture:
- Your Team is at the Founding Stage: Your team is small, between two to five members, and thus is unable to tackle a broader, high-overhead microservices architecture.
- You’re Building an Unproven Product or Proof of Concept: If your product is a new idea, it’s likely going to pivot and evolve over time, so a monolith is ideal for rapid product iteration. The same applies to a proof of concept where your goal is simply to learn as much as possible as quickly as possible, even if you end up throwing it away.
- You Have No Microservices Experience: If your team has no prior experience with microservices, you should stick to the monolithic approach, unless you can justify taking the risk of learning a new architecture on the fly at such an early stage.
When to start with microservices
Here are some scenarios that indicate that you should start your next project using microservices:
- You Require Quick, Independent Service Delivery: If it’s snappy, isolated service delivery that you need, microservices are your best bet. However, depending on the size of your team, it can take some time before you see any service delivery gains versus starting with monolith.
- A Piece of Your Platform Needs to Be Extremely Efficient: If your business is doing intensive processing of petabytes of log volume, you’ll likely want to build that service out in a very efficient language (i.e. C++) while your user dashboard may be built in Ruby on Rails.
- You Plan To Scale Your Team: Starting with microservices gets your team used to developing in separate small teams from the beginning, and having teams separated by service boundaries makes scaling your development organization easier.
Although it may seem that the trend is to move away from the monolith, there are certain situations where using that approach simply makes more sense from a cost and experience perspective. Take a hard look at the above considerations to determine what makes the most sense for you.
This article first appeared on ProgrammableWeb.
