Challenging Conventional Wisdom

Conventional wisdom suggests that a new project should start with a monolithic server because a unified application can make the workflow easier for a small start-up team. But microservices can be a valuable alternative in the right circumstances. So, how do you decide which is right for your team?

To answer this question, we’ve called on three CTOs currently grappling this topic. For example, Darby Frey recently kicked off a greenfield project after assuming his new role as Sr. Platform Engineering Lead of Gamut. Despite starting out with a monolith at his previous company, Belly, he discovered that — in the right circumstances — starting with a monolith isn’t always the best way to go.

At Belly, Darby and his team broke down their monolith into a fairly large microservices architecture. They managed to get it to a good place, but only after months of trials and tribulations migrating to microservices. With this experience fresh in his mind, he approached his new project at Gamut a bit more cautious of microservices. And with that, he found himself faced with a decision we all struggle with, should we start with a monolith or microservices and how do we decide? That question is what we’ll tackle today.

Monolith vs. Microservices

Monolith

Contrary to what you might think, a monolith isn’t a dated architecture that we need to leave in the past. In certain circumstances, a monolith is ideal. We spoke with Steven Czerwinski, Head of Engineering at Scaylr and former Google employee, to better understand this.

“Even though we had had these positive experiences of using microservices at Google, we [at Scaylr] went [for a monolith] route because having one monolithic server means less work for us as two engineers,” he explained.

Monolith Pros:

• Fewer Cross-cutting Concerns: The major advantage of the monolithic architecture is that most apps typically have a large number of cross-cutting concerns, such as logging, rate limiting, and security features such audit trails and DoS protection. When everything is running through the same app, it’s easy to hook up components to those cross-cutting concerns.
• Less Operational Overhead: Having one large application means there’s only one application you need to set up logging, monitoring, and testing for. It’s also generally less complex to deploy.
• Performance: There can also be performance advantages, since shared-memory access is faster than inter-process communication (IPC).

Monolith Cons:

• Tightly Coupled: Monolithic app services tend to get tightly coupled and entangled as the application evolves, making it difficult to isolate services for purposes such as independent scaling or code maintainability.
• Harder To Understand: Monolithic architectures are also much harder to understand, because there may be dependencies and side-effects which are not obvious when you’re looking at a particular service or controller.

Microservices

While microservices tend to be smaller than the average monolith, they do not have to be tiny. Some are, but size is relative and there’s no standard of unit of measure across organizations. These services are built around business capabilities and are independently deployable.

Microservices Pros

• Better Organization: Microservice architectures are typically better organized, since each microservice has a very specific job, and is not concerned with the jobs of other components.
• Decoupled: Decoupled services are also easier to recompose and reconfigure to serve the purposes of different apps (for example, serving both the web clients and public API). They also allow for fast, independent delivery of individual parts within a larger, integrated system.
• Performance: Under the right circumstances, microservices can also have performance advantages depending on how they’re organized. This is because it’s possible to isolate hot services and scale them independent of the rest of the application.
• Fewer Mistakes: Microservices enable parallel development by establishing a hard-to-cross boundary between different parts of your system. By doing this, you make it hard – or at least harder – to do the wrong thing: Namely, connecting parts that shouldn’t be connected, and coupling too tightly those that need to be connected.

Microservices Cons

• Cross-cutting Concerns Across Each Service: As you’re building a new microservice architecture, you’re likely to discover cross-cutting concerns that you did not anticipate at design time. You’ll either need to incur the overhead of separate modules for each cross-cutting concern (i.e. testing), or encapsulate cross-cutting concerns in another service layer that all traffic gets routed through. Eventually, even monolithic architectures tend to route traffic through an outer service layer for cross-cutting concerns, but with a monolithic architecture, it’s possible to delay the cost of that work until the project is much more mature.
• Higher Operational Overhead: Microservices are frequently deployed on their own virtual machines or containers, causing a proliferation of VM wrangling work. These tasks are frequently automated with container fleet management tools.

How to Decide If a Monolith or Microservices Is Best for Your Business

We interviewed three CTOs faced with this decision to garner insights to this question; Darby Frey (Gamut), David Strauss (Pantheon), and Steven Czerwinski (Scalyr). Their experiences teach us to ask the following:

Are You In Familiar Territory?

Darby and his team at Gamut were able to delve directly into microservices because they had experience with eCommerce platforms, and his company had a wealth of knowledge concerning the needs and demands of their customers. If he was traveling down an unknown path on the other hand, a monolith may have actually been the safer option.

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 as it allows you to get used to the rhythm of developing in a microservice environment, right from the start.

How’s Your Infrastructure?

In reality, you’re going to need cloud-based infrastructure to make microservices work for your project.

“[Previously], you would want to 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,” David Strauss, CTO of Pantheon explained. “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.”

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. They thought it would be a month or two until they’d be forced to scale it. It ended up being over a year – and they ended up scaling it a completely different way than they had anticipated.

Decision-Making in Context

Using the wisdom distilled from the interviews, take the answers to the above questions and apply them to your team’s situation.

When To Start With A Monolith

Here are some scenarios that indicate that you should start your next project using monolithic architecture.

• Your Team Is At Founding Stage: Your team is small, between 2–5 members, and is thus unable to tackle a broader and high-overhead microservices architecture.
• You’re Building An Unproven Product or Proof of Concept: Are you building an unproven product in the market? If it’s a new idea, it’s likely going to pivot and evolve over time, so a monolith is ideal to allow for rapid product iteration. Same applies to a proof of concept where your goal is just 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, unless you can justify taking the risk of learning “on the fly” at such an early stage, it’s likely another sign you should stick to a monolith to start.

When To Start With Microservices

Here are some scenarios that indicate that you should start your next project using microservices:

• You Need Quick, Independent Service Delivery: Microservices allow for fast, independent delivery of individual parts within a larger, integrated system. Note, depending on your team size, it can take time to see 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 Grow Your Team: Starting with microservices gets your team used to developing in separate small services from the beginning, and having teams separated by service boundaries makes it much easier to scale up your team when you need to without introducing exponential complexity.

The Takeaway

Do not attempt to take on microservices just because other engineering teams are having success with them. Your own context, evaluated against the above considerations, is the key to deciding if you should start with monolith or microservices.

Thank you to our panel of interviewees for sharing their ideas. To our readers: What has your development experience been like? Do you see other benefits or drawbacks in adopting monolithic or microservices architectures? Comment below.