A detailed summary of the hype around AWS Lambda and microservices, and how StdLib fits in.
StdLib is the easiest way to create, distribute and discover "server-less" web services. Check out our Registry of Services to get an idea of what's possible.
If you're new to the world of microservices, then you might not know what AWS Lambda is capable of. Here, we will jump into how AWS Lambda works and what some of its use-cases are.
The best way to think about AWS Lambda is as a way to create executable functions that sit in the cloud.
At the end of the day, all backend products are a collection of functions that yield certain responses. One of the advantages of AWS Lambda is allowing you to decouple your system into smaller services. These services are referred to as microservices.
This concept has been around for many years, known as Service Oriented Architectures.
It's become more popular recently as the advent of AWS Lambda and other Function as a Service (FaaS) providers has allowed developers to build distributed systems far more easily.
AWS Lambda functions can be invoked by an API call (with API Gateway), or by events within the AWS ecosystem. We'll discuss a few examples and use-cases below.
AWS Lambda has incredible scaling capabilities. Amazon has made sure that it can handle even the largest production loads.
Whether if it's being used for massively parallel DNA Sequence Alignment, a fully managed analytics pipeline or a scalable scraper, it can dynamically scale up or down depending on usage without you having to spend time on auto-scaling infrastructure.
With microservices, we can focus our time on building instead of scaling servers.
Like many platforms, AWS Lambda can be a bit abstract at first. AWS Lambda makes a lot more sense when you look at a few use-cases and architectures that it can power.
Below are a few popular and common ways AWS Lambda can be used.
Most service-oriented architectures have a main protocol to communicate between services.
HTTP(s) can be enabled for AWS Lambda functions using API Gateway, which gives your AWS Lambda function an HTTP endpoint for invocation.
This allows a UNIX-ification of services within your company to a point that you can have your teams designed around individual services.
You can separate image manipulation tasks into one service, have another service for tracking user in-app events, and another one for delivering SMS messages.
We're a bit biased here, since this is one of the main reasons we've created StdLib and its registry.
A common use-case for AWS Lambda is to act as a consumer on streams or webhooks coming from other AWS services.
StdLib is on a mission to create the standard library of the Internet. We believe there's a great opportunity to create incredibly distributed and scalable products using service-oriented architectures, without having to manage infrastructure.
AWS Lambda is a fantastic start, but it's just the foundation of what is possible.
We've built on top of their platform to offer a great set of features that make building services easier:
|Easily deploy functions via Command Line||Yes 👍||No 👎|
|Create HTTPS endpoints for each function||Yes 👍||Only through API Gateway 👎|
|Registry of services||Yes 👍||No 👎|
|Payload Capacity||128MB 🚀||5MB|
|Dev & Production Environments||Yes 👍||No 👎|
|Deploy functions via API||No 👎||Yes 👍|
|Pay per Usage||Yes 👍||Yes 👍|