55000+ attendees with 100+ products and services announcements make AWS
re:Invent 2018 one of the largest tech events. It was a big event for
serverless in general where AWS Lambda continued to be the top trending
service from the event.
Here are 5 key releases/upgrades in the FaaS world along with my notes of when
to use it and when not to:
1. Invoke Lambda from Application Load Balancer (ALB): You can now expose
your Lambda Functions as an endpoint through ALB. This is an alternative to AWS
API Gateway where your Lambda can be triggered when a request matches a given
When to use it?
· Organizations that are migrating their workloads or have a mix of
(micro)services that operate in serverless and non-serverless services will
greatly benefit from a simple ALB setup.
· If you were considering an alternative to AWS API Gateway be it for cost
and/or setup and execution overhead, and/or their 30 second
you now have options.
When not to use it?
· If you were looking to migrate from API Gateway to ALB only for cost, consider
that you might need to setup a ALB health check, which in this case will
constantly ping your Lambda. Depending on your use case, you might be able to
get away without setting up a health check though.
· If your endpoint requires authentication/authorization/caching/throttling then
go with API Gateway.
2. IDE Integration: AWS toolkit now enables deeper integration in your
favorite IDE. The toolkit has not been released to the VS Code marketplace, so
in order to try it you must build and run from
· Invoke your Lambda’s w/o leaving your IDE.
AWS Toolkit Integration in VS Code
Execute Lambda in VS Code
· “Deploy Lambda Function” isn’t functional yet. Also what you get is a list of
Lambda’s and if your account has 100’s of them, it is painful to scroll down to
“your Lambda”. To be fair though, this is an OSS project so expect things to
3. Lambda Layers: Layers is a packaging solution for your Lambda
dependencies including common libraries and/or custom runtime. Your Lambda can
reference Layers created by you or use public* Layers* published by AWS and
other AWS customers.
· If you want to save on your deployment packages size and/or bandwidth.
· Package your runtime as Layers.
· If your runtime has a package manager, having your dependencies deployed
independently causes more harm than good. Your CI/CD pipeline, unit tests, local
debugging will now require pulling these packages (*Layers) *that are outside
your package manager. If you already have a CI/CD pipeline for deploying
Lambda’s you might as well as skip this announcement.
4. Bring Your Own Runtime (BYOR): You now have the ability to bring your
to execute your Lambda function.
· Author your Lambda functionality in
Rust or bash.
· BYOR means someone from your organization is taking the responsibility of
managing the runtime and that includes
updates/patching/versioning/testing/deploying your runtime on Amazon Linux
image, which in some ways is antithesis to the whole serverless paradigm.
. Ruby 2.5 is now available as a runtime for your
so you can use it without packaging your own layer.
5. Firecracker: Firecracker is a virtualization technology that is
purpose-built for creating and managing AWS Lambda’s and this is now open
source. Firecracker allows
you to create minimalist-designed micro VMs with boot time of 125ms, which blurs
the lines between VMs and containers. You can spin up 4000 of them one
showcases how AWS scales your Lambda’s.
· It is too early to say — If this becomes more of an industry standard to run
FaaS workloads, more scenarios become possible (vendor lock-in becomes less of
a concern, run mixed workloads helping with transitions between on-prem to
cloud), so stay tuned.
Note: The current OSS version runs on bare metal on AWS (nested virtualization
is disabled) and on Intel architecture only.
· Not ready to run your production workloads, yet! Check out this talk: AWS
Lambda under the hood to learn
about the complexity of operating your AWS Lambda’s at scale.
· It is built on top of
KVM, so you cannot
develop or run it on macOS natively
is your option).
At Re:Invent 2018 we saw customers sharing their use
of how they are successfully running production workloads using a healthy mix of
serverless services. There were also a breadth of
announcements making serverless services
more deeply integrated with the rest of the AWS ecosystem. ALB Integration,
BYOR, Lambda Layers and IDE support makes FaaS and in general serverless go more
mainstream than ever.
Originally published at https://medium.com/@suryaj/analysis-of-5-key-faas-announcements-at-re-invent-2018-f73b417b83f0.