Serverless solutions are making inroads in every organization’s technological stack, thanks to the growing popularity and use of services like AWS Lambda and Fargate. Serverless adoption has become a panacea and attractive choice for DevOps businesses to suit their specific requirements. Before developing a serverless strategy for DevOps, let’s consider a few questions before considering a big move to serverless.
Increasingly, serverless computing has become part of the CI/CD process, yet many organizations find it difficult to implement DevOps with serverless applications. It’s important to understand how DevOps fits into the serverless framework before embarking on a serverless strategy for DevOps.Â
With a serverless approach to DevOps, as opposed to a monolithic or cloud approach, you deploy code into the cloud and automatically execute it. With serverless computing, server management tasks such as OS updates, fault-tolerance, scalability and monitoring, are no longer DevOps’ responsibility; that responsibility now belongs to your cloud vendor. You don’t have to worry about renting or purchasing servers, hardware scalability, monitoring, or capacity planning since your provider will care for all the underlying infrastructure your app requires.Â
Serverless computing automatically provisions and configures the server as needed to execute your code. It will automatically scale up the required server resources as needed and scale down when they are no longer required. Serverless computing can even locate a function within a container close to the customer’s geographic region; thereby, improving performance through lowered latency. Serverless architecture also allows you to transition from one version of your code to another or run new and old versions of the same code simultaneously, with minimum service disruptions and the flexibility to roll back modifications as needed.
But what is left for DevOps to do? Serverless computing still requires CI/CD pipeline and maintenance operations. Your operations staff will still be responsible for function installation, testing, versioning and performance monitoring. The basic strategies for deploying functions still involve deploying the new code to the customer and rolling back the code if necessary. Testing will only include access to specific instances for executing and testing functions, which reduces costs because you pay only for the time it takes to run the test. Test instances are closed automatically. On the other hand, your developers must break down each application into independent, auto-scalable functions that the serverless provider can wrap into a container that can be monitored, cloned, and distributed to any number of servers as needed.Â
See More: Why a Data-Centric Approach Falls Flat for Businesses Processes
Questions to Consider Before Leveraging Serverless Computing in DevOps
Even if you have a DevOps strategy in place now for your monolithic or cloud application, there is no guarantee that moving to a serverless platform will give you the performance you require to meet your business goals. Before considering a move to serverless, you should have answers to the following questions:
What are your SLIs/SLOs for serverless computing?
Your focus in determining your service level indicators and objectives for serverless computing should be: What is the most important feature we can deliver to our customers? Once you have determined what SLIs/SLOs you will need to fulfill your next goal for your customer, you can then decide whether serverless computing will suit your use case.
Running any app in the cloud leaves you dependent on your cloud vendor’s capabilities to meet your performance goals, so you must know what performance to expect before you can commit to a serverless platform. For example, If you are building a mission-critical system, you may want to look into additional ways to guarantee a certain level of service. You must also consider, for example, the service level requirements will be met or not if an availability region goes down. What guarantees will you have if your vendor closes operations down entirely?
Which serverless platform can best meet your DevOps goals?
Before you begin developing your serverless applications, you need to determine which cloud vendor will provide the best platform for your particular application and approach to DevOps. As shown in the descriptions below, each vendor’s serverless service takes a different approach to DevOps.Â
While there are several serverless options to choose from, four popular examples illustrate some of the differences among the various platforms.Â
AWS Lambda
AWS Lambda follows the event-driven approach. It is offered as a service for serverless computing with other AWS services or via an API. Lambda executes code in response to an event, such as an HTTP request or by an AWS service such as Kinesis or DynamoDB. It automatically scales resources (such as memory, CPU, and network configuration) up or down as the number of events rises or falls. It also takes care of patching, logging, and function monitoring.Â
A Lambda function is invoked in a container per the configuration provided by the developer. A set amount of memory is allocated per function. Users have no control over the containers as Lambda handles all commissioning and decommissioning of the containers internally. Lambda supports applications written in the following languages: Node.js, Python, Java, Ruby, C#, Go, and PowerShell. The execution time for a Lambda function is restricted to 300 seconds. Use cases for Lambda include data processing, stream processing, machine learning and application backends.
Azure Functions
Microsoft’s Azure Functions supports various event triggers, timer-based events for tasks, OneDrive, and SharePoint, which can be configured to trigger operations in functions. Triggers can also be created in other Azure cloud services and HTTP requests. Support for real-time data and files lets you create serverless bots that use Cortana as the information provider. It includes the Logic Apps service for creating visual design workflows and orchestrating Functions activities. Azure Functions integrates seamlessly with Visual Studio Team System (VSTS), Bitbucket, and GitHub. Functions can be written in C#, F#, PHP, Node.js, Python, and Java. It also supports bash, batch, and PowerShell files. Azure Functions allows ten concurrent executions per function with a maximum execution time of five minutes per function.
See More: Modernizing With Serverless? Know These Things Before Starting Your Journey
Google Functions
Google Functions support internal event bus triggers and HTTP requests, which can respond to events such as GitHub WebHooks, slack, HTTPS requests or Firebase analytics events. Included is a provision for autoscaling as well as monitoring, logging and debugging capabilities. Deployment is supported through Zip upload, cloud storage, and cloud store repositories, while the event source is supported through cloud pub/sub or cloud storage objects. Google Cloud’s Stockdriver manages the logging of function executions.
Google Functions supports six different languages with the following runtimes: Java 11,.NET Core 3.1, Ruby, Node.js (8, 10 and 12), Go (1.11 and 1.13), and Python (3.7 and 3.8). Use cases include application backends, real-time processing, virtual assistants and machine learning.Â
Apache OpenWhisk
Apache describes OpenWhisk as “an open-source, distributed Serverless platform that executes functions in response to events at any scale.†OpenWhisk builds its components using containers, supporting deployment within an on-premise data center or various Cloud infrastructures. OpenWhisk manages the infrastructure, servers and scaling using Docker containers. It works similarly to the other vendors’ serverless platforms. Functions can be written in Go, Java, NodeJS, .NET, PHP, Python, Ruby, Rust, Scala, and Swift.
Which application framework should you choose?
After selecting your cloud provider, you will need to choose your application framework. Serverless computing requires a specific approach to coding, which requires a specific framework. Framework products simplify and automate the development of serverless applications. Depending on the programming language you choose, there is a framework available. For example, for JavaScript there is Apex, ClaudiaJS, and Gordon; for Python there is Zappa; and for Go there is Sparta. In addition, Azure, Google Cloud and AWS offer event-driven DevOps tools that do not require server set up or management.
How will you manage deployment and change management?
Applications operate in stateless computing containers that are event-triggered and ephemeral in a serverless environment. Developers have limited access to the underlying infrastructure because cloud providers totally maintain these containers; especially, you cannot monitor the behaviour of apps at the operating system level. Rather, business logic and settings are kept in the same repository. To deploy or rollback your code, you’ll need a declarative tool like Terraform or Cloudify, which allows you to provide cloud platforms using a declarative description of the services you’re using and how they’re connected.
See More: Low-Code Automation: How Businesses Can Avoid the Pitfalls
Will your governance and security requirements be met?
With serverless computing, your DevOps team no longer has control over the functioning of the backend infrastructure. While you can monitor its performance from the log output, you are limited in how you can customize it to suit your processing needs. Your team will need to set up centralized monitoring with real-time alerts and conduct periodic audits of infrastructure availability and performance.Â
By delegating server management to the cloud vendor, you are also delegating server-related security capabilities. In the end, the developer is ultimately responsible for knowing what software is being used, what the dependencies are, what the licenses are, and whether compliance and security requirements are being met. Will your chosen cloud vendor meet those requirements?
How will serverless computing affect the roles of your developer and operations staff?
Serverless simplifies operations, but it doesn’t eliminate software testing and deployment. As such, your DevOps team will need to change its focus–from infrastructure management to the automation of function deployment through serverless frameworks. Because the amount of work with the backend infrastructure is virtually eliminated, you will probably need less DevOps engineers than you did previously. But you will still need a DevOps team to set up and configure a pipeline that will allow your developers to validate, build and deploy their code and connect the code running in the cloud to the appropriate data.Â
Team members will need to learn how to use functions to properly configure customized Infrastructure as code (IaC) workflows to create a distributed DevOps pipeline. For this, they will need to learn a new DevOps framework, so you must consider a certain amount of time for them to acclimatize themselves to the new platform. In particular, developers must learn to make decisions on how granular a function should be. If your functions are too granular, you may end up with functions too numerous to manage. If they are not granular enough, you will end up having to work with “mini monoliths.†Also, as mentioned earlier, vendors limit the time a function can run, so they must adjust the function’s granularity to execute within those time limits.Â
Are you ready to switch to serverless computing?
Suppose your answers to these questions line up with your business goals. In that case, it is time to consider switching to serverless computing and eliminate the tasks related to infrastructure management and give your team time to focus more on development and deployment. The result: you will deliver new products and features faster and less expensively, but you’ll pay only for the time your code is executing and not for the time when servers stand idle.
Do you think adopting a serverless platform for DevOps is a hassle or is it the right thing to do ? Let us know on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!