As far as most people are concerned, a company has “The IT team” and no one seems to understand the different roles within the team. Since IT services are gaining importance for businesses, it is important to bridge any communication gaps. But let’s not rush in. Every company treats this differently, but let’s look at generic definitions…
In the Red Corner: The App Guy
The “App Guy” – Weighing 190 lbs, his hand seems to be permanently stuck to a warm cup of coffee. He’s got a slogan on his T-Shirt, one of the ones that make you think a little (like – There are 10 kinds of people in this world, those who understand binary and those who don’t). Wearing ripped jeans and glasses, his other hand is holding his phone, and he’s reading an email.
In the Blue Corner: The Infrastructure Guy
The “Infrastructure Guy” – Weighing 180 lbs, at first glance, he looks very similar to the App Guy. Wearing a Polo Shirt and Jeans, he’s drinking Red Bull, and he’s cradling his laptop on his actual lap.
OK, I’ll admit it. The stereotypes suck. But in IT teams all over the globe, there’s a conflict going on between these guys. While both teams have the same business objectives, their immediate goals and priorities are different, and that is an organizational challenge that is becoming more essential to be solved for businesses as they depend more and more on IT.
Let’s look at an example:
Payroll application goes down. Infrastructure guy is certain the problem is in the application. Application guy has been there before, his code is perfect, and he’s sure the Infrastructure team haven’t been thorough. But his log files don’t make any sense to any one but him. Stalemate.
Let’s take a closer look at the teams these guys belong to:
The Operations Teams: building and maintaining IT systems
In general, the Infrastructure and/or Operations team is usually responsible for the IT infrastructure, including servers, storage, networking and in most cases today, the virtual estate. The role varies from company to company, and sometimes you’ll find there’s ‘sub teams’ for the different specialties. The objective of the team is to build and maintain the IT systems. This includes the day to day management and timely responses to any outages, failures or system degradation.
The Software Engineering Team: writing, testing and deploying code
The App Guys (or Girls!) are usually members of the Software Development or Software Engineering team. For the most part, organizations can purchase software to deliver certain functions, however, there might be a need for bespoke software to deliver a certain service to the business. The Developers will work with the business to get the requirements, and are responsible for writing the actual code, testing it, possibly deploying it and updating it. The team will consist of actual developers or coders, as well as Project Managers, Quality Assurance (QA) and Business Analysts – all depending on the size and complexity of the organization.
Both of these teams have different challenges. The Infrastructure team might be struggling with how to move from a reactive troubleshooting approach to an approach that enables them to plan better. The Development Team could be dealing with how to deliver on time and within scope (and budget). One thing is clear though: in order for the business to be successful, these guys have to work together. The “DevOps” movement has done a lot to help with this, but in many cases there is friction.
I’ll start out by laying out my allegiances. In a previous life, I worked in an Infrastructure team. But, some of my best friends are developers. In my case, the manager of the IT function was essentially the lead developer, which went a long way to making sure both teams worked together smoothly. But not all organizations are that lucky.
Red versus Blue Corner: A deep dive into the different views
As an Infrastructure Engineer, you have to keep an eye on many things. When the users (your customers) are not happy with a service, you have to pin point what the root cause of the issue is. Is it a hardware problem? Could it be the network? Maybe the application isn’t working properly? When the problem is the software that’s developed in-house, it’s important to identify if the problem is with the infrastructure, or if the software is to blame. Ideally, you want to pass to problem on to the App Guys.
But you see, the App Guys have their own problems. Their day to day task is usually writing software, not troubleshooting or fixing it. So whenever they are asked to look at a problem in production, it’s usually a distraction. Any serious or ongoing problems means that project deadlines will be missed, and nobody wants that. For the most part, they want to make sure the Infrastructure Guys have ruled out problems on their side of the fence, and not just passed this problem on.
Potential areas of communication challenges:
Developers do not understand how much management is behind “just spinning up a VM”
Conflict may also come from other sources. Virtualization has enabled a new and faster way of delivering IT Services. I still remember when delivering a new piece of software would take a few weeks. Now, you can deliver a virtual template in minutes, and have a service running in a few hours. This gives the impression that virtual computing is ‘free’. Not true. Even if you are using a Public Cloud provider, someone has to maintain the service and pay for it. The more servers you have, the more likely you are to have contention and performance issues. Infrastructure guys are very aware of this, and have to plan ahead for capacity. Developers want capacity and want it yesterday. “It’s just a virtual server, can you just spin it up for me?”.
The physical machine mindset
What about server sizing? When I bought my gaming laptop, I went for a top of the line system, with 32 GB of RAM, Intel i7 Quad Core over clocked CPU (4.1 Ghz), 2 Terabytes of storage. Why? Because I don’t want performance to be an issue. So I got the biggest and the best machine out there. And back in the day when we were running everything on physical infrastructure, it made sense to take this approach in the datacenter.
Virtualization means that you should only really configure a virtual machine with what it needs in terms of compute. When you oversize the virtual machine it causes contention and you start to see problems like ready queue, memory ballooning and swapping. Some App Guys however, are stuck in the Physical Machine Mindset. “I want the biggest baddest Virtual Machine out there, with as much resource as possible.”
The IT organization is actually a department with very different teams, different objectives, different challenges and sometimes, this entails communication challenges. Both teams need to find a way to work together. I’ll include some tips on how to make this happen in the next post.