Serverless has been a consistent focus for AWS, and so far this year is no exception. Every year at re:Invent, AWS announces endeavors that will make an impact in the coming year’s cloud focus, and creating serverless options in existing services was a big part of that.
Here are some highlights from AWS’ recent serverless announcements:
- Amazon DynamoDB On-Demand
- Amazon DynamoDB Transactions
- Amazon API Gateway Web Socket
- AWS Lambda + Application Load Balancer
- AWS Lambda Custom Runtimes
- AWS Lambda Layers
Amazon DynamoDB on-demand is an announcement that has many in the serverless community excited, as they feel it finally allows users to build a truly serverless application from end-to-end. Previously DynamoDB was considered the best database option if you were going serverless. However, you still had to understand what the traffic to your site would look like, the traffic to each DB you had (if more complex), and then determine the desired read and write capacity for each. You still had to “tune” your DynamoDB to get the proper performance under production load. This was not only inconvenient, but for many startups it could also create a worst-case scenario which could botch a big event with lots of traffic to an application or site. Those concerns are no more.
This new feature in DynamoDB will also be useful in the enterprise market. On-Demand can offer help for businesses that need a very close matching of traffic and provisioning on business-critical tables. Furthermore, it also lowers the barrier of entry to use DynamoDB, as pay-per-use is often easier to get approved for testing/development. DynamoDB on-demand is now available for any new table you create either through CloudFormation or from the console.
Despite the benefits, there are a few concerns with DynamoDB On-Demand. The biggest one is that with similar usage, you might end up paying seven times what it would cost provisioned. Ideally once you have a good idea about your traffic to a DB, and assuming this traffic has a set pattern, it will always be more cost effective to provision. However, On-Demand is still a very welcome addition.
You can learn even more about DynamoDB On-Demand by playing with it or reading this awesome blog from Alex DeBrie.
Another Amazon DynamoDB related feature is the support for transactions. That is, all or nothing reads and writes, as well as idempotent writes. These new additions bring DynamoDB closer to more well-established databases and will help users that have the need for more guaranteed reads and writes.
You can look at how to implement transactions as well as more details from the AWS Documentation on DDB Transactions.
A new open source virtualization platform from AWS, Firecracker will soon be powering all containers, and by extension all lambdas, running on AWS. With the potential to drastically reduce cold start times, as well as reduce costs for containers and lambdas across the board AND increase performance, Firecracker is already working its magic on ECS Fargate. It has also delivered some big cost savings.
API GateWay(APIGW) now supports web sockets. This is an interesting development that will bring serverless and Lambda to what used to be exclusively EC2 territory. Web socket clients will now be able to maintain a web socket connection with API gateway and the typical web socket events can trigger specific lambdas to react to these events. This in turn should help simplify the build related to lightly interactive sites such as teaching websites and quizzes. While you’ll still be mindful about what kind of application you are building ( as there will still be cases where EC2 instances might provide a more cost-effective alternative) this is an exciting development. When combined with DynamoDB on-demand this service could also potentially offer the ability to have stateful serverless backends, again making it easier for certain niche applications to transition to serverless.
You can find out more about APIGW web sockets here.
AWS Lambda is now a supported endpoint on application load balancers. This opens up the door to interesting hybrid web application architectures. Users could realize cost saving by using Lambda to serve certain lower traffic and low intensity parts of their application while using EC2 instances to serve the more complex systems. This again lets users dip their toes and realize some of the cost saving from Lambda without having to redesign their application from the ground up.
You can find out more about this new ALB feature here.
AWS Lambda now supports custom runtimes. This particular announcement is expected to convert many users that were reluctant to move to serverless development due to the undertaking of having to re-write codebases in one of the supported languages. In this case Lambda will now support any programming language that can be compiled to specific kind of binary and can be run on Amazon Linux.
Custom runtimes have been so popular that in the less than 2 months since announcement at re:Invent 2018, a plethora of new runtimes for Lambda have been released and are ready to be tested by Lambda users. Some examples of runtimes that already exist and are ready to be tried include:
Creating a Lambda custom runtime however is something any of us can do. So if you don’t see what you are looking for you can go and create a custom runtime yourself. The sample process for the C++ custom runtime for amazon can be found here.
AWS Lambda Layers is probably the most exciting announcement when it comes to helping users transition to serverless with greater ease. It creates ease of use around AWS Lambda while eliminating a big quirk that has often annoyed more seasoned developers. Previously each Lambda function had to be packaged with all the functions it needed to run, as well as all third-party libraries. If you had two Lambdas with overlapping functions or libraries, you could not share the resources. For Lambdas using large third-party libraries this would lead to annoyingly long deployment times.
Lambda Layers will also enable easier movement of monoliths to serverless. With Lambda Layers it is much easier to make calls to legacy business logic in a layer containing the monolith, while still getting the benefits of running certain functions in a serverless fashion. This combined with the new very long Lambda execution times means that a Lambda could potentially house a whole monolith.
Lambda Layers will also be a resource to custom runtimes. With many lower level languages requiring more scaffolding, Lambda Layers will be very useful to keep codebases written in lower level languages cleaner and more contained to follow the best practice of single business function per Lambda function.
With all these new offerings, it will be a great year for those looking to finally make a move into the serverless space on AWS. Furthermore, with the improved ease-of-use, and lower barrier of entry for enacting serverless services, we anticipate that the demand for serverless services on AWS will only grow from here.
To learn more about Onica’s serverless, cloud native development offerings, watch our on-demand webinar.