We’re very pleased to announce the official launch of our new Java tracer for AWS Lambda. This release extends Lumigo’s real-time monitoring and observability tools to all JVM-based AWS Lambda applications, with support for Apache Groovy, Scala and Kotlin among others.
Deploying a basic Serverless application has been made easy with the abundance of frameworks out there. If you’re part of a small team or working on a relatively simple project, setting up a basic serverless CICD process is also pretty straightforward, since there is plenty of information on the subject. But when a Serverless application grows it can get very complex very fast.
One of the basic ingredients of any software is that before you deliver it to the end user you want to make sure that it works properly. The question is how we need to adapt our approach to testing to take account of the cloud-based, highly distributed nature of serverless architecture.
Back in 2017, I wrote a post titled “3 pro tips for Developers working with Kinesis streams”, in which I explained why you should avoid hot streams with many Lambda subscribers. When you have five or more functions subscribed to a Kinesis stream you will start to notice lots of ReadProvisionedThroughputExceeded errors in CloudWatch.
Welcome to the second edition of Serverless from the Trenches, our series of bite-sized blog posts aimed at developers and DevOps working in serverless. Each article will focus on a different technique or tool to solve a real-world problem and – hopefully – help make your work in serverless more productive. This week we look at how to add Cognito to your integration tests flow, making for true black box testing.
Some time ago, the Register published an article titled “Lambda and serverless is one of the worst forms of proprietary lock-in we’ve ever seen in the history of humanity”. It received a lot of attention, and vendor lock-in has become a perennially popular question at conferences. But I’m here to tell you that you are probably thinking about vendor lock-in all wrong when it comes to serverless.
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.
