BT

Your opinion matters! Please fill in the InfoQ Survey!

Serverless Takes DevOps to the Next Level

| Posted by Rafal Gancarz Follow 1 Followers , reviewed by Manuel Pais Follow 8 Followers on Apr 28, 2017. Estimated reading time: 13 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

Key Takeaways

  • Many organisations still struggle with DevOps adoption
  • Serverless not only embraces the DevOps culture but has a pure form of DevOps in its DNA
  • Serverless makes operability a first class concern and embeds it into the development process
  • In the future many IT specialists will be replaced by broadly skilled cloud engineers
  • Serverless will change the culture of IT organisations and impact how companies use cloud computing

Serverless is here

Serverless computing is changing the way that software systems are being built and operated. Despite being a relatively new area within the IT industry, serverless has the potential to massively alter the way that business value is being delivered with software. It allows running cloud workloads that are available and scalable very cheaply which is ideal for a many product types and business use cases.

But serverless won’t just change the way that software is delivered to the user. It will change the organisations delivering the software too, which I believe is an even more profound impact that serverless will have on the IT industry. In this article I will explore the ways that serverless will alter the culture of organisations adopting it to deliver software and how it will affect the future of the whole industry.

The state of DevOps

Anybody, who hasn’t lived under the rock for the past few years, must have heard about DevOps already. DevOps movement encompases and extends agile software development into the field of IT operations and aims to deliver greater business agility by fostering strong collaboration between development and operation teams as well as the adoption of novel operational practices, particularly around infrastructure provisioning, improved release management and operational tooling.

In fact, DevOps is becoming the new standard in the IT industry and has become widely adopted, quite often in conjunction with cloud computing and container technologies. At the same time a lot of organisations are struggling to realise the full benefits of DevOps, mostly due to expertise shortages and various organisational challenges. Despite these adoption pains, DevOps is becoming a mainstream movement and is changing the way that IT organisations are delivering software, in a similar way to what agile movement has done for over a decade.

But how does serverless computing fit into the DevOps culture and how will it influence common DevOps practices?

Why serverless computing?

In order to understand how serverless computing may impact organisations using it, let’s first look at key characteristics of this approach to building and running software systems.

Function-as-a-Service (FaaS) provides a managed runtime for executing any arbitrary code that has been uploaded to this service. This may look identical to just deploying a runnable artifact onto a compute instance (server) and having an operating system execute it but it’s not. FaaS takes care of making the function available at the scale required to satisfy the current demand but only charges for the execution count and time. At the same time it abstracts away the setup of the actual runtime (like JVM or NodeJS) and the operating system itself. The runtime process, the OS and the compute instance is still there (don’t let the ‘serverless’ term fool you) but the developer doesn’t need to worry about any of these anymore.

And that’s the beauty of it - the entire compute stack is completely managed by the cloud provider, including the OS process running the function code. This simplifies the management of the compute infrastructure immensely, and combined with a pay-as-you-go billing model, offers an incredibly flexible and cost-effective compute option, compared to a more traditional Infrastructure-as-a-Service (IaaS) compute model.

Rapid development

Looking beyond the FaaS compute (such as AWS Lambda, Azure Functions or Google Functions), public cloud providers offer a range of other services that can be combined to create serverless architectures. From scalable persistent stores and messaging infrastructure to API gateways and content delivery networks, these days it is possible to build complete systems without ever having to be directly dealing with servers.

Each cloud provider service is fully configurable using the provider’s SDK so nothing gets in the way of delivering business value quickly (except lack of familiarity with available services and their configuration options). Functions tend to be responsible for processing simple events or requests so usually don’t require a lot of coding, resulting in small units of concentrated business logic. For instance, a function could be responsible for publishing a notification of a change to the user’s email (based on a trigger from the database table) to the corresponding message topic, so that other subsystems can consume such notifications and update an external system, for example.

Functions then implement the business logic and glue services that provide essential capabilities, such as persistence, messaging, integration, content delivery, machine learning, etc. These services address a lot of complex engineering problems and allow creating sophisticated solutions without much difficulty, enabling rapid prototyping and development.

Operability from the start

