As the world of software expands, new development practices are constantly being thought of to ensure the speed and reliability of development. Increasing competition and rising customer expectations and reliance on software have set the goal for thrilling speeds of development while maintaining reassuring reliability against breakages. This is where the motive of DevOps arises as it is a cultural practice aimed at providing the exact need for increased velocity with maintained reliability and uptime. To go fast without crashing.
However, adopting DevOps is easier said than done. The idea is spectacular in the literature and coming from the mouths of industry luminaries that ornate tech-conferences. In reality though, implementing DevOps can entail learning curves to overcome, changes in trusted practices, and implementation of infrastructure for which companies and teams simply do not have engineering resources for at a specific time.
Similarly, serverless provides the much-needed respite in DevOps adoption. That is the purpose of this piece. To highlight some of the ways that serverless technologies can be utilized to achieve ideal DevOps practices by provisioning facilitating architecture.
The True Meaning of Serverless
To understand how serverless can aid in the adoption of DevOps, it is crucial to break the misconceptions of the technology and understand the pillars that make something truly serverless. The onus lies on the success of AWS Lambda’s popularity making it synonymous with the concept of serverless.
Don’t get me wrong, I am not belittling AWS Lambda. In fact, the strides made by the serverless community has been greatly supported by gaining popularity of AWS Lambda. However, some new entries into the domain have associated serverless only to be FaaS and this could not be further from the truth.
Contrary to the misconceived belief that serverless is a form of compute service, any service is a serverless service if it demonstrates the characteristics listed below:
Considering these properties solely, and taking the AWS ecosystem as an example, we see that there are actually many AWS services that qualify for the serverless tag. For example, in the domain of compute services, AWS Lambda is no longer the only service that makes the cut but rather we now see AWS Fargate, too. Similarly, integration services such as AWS Step Functions and Amazon API Gateway are also included along with the database services such as Amazon Aurora and Amazon DynamoDB.
As a result of tackling the misconceptions, we have inadvertently expanded the classification of serverless services. This better-perceived bag of services delineates that the already popular tools being used in various DevOps stacks across the industry are actually serverless.
The question then becomes, why is serverless so beneficial for DevOps?
The Serverless Appeal
What makes serverless tools so attractive, to the point where it is adopted without the users even considering the tool as a serverless tool, is the inherent benefits that come with the characteristics listed above.
If DevOps is adopted it is for the purpose to accelerate development while stabilizing the product away from downtimes. The resulting goal that is hoped to be achieved is a more competitive edge and through better customer experience and faster maturity of the product in terms of features and capabilities. Which further entails endows sustainability of the software product in the industry.
So these are the motives of DevOps, which by no doubt are the shared motives of the entire industry. No team or company stays away from DevOps because they do not want to be more competitive and ensure sustainability. The reason why there may be a reluctance to adopt DevOps, albeit the known benefits, is because it may be too expensive for the adopters. This expense may be incurred in the form of time, technical resources or simply the efforts spent in overcoming learning curves to procure the skills to move towards DevOps.
Considering these barriers, the reasons for serverless tools in the DevOps stack becomes apparent. Implementation of any DevOps solution needs to ensure low costs for greater returns. Tipping the cost-benefit scale in the way for DevOps adoption.
Therefore, with serverless technologies, the greatest advantage is the pay-as-you-go model. You end up paying for only those resources you would use. In terms of AWS Lambda, you would only pay based on the number and duration of invocations. Hence, potentially lower costs.
There are cases where FaaS functions could become more expensive than containers, and that depends on the traffic experience. The higher and more consistent the traffic, the higher the costs of serverless tools, and these costs can rise higher than container costs. However, in the case of FaaS for DevOps, the traffic would coincide with the speed of development. This intuitively would be lower than the required traffic to result in FaaS functions becoming more expensive than containers.
Price comparison between AWS Lambda and an m4.EC2 instance
State of DevOps 2019 report statistics on code deployments per different DevOps performers
Now considering the number of invocations that would be required if AWS Lambda functions are used in the continuous delivery infrastructure, we can see that the costs would potentially be cheaper than the use of containers.