When will DevOps die Part 2
“All those moments will be lost in time… like tears in rain… Time to die.”
“I can’t lie to you about your chances, but… you have my sympathies” Ed O’bannon — Alien
Background
In the first episode, I wanted to define what DevOps is, and what makes a DevOps engineer.
I found out that DevOps is first a cultural change, and that a true DevOps environment is hard to find. I saw that many “DevOps Engineer“ jobs are more about doing operations automation and not exactly DevOps. I even argued that DevOps engineer is a problematic role; how can you engineer culture?
I have noticed that the demand for DevOps Engineers has been rising during the last couple of years, but I am not sure that the people who are hiring understand the meaning and the importance of DevOps nowadays. Many companies rush and create DevOps teams that are operating in a traditional waterfall model, but with some new cool tech.
But all those subjects are covered in the first part. This time I will try to define some big changes in the software development market, and see how they will effect DevOps culture in the near future.
Cloud providers are changing the IT world
Cloud adoption is rising high; seems like almost everyone wants to lift and shift their applications from local on-premise servers to somewhere remote.
The cloud offers a very scalable solution for small businesses to start with a lean toolbox and a lot of options to save money. I would add, that when you grow, the cloud can be expensive, but this is not the subject of this article.
If you are starting a fresh new startup, you will most probably build it in the cloud. There are many options, such as Google Cloud, AWS, Azure, Digital Ocean and many more. Some offer a more classical way of buying a virtual machine and deploying your software over it, and some can give you many special tools to make your life as a developer much easier. But what does it mean for a DevOps engineer?
The emphasis on our work is slowly shifting; instead of taking care of resources and their automation, we are now more concerned with the functionalities of our stack and the reliability of it.
We are slowly outsourcing the infrastructure to the cloud providers. Instead of maintaining a Jenkins server, we can use Drone CI or reCircleCI, as they might be less flexible but much easier to manage than Jenkins. At the end of the day, everyone thinks his software is special, but maybe 90% of them are identical.
Let us think about Kubernetes, which might be the hottest buzzword around right now. It might have a really steep learning curve, but have no fear! Google Cloud offers a really easy managed solution in which you can have a cluster running in their server in a matter of hours. You will not be an expert in K8s, but you can slowly build a nice cluster for development and gain knowledge about it.
Fact is that Kubernetes removes a lot of the work that the good old Ops used to do, but now even setting it up and running it is someone else’s job. Kubernetes by itself is an abstraction that replaces Ops with API and driven automation. And now we have the Knative, which is serverless running on top of that.
I think the first company that truly understands the power of outsourcing your infrastructure is Google. Unlike the rest of the cloud providers, Google cloud is oriented towards developers and not operators.
One might argue, that if you start a small startup and you do not have the manpower to have an onsite DevOps Engineer, you can somehow survive with Google Cloud. Just from the language, they choose you to see that they are aiming in a different direction. For example “Google App Engine” is defined in the following way:
”Build and deploy applications on a fully managed platform. Scale your applications seamlessly from zero to planet-scale without having to worry about managing the underlying infrastructure. With zero server management and zero-configuration deployments, developers can focus only on building great applications without the management overhead”.
The whole idea of managing infrastructure (even virtual) is slowly disappearing. This is why configuration management tools such as Puppet and Chef are losing their importance and usage. Those who still need some usage of infrastructure will go into the direction of declarative infrastructure.
If a couple of years ago we stopped treating our servers like pets and started treating them like cattle, nowadays we prefer not to treat them at all, and we expect our service provider to deal with them instead of us. From this need stems the idea of Serverless Computing, which I will touch in the next paragraph.
Serverless
https://www.youtube.com/watch?v=-fu7jN2_2pE
The name is a bit misleading since serverless computing is a cloud-computing execution model, in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. It can be a form of utility computing.
Serverless computing can simplify the process of deploying code into production. Scaling, capacity planning, and maintenance operations may be hidden from the developer or operator.
Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.
Think about AWS Lambda or Google Cloud Functions; the developer is getting a pretty straightforward interface to build his software and he does not care about the infrastructure anymore. I think this is a radical change; in some specific cases we no longer care about the resources needed to run the application, we only care about the functionalities and expect someone else to provide us the computing power and the infrastructure.
This tendency will grow in the future years since one can save money while scaling computing power, but also it’s easy to start a company with a minimum amount of people.
The company Ops, or DevOps, will have things to do, but as much as we see this trend of serverless used more and more, we would have to ask ourselves as DevOps people, what are we actually doing? Does a company working in that model need a dedicated DevOps guy? Would it be better to be leaner and use outside people to mentor the developers when needed? (we can do that!)
Serverless is just a small part of a bigger picture. It's gaining a lot of attention and good adoption rates. If we can transform everything into code, the next logical step is to let someone else deal with this toil (most likely with automation), and let the in-house people deal with things that are more directly connected to the app its self. One of the reasons to use those services is to remove that responsibility out of your hands. The question we might need to ask ourselves is; would it make us useless?
Culture is your friend!
I know this whole series might feel a bit depressing sometimes since we humans have hard times in letting things go. But here are some good news, let us look at a paragraph for a second:
“The nature of our work is interdisciplinary so we recognize that a successful candidate can come from a wide variety of backgrounds (e.g., software engineering, SRE, human factors, safety science, systems engineering, technical product/program management, UX research, organizational psychology, cultural anthropology). We encourage you to apply even if you feel uncertain that you have the “right” background”.
Taken from Netflix job description for the role “Sr. Resilience Engineering Advocate”.
As I defined in the previous article, there are avant-garde and mainstream, I would rate Netflix as a more avant-garde company; what they are doing now, others will copy in a couple of years.
Notice, that they understand that the stability of their product is a company-wide challenge. Organizations are slowly starting to understand that taking a team of people and labeling it as DevOps Engineers is not enough. Furthermore, they understand that no matter what cool and new tools you use, if making the best software is not a company-wide goal, you are going to have trouble.
If you are part of a DevOps team that creates their own silos inside the organization, you are not really doing DevOps, you are only called DevOps. In this culture, the goal is to have a diverse team, where people share the responsibilities for everything they do. Unlike Terrence McKenna, I think that for the DevOps people, Culture is your friend!
https://www.youtube.com/watch?v=3Lw30BeBZ6k
What’s the future for DevOps?
The first thing is that DevOps will change its meaning again; we might see changes in the way people perform their work, but we would need people to
help developers to run their code somewhere.
DevSecOps — We are automating the way we release software, making all the boring work done by different tools. I would say that the next step would be automating security, for example, Chef’s Inspec is a tool aiming to do that.
Writing Code — In a way, the DevOps Engineers of today are the Developers of tomorrow, the next evolution of our field will demand us to know how to develop tools that could help other engineers to work faster.
Mentoring — Some of us who are multi-disciplined and experienced, would have the option to advocate things on a cultural level. Mentoring others on good practices would be very important to companies that want to be the best for a long period of time.
Reliability — This is a side of software development that would stay crucial. Nonreliable software is software that does not make a profit. We would need people who are experts in building monitoring tools (that’s one huge bone to pick, how to set up monitoring in the serverless and cloud-native world).
