Bootstrapping with Serverless
Creating a business by bootstrapping requires a constant tradeoff of time and resources. Using modern cloud services, a bootstrapper can reduce up-front investment in technology infrastructure, and focus on product innovation with quicker time-to-market.
Serverless adds another layer of abstraction to cloud services. It eliminates many infrastructure management tasks such as server or cluster provisioning, patching, operating system maintenance, and capacity provisioning (yes, serverless does still have servers involved, it's just somebody else is worrying about them).
Abridge, as an example
Abridge uses various AWS services that are considered to be "serverless". These include:
- API Gateway is the proxy layer that enforces authentication/authorization and routes incoming HTTP requests to backend services.
- Lambda runs Abridge's backend code (application business logic, role-based access control, background collection jobs, etc) without provisioning or managing servers. We pay only for the compute time consumed - there is no charge when our code is not running.
- DynamoDB is a NoSQL database service that holds customer metadata and configuration. It's schemaless and pricing is either by on-demand or provisioned capacity mode.
- Cognito provides identity features that are used to manage users and authenticate against internal or external sources.
- CloudFront is the CDN layer that accepts inbound HTTP/HTTPS requests and caches responses from the origin.
- S3 is the origin for static web content, including the marketing website and the web application. It also holds data blobs segmented per customer, with data lifecycle rules applied for auto-expiration.
There are various other services involved, like SQS, SNS, SES, Route53, CloudWatch, CloudTrail, and GuardDuty. The AWS infrastructure is all managed with Terraform.
When it comes down to the code, Abridge was built from scratch, but there are various frameworks that will accelerate creation of a serverless-based application. For example, Chalice is specific to Python on AWS Lambda, the Serverless Application Model is a more general AWS framework, and Serverless Framework is a provider/platform agnostic solution.
Pros and cons
As with everything, serverless has tradeoffs. Positioning them strictly as pros or cons doesn't make a lot of sense, but there are a number of things to consider.
Without serverless, the cost of running Abridge would be significantly higher. Lambda's on-demand capabilities allows Abridge collectors to run only for the period of time necessary, rather than continuing to run while idle. If you architect your application well, cost should be linearly aligned with your customer levels, but it is something to monitor as your usage increases.
Scale is also something to worry less about. If the business grows, and the technology platform needs to grow, then it can grow. It may not be entirely smooth, and it'll probably need some attention, but it'll likely need less than on-premise or more standard cloud services. Similarly, high availability is generally easier (or taken care of for you) on serverless.
Debugging can be difficult, as serverless tends to give you less visibility into the underlying infrastructure and requires you to use provider-specific features to view logs and metrics. There's a range of tools available and this is becoming a solved problem.
Implementing longer-running tasks can be difficult. If your application can't be separated into shorter-running logical units then it may not be a fit for serverless.
Vendor lock-in is something to consider, but if you pick a reputable vendor that may not be a problem and it's not specific to serverless.