How do I achieve the perfect balance between scale, speed, and cost without breaking the bank?
As an early-stage startup, you often have very scarce financial reserves if any to bring your product to life or at least at an MVP stage to elicit interest from angels or early-stage VCs.
You are forced to work on a strict budget on hires and technology to at least increase your runway for a few more months.
As a tech founder (tech lead), you are given a product rubric. It captures wild abstract features from the rest of the team, and you, my friend are to bring that vague idea to a working product. Bottom line is that the product has to look good and feel good.
We’ll focus on the feel here.
The feel is a combination of speed and efficiency and a huge chunk of that comes from the system architecture, choice of a stack, and compute resources. From a development perspective, think backend application (API), DBMS, storage, and where they operate from (Cloud or In house servers).
The cloud
Cloud solutions are more price-friendly for startups when it comes to speed and scalability. The latter is because we can both horizontally and vertically scale our infrastructure. Doing the same on in-house servers would cost a ton of money to set up and maintain.
On the cloud you pay for only what you use, this boils down to CPU hours, storage and memory.
Now let’s talk about how speed and scale affect costs on a cloud-based product.
Speed
As a tech founder you’ll never get enough of, “This app isn’t fast enough. How can we improve it ?”. All I say after that is, “pay more !”. Here's why.
For speed, what you pay for is what you get. Cloud quotas for each tier limit you to certain memory and CPU types. As an early-stage startup, you’d probably be using the free tier. How to balance this is by limiting your processes to small processes instead of huge monolith processes.
An example would be if you are using a document-based NoSQL database like MongoDB, try as much as possible to shy off relational queries as they increase both the DBMS and Application CPU and memory usage thus increasing your bill.
Another example is if you have some kind of real-time features on your app try to sieve out features that would work fine as near real-time.
The logic is WebSocket libraries rely on HTTP long polling as a WebSockets backup which would mean that the client would constantly ping the server and vice versa to check for changes.
The downside is that constant pinging impacts the CPU hours when at times no data is being passed between them.
Scale
As discussed before. Scale isn’t a real issue when it comes to early-stage startups but I’ll talk about it nonetheless.
Scalability is the application’s ability to avail resources or data despite the number of concurrent requests (traffic). Cloud service providers have really aced this one. By use of load balancers that span new instances running your app, you need not worry about how it’s done. Though worry about the price.
High availability applications can be really expensive as spanning new instances add up to the overall bill.
How you’d deal with this is by limiting the number of instances the load balancer can span up to a reasonable number while checking each instance’s compute resources. You can either decide to reduce compute resources per instance to accommodate more instances (horizontal scaling) or add more compute resources and reduce the number of instances (vertical scaling). But always make sure to keep a reasonable balance between the two.
Note. All cloud service providers have billing alerts inbuilt. Make sure to set up a billing alert. Cloud solutions can be expensive as they are cheap if not correctly utilized.
In conclusion, always watch out for features released (how they scale and how they achieve speed) as they are directly proportional to product maintenance costs.
