Why Is Serverless Hard and How Can Thundra Help?
Serverless computing has become very popular over the past few years, since it lets developers reduce not only their code, but also their infrastructure. Serverless has a lot of benefits, like reducing costs, code, and infrastructure management, and that’s why many companies and developers are switching to cloud solutions like AWS Lambda.
However, for all the benefits serverless offers, it also introduces several new challenges.
Serverless Can Be Hard
When you first start to develop a serverless architecture, it can quickly become apparent that serverless is hard. Not only does serverless architecture require a paradigm shift from a technical point of view; it also obfuscates much of what a developer is used to doing.
Suddenly, tracing where code is going and testing code become much more difficult.
In particular, it can be difficult to track all of your various functions and services that are running everywhere on AWS and other cloud providers. The issue is this: when you run everything through an event-based architecture on the cloud, you, as a developer, have given over a lot of control about insights into the workings of your systems.
All of your function calls, cloud components, and systems get obfuscated and become difficult to trace, and even with the logging provided by AWS and Google Cloud Platform, it can be hard to figure out what is going on in every function. That’s why observability is one of the larger hurdles most developers deal with in serverless architectures.
Troubleshooting and Testing
Whether you’re using serverless or not, testing is a necessary step in development. Typically, developers test their code locally or on test instances of their application, which allows them to understand how it will interact on production. The problem with serverless infrastructure is that many of the components you need to test against are not local but are on your cloud provider, so as you deploy your code, you may get some unknown responses on how a function will integrate.
Even if you know that the code operates correctly, sometimes issues arise after the code is integrated that are difficult to test because what you need to test against is in the cloud. Thundra helps developers solve this with its real-time debugger. Using this, developers can still debug test their applications from their local IDE such as Microsoft VSCode or IntelliJ IDEA and see how their applications perform with cloud resources.
Serverless Can Still Get Expensive
One of the major reasons to switch from running on virtual machines to serverless is cost. You want to pay only for what you need, right?
In theory this is great. However, because of the structure of how you are charged for each API request, serverless can actually get very expensive. If your applications need to scale and are constantly pinged, there’s a good chance you may even end up paying more than if you had just set them up on virtual machines.
This isn’t always due to scaling. It can also be due to bad design or optimization of your code. For example, you might be consuming data streaming from Kinesis with your Lambda function, and a poisonous message makes your Lambda function retry hundreds of thousands of times until that poisonous data expires. If you don’t implement the best practices for this, you may face an unpleasant bill. In the end, it can put a major dent in your team’s budget.
How Thundra Can Help
There are drawbacks to serverless architecture, but that doesn’t mean you shouldn’t consider using it. Many of the benefits outweigh the negatives, and Thundra was developed to solve exactly these challenges. By providing the ability to easily trace your serverless architecture, creating a debugger that allows you to run on AWS live, and providing insights into costs, Thundra has eased many of the challenges developers face.
Thundra and Debugging
You may recall that the problem with testing and debugging issues with serverless code is that it’s hard to test how it integrates with the rest of your serverless environment.
Fortunately, Thundra has a solution for this, an online debugging tool that integrates directly with your IDE.
The debugger allows you to create breakpoints and then run the code live on the live AWS environment. This lets your team run integration tests without directly implementing the code.
This can all be done using the Visual Studio IDE. You’ll need to download the plugin and update your configuration. There’s a great walk-through written by a Lambda expert Mike Roberts that can help you if you’re having trouble configuring your plugin.
Thundra Reduces Serverless Costs
Developers are using serverless design more and more because it offers an opportunity to reduce costs, since you pay only for each function call and not an entire virtual machine, whether you’re using it or not.
However, serverless costs can creep up on you, and when your systems are designed suboptimally, this can lead to very expensive AWS bills.
To counter this, Thundra lets you easily look into function usage and cost and trace how the functions are used in the bigger picture. Thundra has also created an alerting system that can help you track specific functions and activities as the user-specified conditions are met.
Overall, these features let you see where you can optimize your serverless architecture. They can tell you, for example, where functions are taking a long time to run and thus possibly costing more, and can see where memory is poorly allocated. All of this provides valuable insights into how you can optimize your code.
Tracing with Thundra
One of the biggest challenges for developers using serverless technology is observability. If you can’t trace where calls are going and what is happening behind the scenes, it can be difficult to know what will be affected as you modify code.
This was one of the first problems Thundra set out to solve. To do so, Thundra developed a tool that fully traces your serverless calls.
In the Thundra application you can go to the Traces page and see information about where the code was invoked, when it was started, what other systems it interacted with, and whether errors were thrown, using Thundra’s distributed tracing engine, Otto, which can integrate AWS components like Lambda, SQS, SNS, Kinesis, and more. This lets you create customizable traces of your serverless architecture.
This ability to trace every action caused by invoking an endpoint lets you understand the entire infrastructure without all the abstraction. Using Thundra’s trace map, you can clearly see which cloud components are interacting with a given endpoint. More importantly, when there are errors, this map allows you to quickly pinpoint which component failed.
Compared to your typical serverless environment, this is a huge step forward. Instead of going through each component step-by-step, your team can quickly look at the map and assess the errors. In the end, this creates an environment without the challenge of observability.
Serverless Doesn’t Have to Be Hard
Serverless doesn’t have to be hard, and many of the downsides are quickly being mitigated. There’s a reason so many developers and so much hype are centered around serverless: it really does help simplify infrastructure and reduce costs.
Tools like Thundra give your team a much deeper understanding of what is occurring in your serverless environment. Thundra continues to improve and add features to help users test, trace, and optimize their code bases. This allows developers to focus more on their event-driven architecture and not to spend all day trying to figure out how to test code locally for something that will be run in a very different environment.
Serverless continues to help organizations around the world spend less time on infrastructure and more time on code. Don’t let a few challenges keep you from taking it on.
*** This is a Security Bloggers Network syndicated blog from Thundra blog authored by Suna Tarıyan. Read the original post at: https://blog.thundra.io/what-makes-serverless-hard-and-how-can-thundra-help