DevOps is the word of the year. Everyone speaks about it, and many are hoping to apply it, even though most are confused what it truly means.
Inquiring about DevOps does not seem to help. If you speak with a software vendor, he’ll tell you that all you need to become DevOps ninja is to purchase his product. Puppet, Chef, Ansible, Docker, Terraform, Packer, Jenkins, Nexus, Git… Every software vendor seems to have a DevOps sticker attached to his product. You’ll notice those stickers being right next to “we make Docker easy” and “we convert your architecture into microservices.”
Truth be told, software vendors are not the only people offering DevOps nirvana for a moderate price and a promise eternal faithfulness. Coaches and consultants are having their moment as well, even though they tend not to promote a single solution. You just need to adopt Agile across the whole organization, apply XP practices, implement continuous deployment, convert your applications into microservices, and attend at least three thousand daily standups. Your journey will begin once you accept all those DevOps prerequisites and commit to many others that will be discovered throughout the process. The consultant will have a gig of a lifetime, and you will be trilled by the prospect of reaching the promised land.
It does not end there. The job market is full of offers of DevOps engineer positions even though such a thing does not exist. I’m still not sure what it even means. The most sensible explanation for such a position is that someone replaced the word operator with DevOps engineer. You will continue working in a silo, you will continue being in charge of the same processes and tools, and you will continue receiving JIRA tickets with requests to create a new server. But hey, look at the at the bright side. You got a new title! Isn’t that peachy? Don’t worry if you’re a battle tested sysadmin. The same rules apply. Your future is secured as long as you change your title to DevOps engineer.
Now that you converted all your operations personnel and sysadmins into DevOps engineers, the next step is to employ a few more. After all, DevOps is the new thing, and you have to spend the extra budget that comes with the promise of converting the organization into the next generation Disneyland.
Once you turned all operators and sysadmins into DevOps engineers and added a few more, you need to have a department. Actually, you already have it, but the name is inappropriate. Since you are brilliant and quick witted, you renamed it to DevOps department before anyone else comes to the same idea. You’re not going to let others take away the spotlight. You were in a basement during the agile party. You didn’t get the invitation and, frankly, you still hold a grudge. Now it’s your time. The DevOps party is about to start, and you expect it to last for a couple of years, if not more. You are the star. You’re on the stage, and your fellow colleagues are in the front row. For a split of a second, it seemed like you saw some of the agile folks as well. They’re somewhere in the back, together with the rest of those with cheap tickets.
The truth might be horrifying. You are jumping on a train without a ticket. You’re faking it. The only question is whether you’re self-deceiving yourself and others out of ignorance or as part of a sinister plan.
Let’s go back to the chaos created by the myriad of tools and practices you have to adopt if you’ll ever become “DevOps certified.” There are too many to handle and, as a result, we’re experiencing brain overload. It’s close to impossible to understand what’s going on. What you need is understanding where you are, where you’re going, and how do you plan to get there. Believe me; those questions are much harder to answer than it looks.
When you find out where you are, you will understand what your strengths are, what is your current state, what your problems are, and so on. You will establish your starting point.
Figuring out where we are requires a high level of objectiveness. An honest answer will probably mean that someone will get hurt. It’s never pleasant to discover that you’re not on the top of the hill. It is painful to find out that, when compared with the competition, you are not as good as you thought you are. You are looking for answers that will situate you (the company) within the industry as a whole and, more importantly, allow you to understand the gap between you and the industry leaders. Be prepared for a disappointment.
Once you know where you are, start figuring out where you want to go. That part is not as hard as it seems. All you have to do is look at where the leaders are. Polyglot projects, small and self-sufficient teams, agile, DevOps, microservices, continuous delivery or deployment, containers, schedulers, cloud, everything as a service, removed administrative overhead, adoption of new programming languages, and so on and so forth. We know where the leaders are. It’s enough to visit a couple of conferences and listen to speakers from Google, Netflix, Zalando, Amazon, Uber, CloudBees, Docker, and other companies that are shaping the industry. In today’s world where attracting talent is harder than ever, companies are competing who is going to be more transparent and sway top engineers to work for them. There are no secrets.
The problem is not how to find out where the industry leaders are but admitting their state. The gap between them and us might be so huge that we tend to think of excuses instead absorbing the collective knowledge of the top five percent. I would be a rich man if I’ve got a dime every time I heard phrases like “that does not apply to us”, “our industry segment is special”, “yes, but”, and other excuses that our brains formulate as a self-defence when faced with that immense gap between them and us.
Without knowing where the industry leaders are and acknowledging the gap between you and them, you will not be able to define your destination. You will not be able to understand what you might need to achieve. The chances are that you can do much more than you think. The major obstacle is admitting the gap and not getting fired as a result of that discovery.
Once you know where you are and where you must go, you can start planning the steps that will get you there. Please note that I did not say “where you want to go.” That ship has sailed. Unless you are among top five percent of the companies, you are not in control of your destination anymore. Your competition is. The best you can do is catch up. Your destination is where the others are. You must hope that they will not get far away from that point by the time you get to where they were. Only when you get there can you decide where to go next. Unfortunately for you, your next destination is continuously changing. You’re trying to catch up with someone who is not standing still. Still, you need to reach the top first and then think where you’ll jump.
You dig the hole yourself, and now there’s only one way out. Hurry up before someone finds a shovel and starts burying you alive. If you are not quick, you might end up sharing your resting place with Kodak, Nokia, and other companies that were not capable of understanding the ever-shifting nature of the industry.
Today it’s DevOps. Tomorrow it will be something else. You’re either defining what the future looks like, or you’re trying to catch up with today’s trends, or you’re a zombie. There is no fourth category. The current situation is that zombies greatly outnumber us. They are walking around aimlessly, and they tend to mutter words they do not understand. You can hear them repeating things “agile”, “DevOps”, “containers”, “big data”, and “microservices”. They are always moving in circles not being able to get out of their monotonous paths. Their numbers are great, and a single group usually consists of thousands. The strange thing is that, for some inexplicable reason, they tend to occupy buildings that are marked with the word “enterprise” written in huge letters and hanging in prominent places.
I still have fate in humanity and hope that human strongholds (often occupied by a group of tens or hundreds) are going to prevail. The problem is that zombies, even though already dead, are not aware of that fact and can continue existing for a very long time. That is, until they are destroyed and face the same fate like the group that occupied Kodak and Nokia buildings.
| Reference: | Zombies Are Muttering “Agile”, “DevOps”, “Containers”, “Big Data”, and “Microservices” from our JCG partner Viktor Farcic at the Technology conversations blog. |
