Is Serverless the end of Ops? DevOps vs NoOps… NativeOps.
One of the core advantages of a Serverless architecture is the abstraction away of ops complexity, so-called “NoOps”, that allows developers to focus on writing application code. Yet, there are also Ops complexities added by using Serverless, so to some extent Serverless may not be the death of DevOps — and maybe the start of something new…
What was DevOps?
As the name suggests it is the combination of Development and Operations, moving away from the previous model in which these two teams were siloed apart. It includes a wide range of tools, techniques and structures that allow a more agile approach to product delivery, giving end to end application lifecycle ownership to one combined team.
The advantages of DevOps were the speed, collaboration, agility and scale that a cross-functional team could deliver. It is commonplace in startups and technology companies these days, but in larger corporates, there is still a division between the two — creating inefficiencies, politics and conflicts.
DevOps was tightly linked to the rise of cloud providers like AWS, Azure and GCP. The pay-as-you-go model of abstract computing building blocks provided by these companies allowed on-premise and self-managed data centres to be replaced by much simpler resources managed by a third party.
It has not always been a complete success though. There are still startups with a “DevOps team” and a “Development team, that do embrace some of the tools of DevOps — but not the dream of a single cross-functional team. The reason for this is that although the move to the cloud and containerisation did abstract away a lot of complexity, building secure, scalable and economic cloud infrastructures was still not trivial.
In short, DevOps was the idea of combining developers and ops into one cross-functional team, allowing more agile delivery. Some companies have done this well, others have not.
How does Serverless reduce Ops complexity?
Note: Here we are talking about Serverless provided by a cloud-provider, not self-managed options like Kubeless where there are obviously different Ops requirements.
Serverless is often mistaken to just be FaaS (Function as a Service), often using the example of AWS Lambda functions. But as I’ve spoken about before, Serverless is an architectural movement of building cloud-native solutions that allow developers to focus on writing application-specific code. This comes in two folds:
- FaaS solutions allow developers to send application code which is run by the cloud provider in isolated containers abstracted from the developer.
- Serverless architectures make use of third-party services (often from the underlying cloud provider) to handle routine application functionalities. For example, rather than write the code for and manage the Ops for a user authentication system, Serverless architectures leverage a service like AWS Cognito or Okta to do this for them. In the same way, generic infrastructure aspects like queues, pub-sub, push notifications etc can come from the cloud provider — i.e Cloud-Native.
What is NoOps?
NoOps is the idea that the abstraction away of the underlying machines of cloud infrastructure to the point where, in FaaS, developers can just send the application code they want to be run and not have to consider scaling, security patching or the underlying operating system. Therefore, teams can release features faster as there is no (well less) Ops work to do and the cost of launching a new service is reduced.
The idea of NoOps is not just linked to FaaS, as discussed above Serverless architectures make use of cloud-native solutions to common infrastructure components (e.g. AWS SQS for queues) and services for generic application functionalities like user authentication (e.g. AWS Cognito). Using such resources reduces Dev and Ops complexity as there are less owned by the technical team — things are consumed as a service not self-managed.
When NoOps is SomeOps?
From the above points, it seems like we finally made it! Companies can focus on developing new features — while the underlying cloud-provider can provide the deployment, scaling, patching, network configuration and security management.
Well, not quite. While it’s true that Cloud services can save time and reduce some of the traditional Ops responsibilities. Cloud providers have moved past just being a place for us to spin up instances, containers or VMs. There is a huge range of services provided by companies like AWS, meaning that there is a requirement to understand how these work, when they should be used and the best practices in configuring them — this is arguably ‘Ops’!
Also, Serverless architectures work well when they are structured as a distributed system. Distributed systems add a lot of complexity to monitoring, rollout and security management (even if managed through a service like AWS IAM). Therefore, teams need expertise in these areas.
Yes, we’ve saved time on traditional Ops, but there is an emerging area of Ops that we need to develop best practices and tooling in.
Is there still a divide between Dev and Ops?
The great thing is that the lines between what is Ops and what is Dev are being further blurred. Yes, DevOps had Continuous Integration and Infrastructure as Code starting to link the two, but this is taken to the next level in Serverless/Cloud-Native architectures as some “infrastructure” configurations (e.g. IAM, VPCs, Cognito User Pools, DynamoDB indexes, FaaS memory, Queue policies etc…) are deeply linked to the application logic. Therefore, “Devs” are jumping into learning how to use tools like the Serverless Framework / SAM / Cloudformation and “Ops” are writing config that is closely linked to the application logic.
The Risks with “NoOps”
One of the concerns around the breaking down of barriers to running Cloud applications is that you can get up and running quickly without necessarily understanding the impact of what you’re doing. An IAM wildcard (*) here, a public bucket there — and suddenly security is at risk.
We need to develop best practices and tools to automatically help teams build secure and economic cloud-native infrastructure, as well as do some self-reflection on the responsibilities of “Dev” and “Ops”. Developers need to step up to this challenge and Ops need to coach, support and train their teams if we are going to get the velocity “NoOps” proposes with the quality and security needed in modern applications.
In Conclusion
Serverless does reduce typical “Ops” work while at the same time adding new Ops challenges. The team will be able to focus more on developing features and there is an opportunity for Dev to learn from Ops and Ops to coach best practices and tooling as they emerge, empowering developers to be accelerated by Serverless and …NoOps.
NoOps may not even be the right term — it’s not the removal of Ops. It’s the abstraction of Ops from the underlying machine to be more tightly coupled to the application logic. Maybe…
NativeOps: the push for architectural quality and empowerment of developer autonomy in a cloud-native world.
