An ever increasing number of developers and architects are using AWS Lambda to deploy serverless functions to control costs and reduce the burden of server management. Due to the unpredictable nature of end-user demand in today’s digital-first world, Lambda functions can help resolve unplanned scaling issues.
The way we build software products changes all the time. Serverless architecture opens up new opportunities to create awesome products faster. Not only that, serverless applications are more scalable, secure and maintainable – all with much less code. Serverless is the future of development and you should get ready for it. But what does it mean to be a serverless developer? What do you need to understand before jumping into the serverless pool?
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.
