Serverless is currently one of the trending topics out there in software architectural patterns. Because of the tremendous advantages, there's a significant tendency of switching to serverless among enterprise-level companies. There are many success stories out there and if your engineering teams are potential enough to make a great impact and wise enough to make the right choices, serverless might be a turning point of your journey to success. Before getting started with serverless application development, understanding of how the development lifecycle varies when moving to serverless is essential.
Serverless application development lifecycle: Is it really that different?
In traditional application development lifecycle, there are few main stages like Analyzing, Designing, Coding, Testing, etc. According to the application you’re going to build, these stages might be different. If we prioritize tasks of developing a serverless application, we can customize traditional application development lifecycle according to the serverless architecture.
Main phases of serverless application development lifecycle :
In this article, we are going to discuss how those phases evolve when it becomes a serverless application.
Rather than in traditional development, you may not need to spend more time to configure servers and manage backends. Your service provider will take care of the server infrastructure and you just have to focus on developing the rest of the application. When moving to serverless, there are a few important aspects that you should consider.
When selecting the right programming language, you have to consider the key characteristics of the language. An interpretative, dynamic and open source language is the best choice for serverless development. Then you have to think whether it is aligned with your development idea and whether your development team has the required language competencies.
Likewise, every provider has its unique set of features according to the market demand. You have to select a provider who fits your business requirements, system requirements and stakeholder requirements.
Let’s assume that you have to develop an enterprise scale application and you should develop both the application code and the infrastructure code together (infrastructure-as-code paradigm). Also, you need to run and debug your lambda functions locally. Then the best way to develop your application is to use a powerful cloud IDE. Even though there are many cloud IDEs, there’s only two that support serverless development: AWS Cloud9 and SLAppForge Sigma. Cloud9 is a browser-based IDE which supports in-IDE debugging, collaborative editing, direct terminal access and connectivity to many other AWS CI/CD services.
Since Cloud9 supports only AWS, SLAppForge released Sigma as the first purpose-built hybrid IDE for serverless application development, which supports both AWS and GCP. Unlike in Cloud 9, Sigma doesn’t need a VM/container as a backend, as it is 100% browser-based. In Sigma, developers can generate code and cloud resources via drag-n-drop as they build their application, with the IDE transparently taking care of creating and managing resources (buckets, queues, databases etc.) and configurations (permissions, trigger mapping etc.). In addition, Sigma supports many other features like built-in dependency manager, testing, log analysis and runtime statistics.
When it’s serverless, the build will be the same as what you are familiar. The build includes producing deploy-ready artifacts, unit testing for your infrastructure code, producing binaries and other files for your application and generating the deployment configurations. AWS provides a separate service, CodeBuild, to build serverless applications; whereas some other tools like Sigma IDE facilitate build as an inbuilt feature.
In traditional application testing, we configure a local environment similar to the production environment. However, when dealing with serverless providers, you cannot simulate the exact production environment because there’s a lot in the cloud which you don't manage. In some cases, you can use an unreleased version of the production application for test purposes.
Alternatively and as the best strategy, you can manage two separate, but identical environments for testing and production. In this article, we’ll primarily focus on managing a separate environment for testing. Once you have established the test environment, then the rest of the process is pretty much similar to the traditional path. In serverless application testing, we use most of the testing techniques uses in traditional development, but the effort might vary.
When considering serverless apps, unit testing and GUI testing effort are comparatively low and there are no significant changes from manual testing. However, integration testing needs more effort since serverless often involves thorough integrations, across application components as well as with external services. Scalability, availability, and performance of the application will be handled by the serverless provider, except for specific situations. Since we are developing a serverless application and our main focus is the functionality of the application, usually, there’s no need to worry about load testing either. However, if needed it’s not difficult to run those tests in the normal manner.
However, when it comes to troubleshooting, you would need to have a properly configured error log with all the traces. Since serverless functions are alive only during the code execution time, runtime state will be lost after the execution. So, it's really important to use real-time testing tools while testing serverless applications.
AWS introduces SAM Local as a CLI tool to test and debug Lambda functions defined by AWS SAM templates locally before uploading them to the Lambda runtime. The CLI can also be used to validate a SAM template, start a local API Gateway from a SAM template, etc. AWS console itself has a feature to test Lambda functions but you may experience difficulties when uploading large deployment packages and trying to use 3rd party dependencies in your serverless application. To overcome such drawbacks and provide a better experience for users, Sigma IDE utilizes its test framework by managing a test environment on AWS which allows developers to execute test events easily and provides real-time logs of test invocation results.
In serverless application development, we deploy our application in the cloud platform of the service provider. So the release stage is the most important stage of the development cycle. As we discussed in the Test phase, we should deploy two identical copies of the environment as Test and Production. There are different kinds of in-built deployment utilities provided by the cloud service providers, such as AWS CodeDeploy, AWS SAM, Azure Resource Manager; many other solutions are provided by external parties, such as Sigma IDE where you can easily deploy your functions to the production environment keeping everything in a single deployment stack.
This might be the longest phase of the process. There is a large number of services and functions in a serverless application. Since the benefits of going serverless come at the price of delegating infrastructure management to the cloud providers, you do not have access to traditional system metrics like CPU, memory and disk usage. However, with the accurate instrumentation of your supporting applications and services, you can ensure those metrics are under control. Mainly there should be a continuous back-end monitoring of the application considering the behaviour of the functions and the integrational changes since serverless apps rely heavily on integrations. It's your responsibility to identify flaws and execute a contingency plan to prevent anomalies. To drive your application on the right path you should collect data at the exact time your functions and resources are being used. Since you cannot practically keep your eyes on every single function of your application all the time, you need a real-time monitoring tool which provides full coverage and alerts you or takes contingency actions during issues or anomalies.
AWS provides a number of monitoring and security tools (other cloud providers may have similar tools) like CloudWatch, CloudTrail, X-Ray, and dedicated Amazon Machine Images (AMIs); where you can monitor configuration of your cloud, trace API calls, collect logs, create alarms for functions and configure them to trigger whenever the functions err out or get throttled and send alerts to you.
While your cloud platform has some monitoring tools, there are other third-party applications which also provide cloud monitoring solutions. Likewise, SigmaDash is the inbuilt monitoring utility of Sigma IDE, which enables real-time monitoring for functions and projects, real-time log tailing with SigmaTrail and provides statistical graphical representations for invocations, invocation duration, memory usage, errors, cost and throttles.
When moving to serverless, you may have to make quite a few changes to the application development lifecycle and may require different types of tools to define your serverless environments. For the past few years, all cloud service providers have been rapidly expanding their boundaries and enhancing their infrastructure offerings to cover all the stages in the software application development lifecycle. Besides, there are many other tools and frameworks which make serverless much easier. Therefore, keep aside the worries, empower your business with serverless and write your own success story!
Software QA Engineer at AdroitLogic and SLAppForge