DevOps, the Cultural Shift

Tracey Flanders Published Aug 2, 2014 at 7:26 PM MST by Tracey Flanders Tags Cloud, DevOps  Leave comment

Let me first start by describing DevOps. It isn't necessarily a title or job description, it's a form of culture. If you've been in IT long enough, you know change is inevitable. For those companies today, who wish to succeed in the cloud era, they will need to adjust their teams skill-set.




Is this a another trend?

I don't think so. Will those companies that can adjust faster be better off? Probably. Let's face it, cloud levels the playing field for everyone. No longer do you have to build multimillion dollar datacenters or commit to a 3 year colocation contract. The cloud changes all of that. But it all hinges on your IT team's skill-set.


When I first came to work in the IT world, Big Iron mainframes were predominate in most companies. The middleware servers were just a small component of the overall system. Sure there was a time when it was cool to virtualize Windows 2000 on an IBM AS/400. Around the same time VMware was taking off, you could only install it on an IBM x86 server, I think it was a P-Series 440.


Anyway, that was the beginning of the new virtualization era. VMware was a good place to put development systems, if you didn't mind the slowness. I started working with VMware when 2.0 was released. Once multicore processors in servers became a reality, the mainstream need for Big Iron was over. I'm sure mainframes are still sold today. But I don't see that skill-set as often, 17 years later.


In any large company there will be siloes of skill-sets. For instance the network team wouldn't typically be able to build a VMware vSphere cluster and vice versa for the network stack. But, what you do find is they work together to bring up these large network, compute and storage platforms. The only challenge is it can takes weeks to month to deliver those foundational platforms. It is an extremely complex and expensive path, lots of moving parts. Cloud services change all of that, allowing IT to become agile.



DevOps defined 

When I think of DevOps, I think cloud, startups, really smart people, open culture  and collaboration. In my opinion, that's how all IT shops should work. IT is not here to solely do IT, it exists to serve the business. If we're not not providing value back to the business, what's the point. Process and procedures tend to get in the way of a good IT and business relationship. I'm on the side of IT and ask myself these questions frequently, is this right for the business? Or is this because we've done it this way all the time? The term "Think outside the box" comes to mind. With a DevOps culture, you'll find that the skill-set is both sysadmin and development-like combined.



Does that mean a developer is doing sysadmin work? I'd say a smart one would be automating the mundane sysadmin taks. For those of you that have a scripting or developer background, the transition may be easier. You are already a consumer of IT Infrastructure, so you see it as merely as a resource. You're not worried about what datacenter it's in, etc. On the flipside, sysadmins who can script and have a good understanding of applications, you're well on your way. Do developers need to understand infrastructure? In a sense, yes. They don’t need to know the inner workings, especially in a IaaS like AWS. But they will need to understand high availability, redundancy, and a little networking.


You can see how this would be a challenge in much larger companies, who have the siloed skillsets and the boundaries of responsibilities. 



What about traditional IT?

If you were lucky enough to be around during the mainframe era, did you see many of those people cross-training to the middleware platforms? I did see some, but most were complacent. So what does that mean for those people who are used to the traditional way of building IT platforms? Over provisioning resources, building for the biggest peak load. Well, I'd say we are at the turning point of that culture shift, DevOps.


Does this mean you need to put down your console cable to start writing code? Not necessarily. But over time the more you can learn to automate and take advantage of those frameworks, the better. Does this mean your job goes away because you automated things? I don't think so, I think it's going to let you focus on the things that are important, what the business needs. Think about it. If you had automated your daily, weekly t asks,what's left? The cool stuff you want to do. Rather than doing those repeatable mundane tasks, you'll be able to focus your energy on actual products. This will require most people to move outside their comfort zones. Building products means knowing applications. Good or bad, that's the reality.


One place I worked, we were building the next generation healthcare system based on a 6 year, $250m contract. There was a team that managed the legacy system (they were termed the legacy team, unofficially of course), and then there was the new team, building out the next-gen system. Guess what happened to those who didn't embrace the new ways or learned to support the new system once we cut-over? Not to say that's how most companies would do it, but business is about making profits. The morale of this story is change is good, change is inevitable, be prepared. This doesn't mean you loose your job in the next 5-10 years, but I bet you're not going to be on the new team.



Encouraging the shift


If you're a director, VP or have the authority/iinfluence, start by building a cross functional team. Pick your biggest change agents, people willing to change and blaze the trail for others. Place them next to each other, fly in those remote colleagues more often that not. Teach them to feel vulnerable when they are collaborating together, that will promote knowledge sharing.  Promote collaboration, build or arrange areas with white boards, comfy chairs, etc.  Challenge them to work as a team on projects. It’s worthwhile to do off-site team building activities, it removes distractions.




People will always lean towards what they like to do. Out of all the teams I've managed or been a part of, if you collaborated together, you always filled the gaps necessary to succeed. It can sometimes take months or years, but once you have the team synergy, you've got a well oiled machine. Just remember when colleagues leave or are hired, the team dynamic changes. Be prepared to rinse and repeat.


My advice? Never stop learning. If you're like me, you love technology and collaborating with people who share your passions.  Below are some skills you should become proficient with.



Cloud providers



Leave comment

We welcome your participation on our website. Please keep your comments civil and on point. Your email address may be used to notify you of comment replies.
By submitting a comment, you agree to these Terms of Use.

Login to comment on this article.