Serverless use cases — APIs
This article dives into serverless APIs, identifies key components and integrations to ensure best practices.
This is part of several writings about serverless. Previously wrote about what is serverless, design & technical trade offs, business benefits, market offerings comparison, service-full vs no-code, integration patterns: orchestration & choreography, voice apps and web apps. The idea is to go through scenarios to understand when and how to get the best of serverless.
Why serverless is a good fit for APIs?
Serverless is a good fit for APIs when: [3]
- You need elasticity due to unexpected workloads, particularly if they are open/public APIs
- Cost savings by paying for what you use and enjoying free tiers per month, ideal for startups
- Do not worry about infrastructure setup and maintenance
- Deploy globally close to your customers
What are the components of a usual API?
This is a a quick summary reference of the services.
- API Gateway: acts as a reverse proxy between the client and your serverless back-end compute.
- Functions: allocates computing resources when needed.
- NoSQL Database: stores data in a non-tabular way.
Solution design
The following diagram describes APIs using serverless components. Simple, really simple. [1]
How does it work?
- Clients make HTTP calls based on a contract, version and Service Level Agreements
- API Gateway takes care of requests / responses and cross cutting concerns such as authentication, throttling, caching, service proxy, security, performance optimizations, etc.
- You can also assign a HTTPS endpoint to the lambda by enabling the function URL directly without API Gateway. However, the trade-off is that you won’t have control of cross-cutting concerns and you can only have HTTP, meanwhile the gateway gives you HTTP, REST and websockets. [2]
- The lambda function is responsible for the business logic to process the API call. It can use DynamoDB for persistent storage as the function is stateless.
What about WebSockets? What is WebSocket protocol vs HTTP?
WebSocket is an event-driven protocol, which means you can actually use it for truly real-time communication. HTTP has constant request updates, meanwhile WebSockets provide a full-duplex communication channels over a single TCP connection, so in order to achieve this it needs a persistent connection between a client and server.
API Gateway supports WebSockets and charges per messages ($1.00 per million) and connection time established in minutes ($0.25 per million connection minutes).
How much does it cost monthly?
I have prepared a cost analysis for a HTTP API that gets invoked with 12KBs request and response is 46KBs. The function takes around 120ms of execution, up to 1536 MB of memory usage. Based on US East. I have changed to 60ms in the second case and to 512 MB in the third to understand the impact based on computing time and memory usage.
Conclusion
The main design principle and certainly an advantage is serverless APIs are based on event-driven architectures and not only from the runtime behavior but also from billing model. This pattern is able to support new developments but also act as proxy to existing back-end that you need to ‘strangle’.
References
- [1] AWS Well-Architected Framework, Serverless Applications Lens — RESTful microservices
- [2] AWS Lambda Function URLs vs. Amazon API Gateway. Finding the Right Fit for Your Use-Case
- [3] The benefits of a serverless API backend by Bill Doerrfeld
- [4] API Gateway pricing
- [5] Lambda pricing
- [6] WebSockets — A deep dive
Disclaimer
This is a personal article. The opinions expressed here represent my own and not those of my employer.