With the serverless approach it’s virtually impossible (or at least a bit pointless) to write any code without having at least considered how code will be executed and what other resources it requires to function. After all, in order to see how the code interacts with API gateways, data stores or messaging infrastructure, code has to be deployed first and all dependent resources have to be provisioned too. To be fair, function execution can be emulated without deploying it onto the provider platform but this offers only a limited degree of validation. Additionally, it doesn’t exercise the entire infrastructure stack that is required by the function (or functions).

The fact that serverless computing requires the provisioning of cloud resources can be considered a hindrance or a blessing. Those accustomed to using their own computers to run applications or systems locally in development mode will most likely agonise over the loss of productivity due to slower feedback cycles. Indeed, infrastructure provisioning and code deployments do take more time but not as much time as they would have with IaaS compute (if you consider launching compute instances on demand).

The main benefit of being forced into looking at the infrastructure stack right from the beginning is the fact that infrastructure setup and provisioning mechanisms are being brought forward and tackled at the same time when the code is being produced. This is rather different than a more traditional (and still quite common) approach where developers are writing code and perhaps even produce deployable artifacts (with help from the CI tool) and then hand these over to the operations team for deployment, assuming that the compute and network infrastructure will be taken care of.

While the DevOps movement promotes collaboration between development and operations teams, with serverless it’s simply not possible to separate the two areas.

Even deploying a simple function requires making a few crucial decisions that have implications from operational as well as financial point of view. The two most basic configuration options are the amount of available memory and the timeout (the time budget for the function invocation). Both of these settings influence how much function invocation might cost as invocations are charged based on memory consumption and the execution time. Additionally, allocated memory is usually linked with the specification of the compute instance that the function is running on - more memory comes with more processing power.

With so much riding on the optimal configuration of the function, it’s important to be able to quickly adjust the settings based on available budget as well as the desired and observed performance characteristics. These characteristics can be determined from the metrics collected and exposed by the cloud provider (AWS CloudWatch is an example of the monitoring service). Actually, having a rich set of metrics for FaaS and other services commonly used for building serverless architectures is essential to being able to operate these architectures. Since metrics are available immediately after resources are provisioned, many operational aspects of the architecture, like performance optimisations, capacity planning, monitoring and logging, can and should be considered even during the development stage.

Security is another great example of an aspect of software delivery that is quite commonly addressed as an afterthought or is delegated to a dedicated security team that has to assess and sign off all software components before being deployed to production. With serverless, security has to be considered as soon as the function is deployed during the regular development activities. At a minimum, each function has to have a security policy associated with it. As much as it’s possible to give the function access to every other resource in the same provider account, it makes sense to spend a bit more time to determine and configure the right security policy for the function based on its job. Ideally then, following the principle of least privilege the function should be given the minimal set of permissions it needs. For example, a function that needs to query a database table should only have permissions to query this one table and nothing else.

It’s becoming quite evident I hope that the serverless model is firmly making operability (including security) a part of the normal development cycle, rather than deferring these elements until the time the operations team gets involved, when it’s usually too late to address any problems properly and easily.

When it comes to serverless, DevOps mentality is not something that can be adopted incrementally (usually with much pain) but it’s rather written into the DNA of making things work.

Pay for what you use

Serverless computing brings another revolutionary change compared to the IaaS computing model and that’s the pricing model based on paying for individual function invocations rather than having to pay for keeping servers up.

Organisations using the public cloud are used to treating cloud infrastructure costs as operating expenditure (OPEX) rather than capital expenditure (CAPEX), but with IaaS computing they quite often still end up making substantial upfront investments in order to reduce cost (one example is reserving compute instances or purchasing reserved capacity for other cloud services). With serverless computing, this is usually no longer possible or cost-effective as it’s much cheaper to just pay for function invocations made than to keep servers running all the time.

Considering the pay-per-use pricing model for the majority of services used to build serverless architectures it becomes feasible to operate many more environments to support development, testing and operational activities involved in software delivery. After all, they may end up costing very little or nothing if not used. Economic implications of serverless are removing many obstacles that are making the road to DevOps so challenging to many companies.

Being able to have as many environments as it may be needed to satisfy the needs of various teams or business stakeholders offers some tremendous new possibilities. For instance, each developer could have a personal development environment in the cloud or perhaps each feature being worked on could be deployed into a dedicated environment so it can be demoed independently of anything else being worked on. These separate environments can be even hosted on separate provider accounts to deliver the ultimate level of isolation.

