Developers Vs. IT: Striking A Balance

Organizations are paying quite a bit of attention these days to what I call “developer-centric” tools and platforms. Developer-centric tools and platforms seek to optimize the role of the developer, sometimes at the cost of other functions within an organization. This attention seems to align with the increased focus on containers and microservices-based architectures. Is it coincidental? I don’t think it is. Docker has a relentless focus on a developer-friendly workflow for its tools, which has paid off in developer adoption.

Having a developer-centric approach isn’t necessarily a problem, at least until the role of the developer starts to take precedence over all other roles. While it's important to help developers be more productive -- especially for software-heavy or software-only organizations that derive the bulk of their value from the output of their developers -- I also believe that it’s possible to sway too far in one direction or the other. For the vast majority of organizations, the answer lies in finding the right balance between optimizing developer workflow and enabling operations, networking, and security to also perform optimally.

This answer -- finding the right balance between developers and the rest of the groups within your IT organization -- is deceptively simple. Why? Because this balance can’t be achieved with technology alone, and that is how many organizations -- and many vendors -- will approach it.

Consider networking and network security policy. In the past, organizations have probably swayed too far away from developer productivity for security purposes, and the result was overly restrictive security policies that were inflexible, brittle, and onerous to manage. Developer productivity slowed because developers had to wait to get firewall rules approved, operating system configuration changes performed, and security audits conducted.

interop-las-vegas-small-logo.jpg

Then along came the public cloud, containers, and microservices-based architectures built with tools that focus heavily on the developer. Only the bare minimum of network security policy is exposed in these tools -- for example, the ability for the developer to specify the ports that should be exposed for the application to communicate across the network. The idea is that developers shouldn’t have to worry about networks or IP addresses or firewall rules -- they’re developers, after all -- developer productivity and code is what’s most important.

Naturally, this approach is as equally flawed, though in different ways, as the first approach. How can network security policy be implemented effectively if the right primitives aren’t provided? Exposing ports is only part of the picture; what about controlling the remote systems/endpoints that should be allowed to communicate with that application?

Here is where we find that technology alone can’t help organizations find the right balance. If you begin to expose more and more functionality to the developer -- for example, providing access to specify access control lists (ACLs) that control who and what may access the application a developer is building -- then does that begin to negatively impact the developer?

Moreover, what about separating build-time information from run-time information? Is it best for all this information to be exposed to the developer or should some of it be exposed instead to other groups? And if it is exposed to other groups, then how do you prevent yourself from falling back into the first scenario, where the security policy was so inflexible, so brittle, so difficult and time-consuming to manage that your organization’s momentum is slowed?

Organizations must strike a balance between too much or too little emphasis on developers, but also the right balance between technology and people. See, this isn’t only a technology problem, nor is it only a people problem. This is a problem that spans both technology and people, and therefore the solution must also span both technology and people. Adopting developer-centric tools and workflows can help improve developer productivity, but without an equal focus on improving communications between developers and operations/networking/security, you’ll just find yourself with a new set of problems.