It does not matter how you think about yourself or how good you may be at your job: Most employers see you as a cost center, aka an employee. You should be lucky enough to be a developer because only then you are considered as an investment.
You may recall Steve Ballmer’s amusing, sweat-drench “developer, developer” chant. As it turns out, he was right. It is all about developers, especially when it comes to cloud-native security.
Good developers are in high demand. The constant, ruthless IT innovation engine eats its own every day as ingenious advances upend the mainstream and disrupt the cutting edge with surprising regularity. In a winner-takes-all market, software developers are precious assets and a necessary part of the compete-or-die economy.
And they are expensive. Hired.com, a reverse Dutch auction recruiting company, provides transparent market data for this elite group. A Bay Area software engineer with three years of experience at a good company can command more than 20 offers with high six-digit salaries. These compensation figures make it painfully clear that the software developer is an investment and not a mere employee.
An investment must be nurtured to become productive, especially if that investment has legs and is in high demand. Cultivating an SW developer means understanding (1) what motivates her technically; (2) what unleashes her creativity; and (3) what enhances her efficiency. Getting in the way of any these three factors is a good way of hampering getting the best and the most out of the prized SW developer.
Jerry Chen of Greylock has coined the “developer-defined infrastructure” phrase. He explains that developers are “making underlying cloud infrastructure decisions. They are determining not only where will their applications run (private or public clouds) but how storage, networking, compute, and security should be managed.”
Developers have this power because, to a great extent, employers know that they need to give their investment the sufficient leeway to make them productive and happy.
Today, in most enterprises, application security audits are a periodic ritual forced upon SW developers. The ritual priest, the InfoSec guy, drones on a chant by reading seventy-three questions from a spreadsheet scroll. Did you do X? Did you do follow process Y? Did you use Z? Beware he who answers the question incorrectly, lest he unleashes the implicit ridicule of the priest, forces an audit, delays a release, and get a figurative fifty-lash punishment for the transgression.
Some forward-looking enterprises attempt to automate application security through RASP. RASP, or runtime application self-protection, analyzes an application’s behavior and its context with the goal of automatically identifying and mitigating attacks. This technology requires developers to compile individual libraries into their code, follow specific procedures, and use a limited number of frameworks to be fully effective. In other words, it gets in the way of creativity and efficiency and is unlikely to be technically motivating.
The ideal solution, therefore, is to allow the SW developer run free, using the tools of her choice, per her needs, and in service of her audacious personal and aggressive team goals. The security solution should be invisible to the developer, freeing her from the mundane tasks of certificate and key management, using specific encryption libraries, and so forth. At the end of the perfect day, the developer should only be focused on solving the difficult problems that make the product or project move forward by leaps and bounds.
The optimal solution also needs to have policy and visibility hooks for the InfoSec teams at the enterprise level. In other words, the right solution allows the developers to run fast and free while enabling InfoSec teams to keep the business safe through the application of the right security policies, monitoring systems in real time, and having the capability for audits and forensic analysis by introspecting system interaction at any given point.
There are many existing security solutions, applied at various points in the stack, that fall short today. There are two fundamental shortcomings in all of these solutions: They are operationally complex on one side, and they inherently have developer impact because of their intrusiveness and restrictiveness.
Martin Casado of A16Z has spoken extensively about “the rise of the developers” and their game-changing IT market-making power. As the developer-defined infrastructure takes hold and developers more heavily influence IT purchasing decisions, we can anticipate that legacy security measures will be flushed out from the cloud in favor for more invisibly pervasive, yet flexible and controllable solutions.
The market yet has to speak on what these cloud-native security solutions are, but it will state its case as it will need to preserve and capitalize on the massive investments being made by developers.
I welcome your comments and engaging with you in a dialog regarding the ideas discussed in this blog. You can Tweet me directly at @amir_sharif or in the comments section below.