NoOps – as in “No Operations” – has been suggested as the next step in the evolution of DevOps. DevOps, after all, in some minds, freed application developers from the shackles of IT overlords that stingily doled out hardware resources. This was good, but managing infrastructure is not what devs really want, so with the arrival of PaaS (Platform-as-a-Service) cloud systems, the thought was that operations could finally be abstracted away and operations should no longer be of concern. Unfortunately for the inventor and fans of this term, operations remain, less as infrastructure ops, and more so as application ops. In this episode of Five Minutes of Cloud, our CTO, Robert Starmer, gives his take on the future of DevOps and whether NoOps is part of it.
Heroku – https://heroku.com/
OpenShift – https://www.openshift.org/
Cloud Foundry – https://www.cloudfoundry.org/
Kubernetes – https://kubernetes.io/
Istio (service mesh) – https://istio.io/
Kumulus Tech’s Istio Course on Udemy
Use this link to get our Introduction to Istio course for only $9.99 on Udemy
For those of you that prefer reading, we’ve run the transcript past our editors for a smoother, cleaner read, below.
So there’s a new concept that people have been talking about. Well, they claim it’s new. I don’t think it’s any different than anything else that’s come along in quite a while but the concept is “NoOps.” It’s this idea that application operators- those that used to consider themselves DevOps developers- no longer have to think about the operations component. I think this is a simplification that’s a little on the extreme side, in reality, NoOps is more about the fact that developers really never wanted to manage infrastructure.
Now if we roll back the clock a couple of years – five maybe, ten years – one of the benefits that the cloud set of services, specifically things like Amazon Web Services (AWS) and the EC2 (elastic compute) service provided was the ability for a developer to manage the infrastructure that their application ran on top of AND do that in a programmatic fashion.
This was a huge leap forward for many developers and that’s why I think the concept of DevOps had gained such a huge following and continues to have such a huge following. It’s because the developers really get much more control over their environment’s resources that they’re using and how the pieces all fit together. But the reality sets in after a while an now the developers can describe their infrastructure as code but they really have to manage it and that is the infrastructure as code concept.
That means that they now have to deal with the platform-level security issues – what is my operating system and what does its embedded security relationship look like? I have to deal with the network and network security issues. I have to deal with storage and storage security issues.
There’s a lot that one would have to deal with and as a small start-up you know 5, 10, 15, maybe even a hundred-person startup – maybe that’s ok. Maybe it’s ok that everybody sort of has a piece or an understanding of the entire system but I think the reality is that as the system scales you really want the application-focused developers to focus on applications. And have those that are more interested in keeping the system running and stable to focus on the system itself. I think this really breaks the environment and the organization into two different pieces.
Those folks that really want to focus on the application and there are still operations associated with that it doesn’t go away- even if we look at the platform as a service type offering as things like, what I think is the quintessential model to this- Heroku. There are also the sort of additional models that have come out that are potentially open-source platforms – Open Shift or Cloud Foundry are two really prominent examples of these tools. These really change the application developer operations interaction. It’s not that you’re not operating the application deployment or even interacting with the scale of your application but you’re sort of giving a lot of that control over to some other service.
I think this is nowhere more prevalent today than in the interest in the use of Kubernetes as a container management environment. The reason I think it’s so popular is that it gives you the visibility of how your individual resources are working. It potentially gives you access even to managing things like how your database works or what database you’re using. Giving you access to all kinds of data structures and data tools how your applications themselves interact with tools like the service mesh components. With Istio, you have some really fine-grained control and how you scale your application up and down.
These are the sorts of tools that application developers today are starting to use to continue to operate their environment. Even though they’re doing this on top of a platform and that platform now is Kubernetes.
So the folks that talk about NoOps are really talking about the fact that if I’m using Kubernetes I’m not really focused so much on the underlying infrastructure anymore. I’m not thinking about what operating system I’m running. I’m not thinking about what storage service I’m deploying and how I’m scaling and managing and backing that environment up. Or what networking or interfaces and SDN I have decided to use to actually implement that infrastructure, for the most part.
There are still some DevOps practitioners that are using Kubernetes and are managing Kubernetes as just another piece of their application stack. That’s a viable model but I think it sort of breaks the model a little bit and that I do believe there is a push towards what is perhaps more appropriate to think of it as GitOps or infrastructure ops, what I like to refer to as OpsDev. I kind of like the idea that Google has with systems reliability engineering (SRE). Thinking about how do you make sure that your system platform is stable, reliable, functional, upgradeable, etc. and yet let the application developers focus on how their application operates on top of that platform.
I think the two areas of interest have to have some level of overlap but if we do it right I think the DevOps developer focus is on their application and operations specific to their application which is really where I think we would want them focused. That’s where we’re going to get the best value out of the functions that they build. That way and the operators themselves- the infrastructure operators – can focus on making sure the platform is as stable as possible.
In both cases automation is key. You have to have automation to continue to expand and enhance these systems, but overall we can start to break out application operations. The DevOps cycle can focus their two operations development of which SRE is another term for that class of function or systems reliability engineer and let those two communities work together to find a decent boundary, this seems to be Kubernetes today, and yet also let the system scale and be more flexible and functional.