How Small Startups Move Incredibly Fast With Serverless

Dadi Atar
Dadi Atar
Nov 22 · 3 min read

I joined Kumba 9 months ago as a CTO and Co-Founder.

After working in an enterprise (Intel) and a startup (Kampyle, which was acquired by an enterprise — Medallia), I decided to pursue my dream and start something of my own.

Being the only technical person among the 3 founders, I knew that I have very limited bandwidth. Also, I’m coming from a strong front end experience and lacking knowledge in spinning up servers and everything that comes with it.

So I made a few strategic decisions:

  1. Continually model our domain with an ERD and GraphQL schema. This requires a deep understanding of the business we work in.
  2. Don’t solve old problems. Rely as much as I can on proven 3rd party services.
  3. Focus on the core non-replicable functionality and outsource the rest.
  4. Everything is under source control — from code to infrastructure.
  5. CI/CD from day one — both for infrastructure and code.
  6. Focus on monitoring and logging at the expense of QA and automation for quick recovery and visibility.

My first decision point was choosing a cloud provider. I decided to go with AWS for the following reasons:

  • Leading the cloud market in terms of innovation and market share
  • Easy integration with the Serverless Framework for infrastructure infrastructure as code and continuous deployment.
  • The new release of AWS amplify — client side framework for integrating with all of AWS’s services. Heavily reduces the learning curve of entering the world of AWS.

I tried to rely on as much open source technology possible to loosen AWS coupling. The only thing we were heavily engaged with was Cognito for user management and an authorizer for our backend. The rest is based on Node.js, GraphQL, React, React Native etc. See our entire stack on Stackshare.

I found the Serverless model highly effective given the strategic decisions above. This allowed me to quickly spin up a single GraphQL endpoint in an AWS Lambda function which replaces the traditional API modeling. Having a single endpoint also makes sure the Lambda’s container is up, which almost eliminate all cold start performance issues.

Changes in the schema and required data from the client became a no brainer — simply change the GraphQL schema, automatically deploy it, and we’re good to go.

We ended up with the following architecture:

Kumba High Level Architecture

Now that our 3 web applications are stable, we started working on a React Native app. Adding another client is really easy given the single schema, backend entry point and AWS Amplify React Native SDK.

Also adding more backend functionality, such as emails and SMS, is ideally implemented in a Lambda function. Simply add the appropriate SDK inside the Lambda handler and that’s it. Switching from one vendor to another is done in a single place.

To sum up, choosing Serverless has been a well proven decision. In a matter of months we were able to release a stable version for our existing paying customers. I honestly think that serverless and current SaaS solutions allow startups to move fast and not reinvent the wheel every time. Moreover, this has greatly changed the required skill sets of an engineer. I believe coding skills are still in place, but familiarity with current services and how they integrate are even more important nowadays.