Continuous deployment - the new normal

Continuous delivery is one of the key capabilities enabling DevOps but is still fairly elusive to many companies, particularly in the enterprise space. While continuous delivery offers many benefits and enables higher business agility it falls short of realising the full potential of what organisations can achieve.

Serverless computing can be used to enable the holy grail of business agility - continuous deployment. With continuous deployment any change merged into the code mainline gets automatically promoted to all environments, including production. Obviously, for this approach to work without negatively affecting users, the system being continuously deployed needs to be subjected to stringent quality checks from different angles.

Given that many operational aspects, such as infrastructure provisioning or security, can and should be tackled together with the development of the function code, the resulting infrastructure stacks can be provisioned from scratch or updated in place based on the code and configuration contained in the source code repository. These stacks can be managed either by the provider’s native tools (like Cloud Formation on AWS) or more generic tools like Hashicorp Terraform.

With infrastructure stack provisioning and code deployments being fully automated it’s possible to apply or unapply (roll back) changes to any environment, including production as part of the deployment pipeline. Any testing (both functional and non-functional) necessary to ensure the quality of the system should be also automatically executed against relevant environments after the deployment and the pipeline aborted in case of any test failures.

Everybody is a cloud engineer

Serverless is blurring the lines between various technical roles commonly being involved in the software delivery. Where traditionally architects, developers, testers, database administrators, operations and security engineers would be collaborating together to deliver the system and operate it in production, in the serverless world many of these roles are merged into a single one, a cloud engineer.

As many traditional activities have been removed or greatly simplified it’s not longer necessary to involve many specialists. Instead, engineers with broad skillsets and good familiarity with the cloud provider’s platform can achieve as much, if not more, and do it much quicker too. Many development and operational activities can be conflated into the same cycle and costly handoffs or borrowing of external resources can be eliminated altogether.

This doesn’t mean that we no longer have individuals who are specialising in specific areas as people are naturally attracted to some aspects of software delivery more than others but ideally everybody in the team should be able to participate in all activities related to delivering a feature, including operating the system in production. This is the best way to make sure all engineers are incentivised to produce quality software that is operable from the start.

In effect, rather than talking about bringing dev and ops closer together, teams using serverless are the embodiment of pure DevOps culture, where software is being forged to be ready for production right from the start.

Survival of the fittest

Serverless can help achieve the ultimate business agility. However, it depends completely on the organisation’s ability realise the full potential that serverless offers. While many organisations are still struggling to establish some form of DevOps culture and practices, serverless offers a whole new way of creating a culture of rapid business value delivery and operational stability, while minimising costs.

Not many organisations can rise to the challenge of embracing the brave new world of serverless and it is indeed brave as the entire field is still very young and immature so it requires a lot of extra work to address the gaps or challenges resulting from its infant state. A lot of well established organisations, who might be willing to play with serverless, may find themselves trying to use their existing processes and organisational structures and lose any agility that they could have gained or, even worse, massively struggle to build and operate serverless architectures.

Those companies able to fully leverage serverless as means of achieving competitive advantage in the marketplace, may be forced to adjust not only the way they deliver software but also the way they create and sell products.

Conclusion

Serverless doesn’t only supplement DevOps but it goes beyond the current thinking on how IT organisations can achieve greater business agility. It’s geared towards rapid delivery of business value and continuous improvement and learning, and as such has clear potential to drive substantial cultural change even in organisations that have adopted DevOps culture and practices already.

Using serverless approach will not only enable organisations to deliver new products and features quicker and cheaper. It will change their culture in the process.

About the Author

Rafal Gancarz is a Lead Consultant for OpenCredo, a London-based consultancy specialising in helping clients build and deploy emerging technologies to deliver business value. He is an experienced technologist with expertise in architecting and delivering large-scale distributed systems. Rafal is also an experienced Agile practitioner and a Certified Scrum Master, and is always interested in improving project delivery. Rafal has spent the last 18 months working on a large scale project using serverless technologies on the AWS platform and has first-hand experience using the serverless stack for building enterprise-grade distributed systems.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT