When you’re working with EC2 or containers, VPCs have long been viewed as a must-have. Without them, you will face a constant barrage of attacks aimed at your infrastructure and OS, such as brute force login attacks. But are VPCs still needed when it comes to AWS Lambda? What do you actually get when you put a function inside a VPC? And what are the downsides?

It’s time to talk about the everyday challenges of serverless. Whenever I scroll through the latest blog posts on serverless it feels like there are only two types of problems in the field: how do I get started and how do I architect my solution. But what about all the day-to-day problems that developers and DevOps encounter when dealing with serverless? From simple deployment issues like protecting your stack from deletion to stress-testing your solution using serverless techniques.

LaunchDarkly has built an impressive feature flag management system that overages more than 200 billion feature flags per day. It has helped companies implement continuous deployment, A/B testing, infrastructure migrations and much more. It also enables canary launches (or dark launches) through its built-in support for percentage-based rollouts.

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? In this post, we will look at how Lambda Layers works, the problem it solves and the new challenges it introduces.

Lumigo VP Product Avishai Shafir rounds up the most interesting talking points from the three-day Serverless Architecture Conference, held in The Hague, Netherlands.

If you look around the Serverless Application Repository console, you will find a number of applications that can help you ship logs from CloudWatch Logs to external services. One such example is the LogzioCloudWatchShipper application below.

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.

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.

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.

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.