It’s hard to be in the tech field and not have come across the term “microservices” in recent years. Companies such as Google, Amazon, and Airbnb have all promoted this approach to software delivery as one of the best and most efficient ways to develop and grow applications.
When considering how to remain competitive in busy markets, startups often observe what big tech companies are doing and might view adopting a microservices architecture as a way to stand out. If you find yourself in this situation, it’s wise to be cautious. Although the advantages of microservices that tech giants advocate are genuine, they don’t always apply to startups and small, rapidly growing businesses.
What is microservices architecture?
Before we dive into reasons why your startup may not be ready for microservices, let’s be clear about what we’re talking about. We have written a more detailed explanation in our blog, but here is a simple version. Microservices refers to an application that is built using multiple, independently functioning “services.” These services communicate with each other via API. This is in contrast to the more traditional “monolith” architecture startups use in which there is just one large, complex application.
Why do companies like microservices architecture?
Not having to deal with huge “monolith” applications seems like an obvious advantage of microservices architecture. In addition, here are a few more specific benefits of microservices:
- Accelerated scalability and velocity – You can think of microservices as the architectural component of agile methodology. Individual services can be built, tested, and deployed completely independent of other services, allowing for more efficient resource utilization. Microservices coupled with agile also allows teams to create application capabilities that respond to market requirements in real-time.
- Security – In our age of increased awareness around data security, this is critical. Each microservice only contains data relevant to its specific business function. This minimizes the likelihood of complete data exposure in the event of a breach.
- Resilience – If one microservice isn’t functioning properly, it may still be possible to run the application. This lessens the possibility of having to take an entire application offline just to deal with a small problem.
- Reuse – You don’t necessarily have to start from scratch when building a new feature. It’s much easier to modify from an established base with the knowledge about what does and does not work.
Disadvantages of microservices
The companies often cited as having found success with microservices include the so-called tech giants like Google, Amazon, and Netflix or relatively newer companies like Uber and Airbnb. It’s important to note that none of these organizations are startups (all but Airbnb are publicly traded) and all have revenues in the billions of dollars. They also weren’t using microservices architecture on day one.
There are some disadvantages of using a microservices architecture during the early stages of a company. Here are five points to consider when determining if your startup or small business is ready for microservices architecture:
- The complexity of your applications
At one point Google was just a basic search engine, Amazon an online bookseller, and Netflix a DVD rental service. It wasn’t until they decided to scale that these organizations let go of basic monolithic architecture. Microservices architecture is meant to simplify complex applications, not add complexity to simple applications. If your applications are functioning efficiently as simple monoliths, then there is really no need to change what you are doing.
- The size of your technical team
Breaking applications down into multiple services will require you to have a large enough staff to manage them all. Also keep in mind that individual services do not have to be written in the same programming language (although some people see that as an advantage), so you will also need to have a large engineering team that is also proficient in multiple coding languages.
- Communication skills of technical team members
Contrary to what you may think, implementing microservices successfully requires active communication across all engineering teams. With monolith applications most engineers have the same level of familiarity with the codebase and can be pulled in to work on most parts of it. This is not necessarily true with a more distributed architecture. It’s possible that some engineers may not be willing or even able to work on issues not related to their specific service. This type of breakdown in communication is not what an early-stage company needs.
- Resources and budget to manage more tools and platforms
You will need multiple software applications and tools to implement a microservices architecture. At the very least you will need a container tool like Docker and an orchestration platform like Kubernetes. It’s also likely that you’ll need management, monitoring, and testing tools. This is will be a large financial investment, so you should be sure that making this change will really be worth the effort.
- The status of your legacy applications
Before you decide to completely scrap legacy codebases, be sure that it really makes sense from a resources perspective. If it communicates with a legacy database, do you have the resources to change that as well? Or if you already have a plan in place to phase it out in a few years, maybe it’s best to just leave it alone for now.
Some final thoughts
None of this is to say that the use of microservices in the startup environment is always a bad idea. The question is when to use microservices rather than if. The answer to that depends on where your company is in its growth. If you’re still looking for product market fit, or trying to build your customer base, then it’s probably not the time to make significant changes to your architecture.
But if you are scaling to a point where modifying your applications has gotten complex, then moving to a microservices architecture may be something that you want to actually consider.