Importance of Tooling for Faster and Efficient Serverless Applications — Guest Post
After years of delivering and running high-scale, robust, and reliable applications on giant and complex infrastructures that we vigilantly maintained, someone told us that we didn’t need this capability anymore. Of course, I’m not talking about the applications that earn money on our behalf, or servers, which are hidden somewhere around the data centres. I’m talking about the need for maintaining servers. Someone with good intentions just wanted to take this burden off our shoulders.
Yes! We completely got rid of this need about five years ago. Back then, serverless wasn’t regarded as a suitable way of running high-scale applications. It’s time to confess, I agreed with this idea for a while. Throughout the years, cloud vendors and the serverless community have never stopped innovating, and have made serverless ready to develop any kind of application. Now, as a developer, you can build and run an airline application, an insurance company, and also a serverless monitoring startup like the one I work at a.k.a Thundra. (Yes, I somehow changed my mind about serverless around 2016.)
The shift toward serverless created another shift in the tooling decisions of software application teams. Since we don’t need to maintain the infrastructure anymore, we also don’t need to be worried about infrastructure level metrics, such as CPU usage, thread count, etc., to keep our customers happy. However, incidents still occur. To avoid them, we need to check new application-level metrics rather than old infrastructure-level metrics. P99 durations are more important now because we don’t want our serverless functions to time out. The frequency of 4xx and 5xx errors is important because we don’t want our customers to be down due to HTTP errors, right? Distributed traces gained significant importance over anything else because it’s almost impossible to understand asynchronous event-driven serverless applications without following their “trace” between serverless and non-serverless components.
Another revolution happened in silence. The tooling has forced and is still forcing its users to adopt new skills. Traditional ops people should now learn how to interpret traces, aggregate them with metrics, and even create manual spans programmatically. Tooling has shifted toward developers, and is now owned by developers. In this blog, I’ll try to cover sls-dev-tools and Thundra as the emerging tools for developers with a new serverless paradigm, and discuss the benefits that developer tools bring to application teams.
I remember the first time my dear friend Ben Ellerby told me about sls-dev-tools, how they fascinate me, and actually how I decided to write this blog post. Developers are there behind their computers checking their own development environments, and nearly all of them use a terminal for some purpose. Why would we require them to go back and forth to the browser unless they really need it? Remember the aim of introducing serverless in the first place: It was intended to speed up software development and provide the capability to deliver better applications faster. So, we need to eliminate any friction during development, including the time to check trivial yet important metrics, see the latest errors, or inject events to the Eventbridge event bus. We want this all to be possible right from your native working environment, without causing any context switch between the terminal and a distracting browser environment.
sls-dev-tools, maintained by a great team led by Ben, has the potential to replace any existing IDE plugins that fall short in addressing the real pain-points of developers. The application is completely open-source, and Ben’s team at Theodo is looking forward to the PRs and actively looking for issues to fix, striving to make it even better to help serverless developers.
I don’t like to brag about what we are providing to developers (and usually I don’t), but I’d like to quickly mention what we are trying to achieve with Thundra. Almost three years ago, Opsgenie engineers faced a real problem. This team of brilliant engineers placed great importance on understanding the behaviour of applications, and they faced an observability challenge when they stepped into serverless. They were too far away to have the visibility they needed for their monolithic applications hosted on EC2. Thundra’s services were intended to solve this issue by providing traces and aggregating them with metrics and logs for Java Lambda applications because there were no other tools able to do this at that time. Thundra has been available to the community for free since then, making sure customers have enough visibility for complex, event-driven architectures so they can sustain their health.
Throughout the years, we developed Thundra out of other runtimes, like Node.js, Python, Golang, and .NET, and added new core capabilities like real-time and post-execution debugging and application-level security with whitelisting/blacklisting policies. Our ultimate aim is to give relief to developers by replacing multiple tools that application teams have been leaning on with better tools, and by allowing them to use Thundra for free unless they have a real business.
Benefits of Adopting Developer Tools for Serverless
Thundra and sls-dev-tools are just two examples of developer tooling, and they’re both a result of the shift in the owners of the tooling in IT organizations. While originally Ops teams used monitoring tools, it’s now developers who have taken charge. There are many others that work toward the same objective of enabling serverless developers to innovate quickly. I’m fascinated by the surprising benefits that application teams take from these tools, and would like to list some examples.
The most expected benefit is that developer tools cause software teams to work even faster to reach the market. This is maybe the biggest promise of serverless: Focus on the value and deliver good applications faster. But there are still some problems that need to be fixed, such as visibility or cloud development. Tools like sls-dev-tools bring cloud development to the local development environment and make it more understandable by flattening the learning curve.
The second benefit is also somewhat related. Serverless allows us to test new product ideas, or to see how you can create a mobile version of your application. But still, there might be potholes on the road you need to avoid. You may need to debug your applications while you’re in the developing process, or even afterwards when you spot a silly mistake while giving your first demo to a colleague. Thundra helps with this by real-time and post-execution debugging. You can either pause the execution and simulate the different scenarios that your application can face, or just leave it alone and work through it after it’s finished.
The third benefit is the one that I most enjoy discussing, and also the most underrated one. Serverless tooling enables teams to onboard new engineers faster than normal, which I discovered while doing one of my regular check-ins with our loyal customers. They told me that they are very happy that they don’t need to dive deep into the issues with Thundra, which was a bit bittersweet for me because I always want Thundra to help in some way. But somewhat surprisingly, they then told me that they used Thundra’s architecture view and unique traces to onboard their new hires and interns, which I was relieved to hear. Complex architectures composed of several Lambda functions, third-party APIs, and managed services are really hard to understand by checking out the code and .yaml files (do you also feel goosebumps?). They told me that they can see different business-level transactions happening in the app, and see how components are connected to each other just by checking Thundra’s screen. We definitely didn’t imagine Thundra screens on a whiteboard to educate junior developers while in the building process, but it’s fantastic to know this is what’s happened!
Serverless is here to stay! This new paradigm changes application development in a revolutionary way, and also creates new fields for producing new tooling. Distributed tracing tools and architecture overview tools have gained importance to aid developers to understand how to use serverless applications for troubleshooting, rather than using giant screens to watch some metric charts. Developers require more developer-friendly tools like sls-dev-tools so they can work quickly and easily, without needing to switch contexts from serverless to their browser. This new normal will provide opportunities for developers to increase their ability to support their organizations in maintaining the application rather than just coding it. By incorporating the correct tools, companies can leverage the benefits of serverless and innovate faster than their competitors. Expect to see more innovation by the great serverless community in the future to address any other existing drawbacks of serverless.