In a pre-seed or seed stage startup with a less than ten-person engineering team, considerations like using microservices and the value of infrastructure and DevOps architecture are critical and require a clear distinction and understanding. This becomes especially important for startups that rely on data to build and provide predictive analytics. This begs the question, do serverless and microservices save or increase overall infrastructure and development costs? 

I will provide my insight on this topic in a series of blogs. This is the first one in the series where I will look deeper into the challenge and steps to get the best outcome for your business.  

Typical Environment  

Early-stage startups mostly build experiments or Proof-Of-Concept (POC). If you are fortunate and the problem is well-defined, you get to create a product or solution right away. However, in most cases, you are likely dealing with an ambiguous problem statement – In such a case, the biggest challenge is to oversee the scale required for this solution — this even becomes tougher when you are in a startup where the entire software implementation could become throw away work or become immaterial from an end-user perspective. In a good outcome, the current software version or the next iteration could take multiple paths based on the results. In my experience, only about 20-30 % of the time, you will continue to expand, grow, and scale your solution, whereas, in the rest, it’s primarily learnings for your next experiment. 

Regardless of where you are in the startup journey, one constant is the data. Data you collect, data you merge from different sources, and the data click for data science and machine learning experiments. Whatever the outcome of your experiments, the learnings with the data you collect to feed your models remain. Therefore, it is essential to collect and push data to your data lake seamlessly. 

Once it reaches your lake, bring this data to insights using an analytics engine like OpenSearch, or you stream and make it queryable using Athena or any other external analytics and querying tools, What’s important is that you want to make sure your business and product teams are enabled to keep the data as a central piece of influence and your work in engineering enabling them and bring in the visualization of this data in almost real time before they start to decide destiny your experiment.  

It is important to provide insights and listen to your business users (Product and Sales teams) for feedback and evolve the models accordingly. If you have insights published to your customers, you have to keep the production impact to a minimum. In all what you do, you will or most likely have a system which is in place and being used daily and may be externally specially if you are already launched out in public with something that you like to not impact and rather keep it going intact with your daily experiments and POC’s. 

If you are unsure whether your experiments will make it into your mainstream software or codebase, it is best to keep it isolated. If you are building a service or API endpoint that will be idle most of the time, you will have to consider a performance trade-off like a slow start after the first call. Trade-offs like these are important in a startup as they will help keep the infrastructure costs down without sacrificing time and code quality.  

Below is a list of technical considerations when building a scalable infrastructure while your startup grows: 

1. Codebase isolation and infrastructure as code 

2. Infrastructure scaling up or down

3. Designing to optimize the financial impact

4. Real-time data availability and streaming to your data lake

5. Re-engineering and debugging tools

6. No impact teardowns

At Mulberri, we follow design best practices and have put many of them into practice. In the next several blogs, I will deep dive into each of these items. 

Stay tuned… 

https://mulberri.io/