About DevOps dimensions
“It is famously said that every company is a software company. And I would like to extend by saying that today in 2022, every company is a DevOps company. Especially in the post-pandemic world, that has become the norm. DevOps is no longer a word you just hear in conferences. It has become a glaring business requirement today.
There are a couple of dimensions in DevOps that make it increasingly important. First is the business impact – the direct impact on the top line that an organization can check with metrics.
Then, there’s the bottom-line impact, with things like developer productivity, defect density, and cost of quality. So that’s the business angle to it. The organizational angle is that all organizations are now moving, or maturing towards agile, guilds, chapter, tribe – whatever you call it. They’re either creating centralized structures, or they’re getting into the decentralized Center of Excellence (CoE) kind of teams, looking at creating Platform teams that need a DevOps approach.
Then the ways of working are changing. That’s the third dimension to it. The feature driven development, talks about continuous security, and canary deployments – all that needs DevOps.
And then finally, new technologies coming in like chaos engineering, AB testing, Metaverse, etc. There’s a lot of talk about carbon emissions in software industry too. In fact, I’m one of the mentors at DevOps Summit, Canada, where this is a new track that we are picking up – how do you reduce carbon emissions in the software development lifecycle, and that’s where again, DevOps has a role. So DevOps has become very important in any dimension that you look at, in the entire software delivery lifecycle”.
About Different DevOps Transformation
“Fundamentally, the focus of DevOps is different for small and medium enterprises than the largeer enterprises. And that’s because business requirements are different. And there are two-three angles to this.
One is the operations angle. Typically, a small enterprise is focused on stabilizing and scaling up operations without impacting user experience. I was reading an article, and there was a cricket match between India and Pakistan over the weekend. That’s the Asia Cup final. One of the popular channels Disney Hotstar was telecasting it to 13 million concurrent users. Now, imagine the amount of infrastructure you need to be able to support! And this is across mobile devices. The majority of them were watching it on cell phones, on the go at 3g, 4g, 5g speeds. So imagine the kind of infrastructure it will take to support something like that. Yes, that’s at the small and the medium businesses.
Then you come to the banks, the large retailers, where they have a different problem. There, you have a wealth of technology. You know, everything from the Java, .NET, multiple ERPs, Oracle, Salesforce, Mainframe, Heritage Systems, and you have to support all of that. It’s a fundamental difference in their structure. There’s a big people dimension as well. People want to work in an organization which supports 13 million concurrent users, which is telecasting the next big sporting event. People probably don’t want to work in a bank, which has been around for 100 years, and is not transforming. It’s about attracting the right talent also. So we have different organizations, different dimensions to the challenge, both from a technology and a people perspective”.
About DevOps Career Path
“A typical DevOps engineer profile could be different for different organizations because this is still not very well established. This is how a typical DevOps engineer’s career will move and this is how I’ve seen it evolve in the last 10-15 years.
You start with a DevOps engineer, basically maintaining a DevOps pipeline, you’re fixing build breaks, you’re doing continuous automation, you’re putting the fundamentals in place, you’re gaining the depth of skill, because you’re in one team on one technology stack, and you’re going deep. That’s a typical DevOps engineers’ profile.
A couple of years later, you move to a senior DevOps engineer, where you’re graduating from maintaining somebody else’s pipeline to creating a pipeline and onboarding new projects into the DevOps pipeline. You’re continuously automating on the environment side, on the app side. Now, you’ve gone from one team to multiple teams. You gain a width of skills, and then you start cementing the fundamentals that you’ve probably learned in the first couple of years.
Then you grow on to a DevOps architect, where you work across multiple technology stacks, hopefully, across an enterprise. You can set up a DevOps capability. You’re training the development teams. Here you have width and depth of technology. It’s very important at this stage to start developing people skills in parallel because as you move further on from a DevOps architect, you will have a lot more people interaction.
Now, there’s a fork in the road. What does that mean? You can go in a technology direction, the principal architect, who typically pushes for DevOps at a large enterprise. You are at the bleeding edge of new technology, stacks, new tools, you work across cross-functional teams, and you’re trying to break the silo between the Dev and the Ops, but you’re basically a DevOps architect with a very strong technology vision.
The other alternative to this is more technology focused very deep technical work. The other side to that is consulting, where you go more on the web part of it, you probably work in an SI or a consulting company. You work across Enterprises, drive business value, and you may be set up DevOps capability for large enterprises. You talk about organizational change management, this is an architect with a business vision. Now, you can’t directly become a DevOps consultant, if you’ve not done the pipelines and everything in between by yourself.
And then you evolve into a DevOps evangelist. Evangelists are typically one who has worked across multiple enterprises who have done various shapes and forms of organizational change management, and who’s created new roles and responsibilities in the organization. We spoke about probably setting up an SRE function, a release management function and those kinds of things. And this is who has enterprise structure for multispeed IT where some parts of the organization are moving extremely fast. They are into microservices, cloud native, and the other side of the organization. So that’s the typical career path of a DevOps engineer”.
About The Future Of System Administrators
“Today’s typical Enterprises are all moving towards using some parts of the Cloud, probably they will even go serverless in some portions, and move their data into the cloud over the next four or five years. Now let’s look at what happens to system admins, as this change happens. Their bread and butter – supporting Environments, IIS, WebLogic, WebSphere, etc. will disappear in the next five years. Most technologies will not be relevant because the way you deploy a cloud native application and application over a container is completely different than this. It may be around 20-30% of the infrastructure will still be heritage. Maybe some in a bank or in the retailers.
They’re also the way they are creating environments. Today, maybe it takes a week or ten days to create environments. We’re talking about immutable environments, creating environments in matter of hours, if not minutes, the way they do patching, the way they do release management.
If you look at the latest Upskilling industry report from DevOps Institute, that covered about 120 odd countries, they also say that 40% of the people said that resource and skill shortage is one of the top three challenges. And technical debt must be paired with talent debt. So the opportunity is out there for the system admins to evolve themselves into the new roles. The business requirement is there, the opportunity is there. Now it is upon the individuals, whether they want to jump on that bandwagon and move into the new workload of 60-70%. Or they want to stay at the guard of 20-30%, which will continue for a couple of years further. But then life is tough.
I don’t want to create a very bleak picture out there. But as you can understand large transformation programs like this don’t happen in one or two years. They take time depends on your organization and what phase of the transformation program it is in. But one thing very clear the wave is coming, and it will fundamentally change the way we have worked in the last 15-20 years. But there is no need to panic. As long as you recognize that the world out there is changing you have time to make the right moves, learn the right things, pick up the new roles”.
About SRE as a Option for Career
“Things like SRE were carved out primarily by the likes of Google. They operate in a very different space, they had a different set of challenges. And they came out with the concept of SRE, which works great in their context. Just renaming your support team on a random Monday morning and calling it an SRE team won’t really work. It’s a good career pivot, if your organization has people who can think through the journey, and tailor what SRE needs for your enterprise. Because your enterprise is not Google, and it doesn’t have the same challenges. So, if that is done it’s a good logical extension for people in the traditional app area assuming, that they are willing to pick up some new skills and change the way in which they have been working”.
About Other IT Roles and Steps for People Looking for Guidance
“If you’re working in a large enterprise in things like ITIL, for example, or any other shape and form of, if you’ve led a lean initiative, then the new versions of ITIL like ITIL V4 could be easy to pick on.
If you pick up infrastructure automation, good opportunity will be to go into infrastructure as cloud, looking at things like Chef, Puppet Ansible, TerraForm. And you can very heavily relate that to the way you used to create environments in the past. All you need to figure out is your area environment. How does that map to container? What’s the difference? And how do you map your traditional world of a virtual environment and virtual systems and how does that relate to containers? If you can make that shift that’s another good area to get into.
Then there is the DevOps engineer area. If you’re excited about creating software builds, shipping out stuff faster to customers, that’s potentially another area you can look at.
One of my mentors told me several years back: always pray true to your core skill. If core skill is system admin stay true to it, you just have to see how it maps in the new world. If your true skill is an infrastructure engineer stay true to that, because you spend ten or twenty years doing that. So don’t just jump and you know, start learning Kubernetes; it’s great, but probably is not relevant to us. Stay true to your core skill, figure out what’s the extension of your core skill in the new environment and then the gap how to bridge that. That is my three step algorithm for people who are looking for guidance”.
About Knowledge, Skills and Mastery
“You should always remember about the difference between knowledge, skill and mastery. What do I mean by that? You can at best master one or two areas in your entire life. Where you can be really, really, really good at it, you are the guru in that it’s just one or two areas. So that’s mastery. You can obviously have a number of skills. And you should have a knowledge of everything under the sun today. But the key is knowing what to master, what to get skilled on, and what to have knowledge of.
If you go to a conference, and they say serverless is the next big thing since sliced bread, you don’t go after the mastery of serverless. First, you want the knowledge of serverless. What is it? How is it relevant? Does it relate to what you’re doing or not?
The very simple guideline for that is just type the new technology named serverless on Google, if you can answer the first page, and if you can understand what’s written on the first page, that’s good enough knowledge to get by simple rule.
If that is something that relates to you, it’s interesting for you try and develop a skill around that. Go to Udemy, one of those online courses, pick up a course or two, probably use YouTube. Try a small proof of concept. It’s not about doing one course or two. It’s about building applications. Get a cloud account, download the tools, try something, build something. And then you will realize if you like it or not. And then go deeper. But stay with these three things: knowledge, skill, and mastery. Figure out which one to apply and where”.
