Cutting-edge serverless technologies and old-school mainframes have more in common than you'd think: Each can be a black box that blocks deep insights.

With AWS Lambda, we get blue-green deployment out of the box. After we update our code, requests against our function would be routed to the new version. The platform would then automatically dispose of all containers running the old code to free up resources.

Serverless computing is a cloud-based application architecture where the application’s infrastructure and support services layer is completely abstracted from the software layer. Any computer program needs hardware to run on, so serverless applications are not really “serverless” - they do run on servers - it’s just that the servers are not exposed as physical or virtual machines to the developer running the code.

Like any other creation in progress or in the making, serverless applications, need to be tested and monitored. How else would you know if what you’ve created is providing desired results? Before putting your “newborn child” out into the world, you must make sure that it’s ready for the world. Software or even hardware of any sort will first be tested before it goes to mass production, and the same goes for your serverless applications.

AWS Lambda has a soft limit of 75GB for deployment packages for all your functions (including the layers you use). This might seem a lot, but a team that has fully embraced serverless can reach this limit very quickly.

I am a proud lazy programmer. This means that if I can automate a task, I will absolutely do it. Especially if it means I can avoid doing the same thing more than once. Luckily, as an engineer, my laziness is an asset - because this week, it led me to write an HTML scraper for our Changelog, just so I wouldn’t have to manually update the Changelog feed on our new app homepage (btw, have you seen our new app homepage? It’s pretty sweet).

I’m going to be biased in this post and it’s going to be ok because all the information you’re about to see are 100% correct and fair towards both services.

With AWS Lambda, we can deploy and scale individual functions. However, we as engineers still like to think in terms of services and maintain a mapping between business capabilities and service boundaries. The service level abstraction makes it easier for us to reason about large systems. As such, cohesive functions that work together to serve a business feature are grouped together and deployed as a unit (i.e. a service) through CloudFormation.

Don’t you just hate it when APIs are failing and you have absolutely no clue why? Now imagine you don’t have access to the VM, cluster or container where your software is running. Want me to continue with this nightmare? Yes, that’s what debugging AWS Lambda functions tends to seem like. A horrid nightmare of not knowing what is happening nor why things are failing. This article will show you a way of logging function invocations.

We recently released a new search key autocomplete feature here at Honeybadger. It was such a fun project that I just had to write it up for you all. Not only does it showcase an exciting use of DynamoDB, but it also shows the challenges of using Dynamo cost-effectively with large amounts of frequently-updated data.

In the world of web applications, Web Frameworks (WF) existed for a very long time. Traditional WF existed in a world without the notion of microservices, let alone the notion of serverless. Many first-time serverless users use WF to ease the transition into the ecosystem, sometimes unaware of its effect on the performance. The following post focuses on potential cold start issues when using WF in the NodeJS ecosystem.

With AWS Lambda, deploying a new version of our application has never been simpler. However, we still need to take care of some underlying plumbing. Such as managing the configuration for our functions as well as other related resources such as API Gateway, CloudWatch log groups and IAM policies. Depending on the event sources you would like to use, you also need to provision the necessary EventSourceMapping in order to use Lambda with the likes of Kinesis Streams and SQS.

AWS introduced Lambda Layers at re:invent 2018 as a way to share code and data between functions within and across different accounts. It’s a useful tool and something many AWS customers have been asking for. However, since we already have numerous ways of sharing code, including package managers such as NPM, when should we use Layers instead?

Smarter people than myself, once said that you should do things you don’t like first so that you can enjoy the things you’re doing later. Nobody wants cold starts. They’re annoying, and we continuously feel an itching sensation in our brains because of them. The serverless world would be a much better place to work in if they weren’t there.