Skip to main content
Image
blog-cover-serverless.jpg

Directing Serverless Testing in Production

article publisher

Shilpi

Generic

Testing is essential earlier to the launch to assure the correct functioning of hardware, software or any other product under development. Testing keeps the confidence intact of the team when a full-fledged tested serverless application is launched into the outer world. Analogous to any other system in the world it is indispensable to test and monitor the serverless applications after they are created.

Considering the cons of a non-tested application, for the sake of making sure the serverless applications are working the same as they should be. Appropriate attention needs to be taken while performing the testing of serverless as these are the systems with complexity. This complexity gradually increases as moving ahead with the code. In addition to that, successfully performing earlier testing stages does not mean that nothing could go wrong as the application enters the production. 

In this article, serverless testing in production is the focal point and we will be discussing the techniques that can be followed for successful managing of testing serverless in the production environment. But at the very first, let us be aware of what is serverless architecture is?

What is Serverless Architecture?

The term ‘Serverless’ first appeared in around 2012, in the article “Why The Future Of Software And Apps Is Serverless” by Ken Fromm.

Illustration image showingIcons representing laptop, housekey, cylindrical shape, cube placed on top-half and bottom-half to explain serverless testing
Source: Hackernoon

Also, titled as Serverless computing or Function as a Service(FaaS), serverless architectures are the event-driven application design patterns that integrate third-party Backend as a Service (BaaS) and encompasses custom-codes running in a managed and temporary containers on a FaaS platform. All in all, it eliminates the requirement of traditional server software and hardware management by the developers. The word serverless was first seen in an article published in the year 2012, ‘Why the future of software and apps is serverless’, by Ken Fromm.

Serverless shifts the focus towards the application codes of individual functions. Services like Microsoft Azure Functions, AWS Lambda deals with the physical hardware, virtual machine OS and web server management. The only thing that is to be concerned about is the code. Serverless architectures are at aid with the reduction in the operational cost, engineering lead time, at a price of increased vendor dependencies and unfinished services support.

Check out the comprehensive guide on serverless for an in-depth understanding

Serverless Testing Stages Earlier to Production

Either writing a fresh code or fixing a bug or implementing a new feature into the product, it is imperative for the code to go through a list of testing phases. Testing will assure whether the written code is working as per the expectation or not. 

The following are the testing phases for serverless to be performed before it enters in the production environment. 

Illustration image showing the famous testing triangle drawn with a black colour outline for the serverless application having three divisions with a unit  test at the base covering the larger area, integration testing above that and at the tip of the triangle is present the end-to-end or manual test
Testing Triangle | Source: Hackernoon
Sample square image representing a square subdivided into four more squares outlined in black color showing the testing importance in the cloud and local environment with divisions as acceptance, integration and unit tests
Source: Hackernoon

Local Tests: In accordance with the application and the serverless vendor, testing of the serverless app can be done locally. It facilitates paced affirmations ensuring the serverless application or the code is functioning as planned. The most basic and significant step for the former mentioned is writing more and more unit tests.

Unit Tests: The majority of the complexities in a serverless application revolves around how a function connects with the external services which lead to the fact that there is a less need for unit testing of the application. If there appears any complex business logic then placing the logic into its own module is considered as the best way to test anything as a separate unit. Jasmine, Jest, Mocha is the few unit testing frameworks that will make the unit testing process more simplified. 

Integration Tests: As the name states, integration tests usually deal with the errors or issues that arise due to the interaction of code with the external services. S3 or DynamoDB are stubbed or mocked in order to take the integration testing forward. 

Acceptance Tests: The earlier phases of serverless testing brings out the issues in the code. In addition to that, there might be cases of misconfiguration, for example, no identity and permission management setup permission to the functions, API gateway event source not configured together, to name a few. With the purpose to assure flexible and end-to-end working of the function, it is recommended to work on the functions after they have been deployed.

UI Tests: The direct interaction of a UI client with a serverless application makes it vital to perform the changes in the application as per the needs of the client. Most of the UI test is performed manually. When done using automation, frameworks like Selenium are the best.  Besides, the QA team uses AWS Device Farm, Automated Visual Tests are done to perform a perfect UI experience to the client.

Serverless Testing in Production

The early testing phases does not assure that there will not be any issue occurrence at the time of production. There can be something that will create any mishappening at the time of the production. For instance, the breakdown of AWS can impact a serverless application significantly. Furthermore, the dependency of a serverless application on many external services may disrupt the smooth working of a serverless application. The undue load can also question the scaling of the serverless.

To come up with a high-performance serverless application, everything has to be tested in production with utmost care. A series of controlled management practices will ensure the proper functioning of a serverless application.

Five emerging techniques that can be used to manage serverless testing in production: 


Feature Flags ‘In Effect’ 

Illustration image showing a feature flagging diagram with a new feature as a blue colour cube, one toggle on/off button switched on in green color and other two toggles on/off button is switched off stage and customer faces in various colours
Source: Atlassian

With Feature flags, a business can set up the date for the release so that the code can be shipped into the production. It is also called as ‘Feature Toggle’, allowing to easily turn on/off the features of the application. The intention of applying Feature Flags is to determine the users of the new upgraded feature. It assists in finding who should be using the new feature keeping it hidden from the rest of the mass. This allows developers to test everything earlier to the major rollout. Along with this, it facilitates efficient testing of the self-changes made by them in the application. LaunchDarkly is effectively using Feature Flags on a full-time basis. It is recommended to construct a Feature Flag with a user interface so that it does not limit the internal teams' usability internally.

Deployment with the Canaries

An illustration image showing the canary testing scenario in which a small subset of users is shown in black colour, a router with the signal in black colour, three white laptops in the green background working on old version and three white laptops working on the new version of the application
Source: Techtarget

The canaries are frequently being used in association with feature flags. With canary, teams can follow the staged rollout sessions performing testing earlier to the code shipment into the production. It is all for the firm deployment by not knowing what it is going to run in the end. Companies, namely, Nginx, Buoyant are doing canary deployment as a part of their service mesh. 

Staged Rollouts

Similar to its definition, a staged rollout is a type of canarying with a staged component in spite of deploying to a specific spatial part. Charity Majors, co-founder, and CEO of platform-agnostic DevOps monitoring tool Honeycomb.io state, when a canary is set to 10 percent of the complete production. Automation is done so as to compare the 10 percent against the rest of the system. No errors mean fostering deployment to 25 percent and on the reverse side if there occurs any issue, the system would either revert to pre-deployment or similar to staged rollout, it will do the rolling revert. He further adds, not many problems are seen in the case of low-levels of deployment. Problems arise with the scaling of the applications. 

Measuring Substantially

It is a matter of delight for the teams when the code shipped into the production behaves as per the expectation. It draws the major concerns if the teams are confronted for the malfunctioning of the application of the code. Therefore, it is indispensable to monitor, measure and capture the performance of the code, the system more often. Organizations are moving past to offer comprehensive solutions for the instrumentation. Considering the notion that the size and workflows of the serverless are quite large as a result of which it is not possible for a single architect to measure the complete system. Therefore, a richer set of tools are required to assist the production time management.

Observability  ‘A Flagship’

This is the freshly appearing paradigm ensuring the test-driven development in the organization. This new paradigm is called the observability-first paradigm in which the engineering team maps out the outcome from the feature or workflow, application or staged rollout. Before proceeding with the coding, the team creates an instrumentation toolkit to monitor and measure the match of the development and deployment with the initial objectives. If it gives the green signal then only the process is taken further. 

Various Tools to Debug Serverless Applications


Dashbird 

Illustration image showing a Dashbird detection board representing the health of an application with a graph
Source: Dashbird

Dashbird is a widespread monitoring tool that offers solutions for an AWS Lambda application. It majorly detects Lambda specific failures, like, memory issues, runtime errors, misconfigurations, exceptions, to name a few. It associates with AWS to offer insightful level metrics for cost optimization, performance, and resources. 


IOpipe

Illustration image showing an IOpipe dashboard showing function invocations as graphs in blue and yellow colour
Source: Techcrunch

IOpipe offers the full picture of what actually an AWs lambda application is doing with frequent notifications appearing on slack, email, webhooks, etc. It offers high-resolution real-time metrics along with the alert, error aggregation, profiling, and tracing.


SignalFx

An illustration image showing a dashboard of an SignalFx tool with the status of different functions in blue, green and pink colour and horizontal bars
Source: SignalFx

An AWS Lambda, Google cloud, and azure functions monitoring tool, SignalFx provides real-time visibility and performance of the functions, cost optimization, cold detection, memory execution, and usage, low latency metrics, etc. 
 

Thundra

An illustration image showing trace charts, invocation metrices, duration and count chart in avertical bar graphs in blue and red colors
Source: Thundra

Thundra basically keeps the track and profiling of an AWS Lambda based application with least overhead. Data filtration and advanced search, advanced debugging, detailed and configurable tracing, Dynamic instrumentation, etc. are the few features of Thundra.
 

Amazon Cloudwatch

Illustration image representing the complete flow of an Amazon Cloudwatch as Collect, Monitor, Act and Analyze with diagrams in black color which are covered with an orange outline
Source: AWS

The freely available Amazon Cloudwatch assembles both the fundamental and the custom Lambda metrics. It ensures the easy collection of all the AWS data from a single platform in bringing the complete visibility of the resources.

Check out various tools that are helpful for serverless implementations

Conclusion

The development or creation of a Serverless application is just the same as the development of any other application. Therefore, it is suggested to test it before it goes to mass production. It is always advised to think about the test techniques, strategies that can be followed while doing the testing of a serverless application. When the code is sent into the production, testing does not stop there. 

Even if the testing of serverless is done numerous times, things may get really bad or negative when sent to the production. Therefore, it is imperative to follow a few tactics, strong monitoring and error reporting for your applications,  for the successful testing of serverless in the production environment. 

Subscribe

Ready to start your digital transformation journey with us?

Related Blogs

In conversation with Danish Usmani, CEO, OpenSense Labs

danish-interview-osl.jpeg

In a year-end interview, CEO Danish Usmani showcases OpenSense Labs' achievements, emphasising new client partnerships and…

Why should you prioritize lean digital in your company?

Untitled%20design%20%281%29.png

We are living in an era where the change and innovation rate is just so high. If you want your organization to reach new…

How to measure your open source program’s success?

Untitled%20design%20%282%29%20%281%29%20%281%29.png

Along with active participation, it is very important to look after the ROI of open-source projects, programs, and…