The “serverless” computing paradigm emerged back in 2014 in Amazon Web Services (AWS) as a new cloud service called Lambda — a serverless computing platform. During the short lifespan of 5 years, AWS Lambda became the most mature FaaS platform to date. Few other vendors like Google Cloud Platform and Azure joined the serverless marathon during later years, but AWS still holds a dominant market position.
Serverless is a different way of building and managing software systems, where the architectural model is shifted from running processes to running functions. It is an event-driven compute paradigm that leads to environment-friendly green computing. You just write and upload your code. Then define some triggers. An event triggers your code. Your server is going to be active only for the duration of an event – say, a fraction of a second, opposed to what we have now in non-serverless architectures.
Serverless Tooling Limitations
At the moment the most effective way to build serverless architecture is to pick one of the many serverless platforms on offer and take full advantage of all of its capabilities. The challenge is, low-level serverless building blocks provided by an abundance of platforms and open-source frameworks, require quite a shift in the developer mindset and a great deal of expertise, including an expanded effort to combine them into useful capabilities.
Given the newness of the serverless paradigm, the hard truth is that adoption is quite demotivated by the lack of tools available to embrace the power and full potential of serverless. This includes developer and operational team tooling and ecosystem support.
A recent survey indicates that more people are facing challenges around operations when considering going serverless. According to the survey results, the lack of tooling has become the biggest roadblocks in using serverless architecture.
At this point, technology enablers are expected to wrap real tools around existing low-level building blocks provided by popular serverless vendors, enabling faster serverless adoption. In fact, those tools play a key role in driving all industries to consider moving to serverless from traditional application architectures.
According to O’Reilly serverless survey 2019, most of the organizations use custom tools to manage serverless tasks. It could also mean that there is a larger market for new tools or improvement of existing tools as current tools are not addressing everything needed to properly manage and deploy to serverless infrastructure.
Nowadays a number of small players and startups are emerging in the serverless eco-system offering great tools to tackle all stages of serverless development. Although not very different from the traditional application development life cycle, phases in serverless development life cycle evolve in terms of characteristics and attention required in each phase. Tools specifically built for each phase can come to your aid once the application gains complexity.
Lack of tools hits harder on operationalizing serverless
Inevitably, the very first capability needed to build serverless solutions is a way to author function code. The default cloud vendor’s console is the starting point of serverless development, yet they don’t always offer the best developer experience. The bigger obstacles come later when you go through the development lifecycle, for instance during the testing phase.
On the same survey in 2018, while lack of tooling becomes a serious concern in serverless development, debugging, monitoring, & testing became the top three pain points developers faced with serverless. This clearly points back to a lack of tooling.
Proving that point further in the 2019 O’Reilly serverless survey indicates that developers are still struggling around serverless testing and debugging tasks.
Serverless testing is challenging
Moving from the traditional approach to serverless applications changes how the testing is performed. In a non-serverless world, developers often conduct local testing on application components the same way the application might be deployed in production.
But in the serverless approach as infrastructure is abstracted away inside the platform of the serverless vendor, it can be significantly more difficult to perform realistic integration or end-to-end testing incorporating production-like error handling, logging, performance, and scaling characteristics. Additionally, the inherently distributed nature of serverless applications makes it challenging to manage myriad functions.
It is recommended to perform remote testing, making use of the serverless platform directly. Few serverless vendors offer features to enable some remote testing possible but limited to individual function level testing, not at the application level.
Serverless debugging adds more trouble
Similar to testing, debugging remote code in the serverless world can be tricky. Due to the often stateless nature of serverless applications, one can say there is less to be gained in introspection and runtime debugging. Still, the serverless eco-system needs proper tools for run-time debugging which allows introspection and line-by-line stepping.
Debugging serverless functions live on the cloud is the future. The good news is that the next-generation development tools that make it possible to run serverless functions locally are emerging.
Serverless Tools of 2020
Identifying the potential for sophisticated tools in the serverless ecosystem, SLAppForge launched SIGMA; the first drag and drop serverless development tool back in 2018. SIGMA is a cloud-based hybrid IDE that facilitates rapid building, testing and deploying serverless applications.
As serverless continues to adapt and mature in upcoming years, testing and debugging plays a major role in the serverless ecosystem. Addressing the biggest pain points of serverless debugging, SIGMA was introduced with a new feature to live debug AWS Lambda functions.
Live debugging AWS Lambda Functions
SIGMA IDE has been providing the capability to test and verify your AWS Lambda code within the same AWS account before it is deployed as an actual AWS Lambda function. Enhancing this capability further, SIGMA is now capable of invoking these test executions in Debug Mode, so the developer can fine-tune and find any issues in the code without spending much time and effort.
When a function test is invoked in Debug Mode, SIGMA will give you a unique Debug URL. You can simply copy this URL and open it in Google Chrome. Once the Chrome DevTools Debugger is connected successfully with the AWS test Lambda environment via the provided URL, you have the freedom to debug the Lambda code; just like debugging a local application running on the browser, or any remote NodeJS process.
The demand for serverless will grow in upcoming years and serverless computing will be adopted on a larger scale by the community. And we will be witnessing an era of transformation of serverless tools as these technologies mature and more use cases become supported.