What Biz People Need to Know About Tech: Microservices

This is an installment in the What Biz People Need to Know About Tech series. It’s aim is to help non-technical business people to communicate better with engineers and provide better feedback about the value they want them to deliver.

Microservices are something that developers are very likely to start suggesting as a business grows. You may also hear the term Service Oriented Architecture, or SOA. At its core, this is all about whether the code for your business lives in one app or is split up across many apps. Most businesses start out with everything in one app. At some point in their journey, they need to break things up into individual components. We’ll get into exactly what this means from a business perspective in this post.

What is a Monolith or Monolithic Architecture?

A monolithic architecture is what it’s called when all the code for a business (or product) lives in one app. For the most part, this is how you want your engineers to start out. With the exception of mobile apps and possibly javascript front ends, a new business is best served by the simplicity of having one server side app.

Having a Monolith is easier in the beginning for a bunch of reasons.

1. You only have one thing to deploy to the servers (more info on deploys)
2. The code is much easier to reason about and test when it’s all in one app. (more info on testing)
3. The developers’ working environment on their laptop is much simpler to keep working.
4. You’ll spend less money on hosting (probably)

What is a Microservice or Service Oriented Architecture (SOA)?

A Service Oriented Architecture is one where the system is made up of a series of independent nodes that communicate with each other to make your business work. Each node will typically be responsible for exactly one function. For example, you might have an Authentication Service and a Billing Dashboard. The user will go to the Billing Dashboard to see their payments history. The Billing Dashboard will make a call over the internet to the Authentication Service to make sure that the user is logged in.

As a business grows using this model, you can easily end up with dozens or hundreds of services. It’s rumored that companies like Spotify and Netflix have systems comprised of thousands of microservices.

The benefits of SOA are also numerous

1. Different teams can work on their own apps without needing to coordinate with all of the other teams as closely as is needed with a Monolith
2. The system is typically much easier to scale to a very large number of customers.
3. You get more resilience. For example, if your PDF Generation Service goes down, your users only lose access to PDF Generation. With a Monolith, a problem with any one part of the system is more likely to take everything down with it.

What’s the value to the business?

The value that you get from either a monolithic design or SOA comes down totally to the stage that your business is in. If you’re having trouble with scalability, development teams stepping on each other, or long error-prone deploys, then it might be time to start asking your developers if they are considering microservices.

Always Start With a Monolith

You also want to be aware of what it means to move to Microservices too early. some developers might try to make the case that it’ll save time later if they just start with a Microservice based design right out of the gate.

This is almost always a bad idea. It’s tempting from the developers perspective for many reasons, but experienced developers will know that moving to Microservices too early can be a disaster for a business. Unless your business model is almost totally stable and your product is thriving, the cost incurred by moving to microservices will likely put a serious drag on your ability to evolve the product rapidly and find market fit.

What happens when you move to SOA too soon?

When you move too early, the infrastructure required to keep multiple apps working together ends up being out of proportion for your business.

If you say, “Hey, we have 30 days of runway left, we need to launch a Referrals feature”. You don’t want the first 4 days of the developers efforts to be standing up new servers and setting up deployments for a new referrals service. When your business is small and still changing rapidly, you don’t want an architecture that requires a lot of infrastructural work. You want the developers efforts going directly into the product features.

What happens when you wait too long to move to SOA?

On the other hand, waiting too long to move to SOA can be just as damning.

For example, you can end up in a situation where scaling up your monolithic app to handle increasing traffic causes all kinds of problems. The most common is that your primary database begins to have too many connections made to it. If you have an SOA design, you can independently scale up each part of the system. When that’s done well, it makes it easy to not overload any particular resource, like a database.

Summary

The most important part of this post for startup founders is without a doubt, ALWAYS START WITH A MONOLITH

As businesses grow, the decision to move to SOA is complex and difficult. You can run into problems both by waiting too long and by doing it too soon. You’ll want your engineers to be the ones making the call on when to make that move, but hopefully this post has given you enough understanding to participate in the discussion.