Diana Meleshkova

iTechArt is a custom software development company. providing the following services:

• Custom software development
• Web application development
• Mobile application development
• QA and Testing
• DevOps
• Cloud computing
• UI/UX development
• IoT solution development
• AI-powered applications
• Blockchain-based applications

iTechArt is a top-tier, one-stop custom software development company with a talent pool of 1700+ experienced engineers. Since 2002, we've helped VC-backed startups and fast-growing tech companies build successful, scalable products that users love. Our forte is agile dedicated teams of brilliant minds who rock in web, mobile, Big Data, QA, and DevOps.

Quick facts:

• 200+ active clients
• 45 devs - the largest dedicated team
• 71% of our staff are Seniors and Team Leads
• Listed in the Inc. 5000 America's Fastest Growing Companies

Our services:

• Custom software development

• Web application development
• Mobile application development
• QA and Testing
• DevOps
• Cloud computing
• UI/UX development
• IoT solution development
• AI-powered applications
• Blockchain-based applications

It seems impossible to be in the tech industry and not at least have heard the term “microservices” in the past few years. Companies like Google, Amazon, and Airbnb have all touted this method of delivering software as possibly the best and most efficient way to build and scale applications.

When thinking of ways to stay competitive in crowded marketplaces, startups often look to what the tech giants are doing and may see adopting a microservices architecture as a differentiator. If you’re in this position you may want to proceed with caution. While the benefits of microservices that the tech giants promote are true, they don’t necessarily translate to startups and small fast-growing businesses.

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 on this 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.

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.

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

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.