We didn’t know you needed…
Many folks eschew the “cultural” component associated with DevOps. But bound up in “culture” is “communication,” and communication is critical to success not just of DevOps, but for any automation and orchestration efforts in the enterprise.
We didn’t know you needed… port 7243 open.
We didn’t know you needed… new DNS entries.
We didn’t know you needed… the client IP address.
We didn’t know you needed…
We didn’t know.
Those three little words illustrate, perhaps more poignantly than any other, the communications challenge that exists in many an enterprise today. Frameworks and scripts can only automate what you tell it to automate, and that means at some point you have to know. How do you know? That’s communication.
It’s a cliché in IT that network guys don’t talk to dev, and ops doesn’t like security, but the reality is that unless each of the operational domains that govern the production environment know what’s necessary to deploy an app into production, it can’t be orchestrated.
Oh, individual tasks like configuring a firewall or load balancer can be accomplished easy enough, but each of those requires application-specific information to be useful. You can’t open a port if you don’t know which one the app is using. Our Jan 2017 iHealth data shows that across more than 6000 customers there are 36,731 distinct (unique) ports in use. There aren’t that many protocols in use in the enterprise (there’s a lot, but not that many), which means a variety of sites are using protocols not on their “native” ports. Even web apps are spread across multiple ports. There’s the ones that no doubt come to mind when I say HTTP/S: ports 80 and 443. And there’s also often used alternative ports for those protocols, ports 8080 and 8443. Then there’s 8081 (used by 4605 different virtual servers, which approximately represent apps) and 8082. And there are, of course, a lot of ports above the privileged range (0-1024) that are in use with no discernable (to me from my data) related app. Cause port 10203 doesn’t have a “standard” protocol assigned to it.
The point here is that we can’t just assume a specific port for any given application deployment. That information needs to be communicated, in case someone wants to run the back-end for their public API on a different port. Security through obfuscation is still a thing, ya’ll.
In addition to such a simple piece of data, you can’t configure a load balancer if you don’t know what public IP address or host name it’s using or what back-end services should be included in each cluster. This is information you need, and that information has to flow from dev or ops to the folks who manage the systems, usually in netops.
That means communications. It’s not that you can’t build a tool or a form to collect that information. The (Other) API economy and internal digital transformation efforts nearly require that such exchanges be digital in nature. But in order to build a form or API to collect it, you have to know what data you want to collect.
You have to sit down and hash it out. Over pizza and coffee. Over beer and wings. Over e-mail or over the phone. Somehow you have to actually communicate with the all the various groups responsible for deployment of an application and ensure that you know what you need to know.
When folks talk about culture and communications in the context of DevOps, this is one of the things they’re trying to impart.
There’s more to it, of course, but we cannot ignore that at the heart of speeding things up to meet the demands of business and consumers is the simple premise of communication. Of knowing what an app needs to go faster, smarter, and safer. Because what you don’t know can’t be automated, and what you can’t automate requires manual intervention that can introduce delays and challenges into the deployment process. If you want apps to be faster and safer, you have to work smarter, not harder, and it all starts with communication across all the various stakeholders so you know what’s needed.
In a world undergoing a digital transformation, knowing really is half the battle. It’s the other half that’s technology. You can’t successfully execute on a digital strategy that includes, in part, a DevOps approach to dev and deployment, without both.