EDITOR’S NOTE: This article was updated July 2, 2018
Serverless, like Kubernetes and microservices, is a new technology. Yet, despite the amount of blog, forum and news-related posts published about serverless, it represents only a fraction of all IT deployments.
Aside from the new factor, serverless shares few similarities with Kubernetes and microservices. Organizations turn to Kubernetes and microservices platforms to add more agility and, in many cases, computing power to their IT operations. Serverless deployments, meanwhile, are seen mainly as a way to save resources by relegating server management to third parties.
Ultimately, cost savings is the main benefit. A successful migration largely hinges on DevOps, especially at the early adoption stage.
“There are ways to use serverless while delivering a very rich customer experience,” said Sanjay Challa, senior product marketing manager at Datical. “It is about putting the pieces together in a very right way to do that.”
More specifically, Challa said DevOps is relevant to serverless deployments because:
- DevOps promotes collaboration between development and operations — a core mantra is “you build it, you run it,” Challa said. “Serverless deployments essentially embody this central tenant: it’s frankly difficult to separate development from operations because any edit to a serverless function needs to be in the context of its operation in the cloud (the cost of the resources the function will incur and the net user experience),” Challa said.
- With serverless architecture, there is no longer a line between cloud operations engineers and developers. This is because “the roles are collapsed into one, thus embodying the fundamental core of DevOps, to collapse and harmonize the development and operations functions.” Challa said.
For data and database management, Challa said it’s also important for teams not to forget about the underlying database and data architecture, when moving to the cloud and to new serverless architectures. “If teams only focus on the application code and forget about the database, they are setup to fail as changes to the data/persistence layer simply will not be able to keep up and scale with application changes,” Challa said. “This potentially leads to quality issues, outages or even data loss in the event of a hastily made or erroneous database change.”
The definition of serverless can vary, but among the many offerings available, it usually refers to functions-as-a-service (FaaS) and backend-as-a-service (BaaS) services. Despite its name, serverless has a lot to do with servers—but organizations delegate the management of those servers and the associated infrastructure to third-party cloud providers. In this way, organizations upload code or applications and the third party maintains and runs the servers. Amazon Web Services’ (AWS) Lambda, Google’s Cloud Functions, IBM’s OpenWhisk and Docker’s Serverless Docker are among the leading offerings.
When an organization decides to migrate some or all of its data to a serverless platform, it’s important to note the technology’s drawbacks, especially as they relate to DevOps. Common downsides include slower computing performance and less capacity to run code compared to what is available when using servers on-premises or on the cloud. In the case of AWS Lambda, for example, the maximum total of concurrent executions per account is set to 1,000 by default per region and memory capacity for applications is limited to just over 3GB.
Also, by shifting server management to a third party, organizations also are delegating those management functions, including many associated server-related security and monitoring capabilities.
Ultimately, it will be up to the DevOps group to weigh the advantages versus the disadvantages when deciding whether to migrate to serverless platforms. While serverless technologies could potentially frustrate some developers because of the performance constraints on computing, memory, etc.; the key issue is to choose the right tool to solve the right problem, Challa said.
“Each tool has its place,” Challa said. “Serverless is not a cure-all – but is just another tool for enterprises to consider.”
Migrating to serverless also means job responsibilities will be affected, which will require DevOps to manage. “When you move to serverless, a lot of roles are disrupted. You need your network and infrastructure guys less than you did before, for example,” Challa said. “So, your team will look very different, since serverless teams in general looks very different compared to traditional IT operations.”
It is also necessary to solve any existing DevOps challenges you have first before you make the switch to serverless, Challa said. “Otherwise, you are setting yourself up to fail,” Challa said. “Without transparency and strong coordination, moving to the cloud and to a serverless architecture will only slow things down—or, worse, lead to outages and quality issues.”
However, once a serverless platform has been successfully set up and is running, DevOps’ workloads should decrease, since there will be less server maintenance work to do, said Holger Mueller, an analyst for Constellation Research.
“With FaaS, DevOps is less relevant as deployments take place within the FaaS framework,” Mueller said. “There is no need for DevOps to write scripts or manually do anything. Normally, everything should just run itself.”
However, Challa disagreed that serverless deployments completely run on their own once deployed. “Someone had to set up and configure a pipeline to enable developers to validate, build and ultimately deploy their serverless code. That someone must also play a DevOps function in enabling a path from a developer’s workstation to the cloud that supports the serverless capabilities—not to mention the work that needs to be done to connect the serverless application code running in the cloud to meaningful data,” he said.