You may have been told that microservices and startups don’t go together. You might think that microservices are too difficult a starting point for a new product.
This is the typical wisdom, but I’d like to challenge it. With modern tools, the latest industry practices, and cheap and convenient cloud infrastructure (plus some cheating), it’s easier than ever before to start with microservices over starting with a monolith.
The simple advice is to start with a monolith first and then later refactor to microservices. But refactoring to microservices is a difficult and painstaking process. If you anticipate a need for microservices eventually, why not just go microservices-first from the start and save yourself the time-consuming and painful conversion?
Startups can use microservices. And it’s not as difficult or as complicated as you might have thought.
Should a startup use microservices? The default answer is it depends, promptly followed by a cautionary probably not.
But there are many startups and products that can definitely benefit from jumping straight into the deep end with microservices! These days, it’s easier to build with microservices than ever before, and they can be a good option for startups operating with limited resources.
In this blog post, we’ll look at ways that microservices can help startups and examine some shortcuts to help get you started quickly and cheaply.
Scalability is the most obvious benefit to using microservices. Microservices applications are scalable to greater performance and capacity, and this is ideal for supporting a growing customer base.
They are also scalable from small to large organizations: as our business grows, we can grow our team around our application. Indeed, we can grow multiple teams around a growing microservices application.
Startups don’t need scalability in the early days. Of course, every startup dreams of scaling up big, and we hope to be able to do that, but microservices offer many other benefits that kick in long before we scale up:
Microservices applications typically make extensive use of automation. This can scale the productivity of small teams, helping them to operate with a lower cost at a higher level and produce consistent, reliable results.
The DevOps culture promotes ownership within the development team, and typically, developers own the product all the way through to production. This removes the need for a separate operations team and can really empower a small team!
The suite of modern tools (e.g., Docker, Terraform, Kubernetes, etc.) is there for the taking. These tools are well documented, well supported, and straightforward to learn. (OK, so Kubernetes is deep, but you might be surprised at just how quickly you can learn the fundamentals of it.) There is no need to build our own tools; we can and should build on the shoulders of giants.
We have cheap and convenient access to cloud infrastructure. It has never been so easy as it is now to create the infrastructure for our application (e.g. you can create a Kubernetes cluster on Azure with a couple of clicks).
The fine-grained nature of microservices gives us granular control over performance, deployments, risk, and anything else you can think of relating to our application.
We can continuously extend and upgrade our application with minimal impact to our customer.
Problems in one part of the application don’t bring down the entire application; it can run in a degraded state and continue to be useful to our customers.
As a startup, we have to cut some corners. It’s helpful to understand that the code in any particular microservice doesn’t really matter. Each microservice is so small that it can be thrown out and rewritten in a matter of days. Cheap and dirty implementations are officially OK, and we can easily replace them later.
These benefits add up to a continuous rapid pace of development. Rapid experimentation is so important to startups — we are trying to figure out exactly what it is that makes our product valuable!
Microservices help us reduce the cost of experimentation. We are better able to change things quickly and deploy reliably to get customer feedback. We can more quickly triangulate our product’s feature set.
Before you can decide whether microservices are right for your startup, there are a few things you need to consider:
Ultimately, the question is: Do I need to scale? Of course every startup wants to scale, but that doesn’t mean you need custom, scalable technology to achieve it. If it’s not clear that you need microservices, then you should instead prototype with simpler technologies until you outgrow them.
Getting started with microservices doesn’t have to be difficult, although it can seem that way if you are learning and facing down a steep learning curve. That’s why education in the fundamentals is important. It’s only with some hindsight that you can see microservices aren’t as difficult as they seemed at the start.
When you are getting started developing a new product, there are many ways you can cut corners with microservices that will make starting out cheaper, simpler, and more convenient. Let’s get into some key techniques to make microservices more accessible in your early days as a startup.
Don’t roll your own unless that’s the only way. Use a single repo and a single deployment pipeline as well. Keep your whole application (all your microservices) together in a single repository and use a single CD pipeline for deployment.
This drastically simplifies your security model; authenticate at the gateway, and treat internal connections as trusted. Run the cluster on a single virtual machine (VM). Until you need the performance or reliability, you don’t need more than one VM.
Until you need redundancy or performance, there is no need to make replicas of any of your microservices.
You should follow the best practice of having a separate database for each microservice, but you can host these databases on a single database server. There is no need to maintain a separate database server for each microservice!
In the earliest days, there is no need for automated testing. Instead, put your effort into building a script that can efficiently boot the application to a testable state (complete with realistic database fixtures) as quickly as possible. You want to make manual testing easy and efficient.
You’ll need automated testing eventually; it’s not possible to manage a large microservices application without automated testing. But it takes significant effort to stay on top of automated testing, and any work you do on such infrastructure detracts from your efforts to rapidly experiment with features that can make or break your entire product.
Do manual testing in the early days, then upgrade to automated testing as manual testing becomes less feasible.
Go to production early (you need this to get your application into the hands of customers) and have an automated CD pipeline in place from day one of going to production. In many ways, this is the most important part of your whole application! Getting feedback from customers (so we build the right product) is the lifeblood of a startup.
Using a single code repository and single deployment pipeline makes development with microservices much easier to manage. This somewhat defeats the point of microservices — having independently deployable services — but this doesn’t really matter in the early days of the startup!
Later on, it’s not difficult to extract your microservices to separate code repositories, each with its own independent deployment pipeline. When it comes time to do this, use the meta tool to have independent repositories as a single meta repository and continue to work on your application like it was a single repository.
Follow this advice when getting started with microservices and you’ll find that it’s a simpler and cheaper entrypoint for development with microservices.
Eventually, you’ll need to grow beyond cutting corners; you’ll need to scale up. And when you do, you’ll be glad that your foundation is scalable microservices with all the benefits that brings. Microservices offer many flexible pathways to scalability to ensure that your application can grow alongside your business.
I said at the start that prevailing wisdom presents a choice between a monolith and microservices. But I no longer think that it’s a simple binary choice of one versus the other. It’s more like there’s a sliding scale of possibilities from one large service through to many tiny services.
Monoliths and microservices are actually at opposite ends of the same spectrum, and in between them there’s an infinite variety of combinations, with services of varying sizes. You don’t have to decide simply between a monolith or microservices. You can, in fact, choose any point on that spectrum.
Know your options and make a choice that’s right for your company.
Ashley Davis is an experienced software developer and author. He is CTO of Sortal and helping businesses manage their digital assets using machine learning.
Ash is also the developer of Data-Forge Notebook, a notebook-style application for prototyping, exploratory coding, and data analysis in JavaScript and TypeScript.
Ash is the author of Data Wrangling with JavaScript and Bootstrapping Microservices. To keep up to date with Ash’s work, please follow him on Twitter and keep an eye on his blog, The Data Wrangler.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Build your first 2D browser game using JavaScript and the Excalibur.js library, covering essential game development concepts.
Explore the key differences between Angular and React, their strengths, and use cases to help developers decide which option to choose.
Learn more →
GET, POST, PUT and DELETE requestsLearn how to use Axios in JavaScript for GET, POST, PUT & DELETE requests. Examine setup, error handling, and API best practices.
AI for 3D web development is taking the internet by storm. Learn about this trend, the best tools for 3D web experiences, and how it’ll affect the development landscape moving forward.
