You have to start somewhere, but where? For early stage startups, the first question is always: “where to start?” and “what sacrifices should we make now while finding product market fit?”. The decision, more often than not, is usually: build a monolithic architecture to move fast today while we worry about scale in the future. In many cases this is probably the right answer because of limited resources and no product-market fit to justify the time and cost to properly architect for scale. For the purposes of this article I want to highlight a few options that are available that will allow small teams to build for scale without sacrificing speed and be better off in the long run.
The Monoliths
First let’s define what a “monolithic architecture” means in this context. In most instances this means a single service that is handling business logic for multiple parts of a product that should naturally be separate. Let’s look at a high level architecture for a monolith:
In the above diagram you see a single service handling all aspects of the system regardless of the components involved and business needs it serves. The benefits of this are the ability to move fast with little overhead. There are few components involved, which can vary, making it an attractive first option.
Microservices
Microservice architecture, with each service serving a single product and/or technical purpose (e.g. client API, web hooks, push notifications, scheduled jobs etc.), makes not only scaling overtime easier but also creates independent failure points, cleaner architecture, and targeted engineering. The current perception, which in most cases is justified, is that this means a more complex architecture that is harder to maintain and even harder to develop. This is where things vary the most and depend on the cloud provider, components and tools that you decide to use.
The System Components
The components that make up your monolithic service have a lot, and sometimes even more, to do with when thinking about speed and overhead. If you are configuring load balancers, servers, containers, databases, etc, then you are already slowing yourself down and taking away some of the intended benefits of starting with a monolith. These may seem like one time setup costs that a small team could recover from but the added overhead isn’t always projected and accounted for.
There are many cloud services and tools available today that manage a majority of your setup allowing you more time to focus on building. This is also one of the main reasons why I feel a scaled architecture is easier to plan upfront vs sometime down the road when you have more resources. With today’s tools it is just as easy to spin up multiple services as it is a single service. Allowing you to properly separate your business logic and components in a clearly defined way.
Server-Centric
Most early stage startups will have some server-centric approach in their overall architecture. Are you managing a single instance yourself? Setting up and deploying containers? Kubernetes? With the tools available today most teams can have this completely managed for them at almost no added cost.
AWS Elastic Beanstalk: Application management platform that takes care of deployment and scaling for you (while still giving you plenty of control). All you need to do is upload your source code, compiled binary, or container image. Quickly spin up multiple services: your API layer, a worker service for long running or daily jobs, a notifications service, etc.
Google App Engine: Similar to AWS EBS but pitched as a way to deploy and scale a monolithic application.
Digital Ocean App Platform: Similar to GAE that is simple to setup and launch various services quickly.
Serverless
This has become a popular option over the years; getting away from the traditional server-centric architecture keeps costs low while experimenting, and it works for most use cases that don’t require highly performant systems. Scaling can get difficult overtime and managing the ever growing micro-dependencies can add complexity in more ways than one.
AWS Amplify: CLI that will power different aspects of your application to handle authentication, storage, server-less functions (lambda), CDN deployment, etc.
Firebase: Google’s suite of server-less tools for building, testing and deploying applications fast.
Digital Ocean: Limited set of features but simple and easy to configure and get moving.
This isn’t meant to be a comprehensive list or comparison between various cloud providers, but rather highlight how leveraging these tools can save you considerable time now and in the future. Everyone will have their preferred platform and ecosystem they already work in that makes the most sense for them.
Of course this won’t answer all questions or fit every solution. Each new product or service requires a more nuanced discussion to pick the right approach and strategy that sets it up for success.