I was reading Mike Kavis’s Do This, Not That: 7 Ways to Think Different in the Cloud and encountered what initially sounds like reasonable advice…but becomes absolutely unrealistic. I’ll explain why at the end. Mike writes…
Think Empower, Not Control
The first thing many companies do when they start their cloud initiative is figure out how to lock it down. Too often, the people who own security and governance spend months (sometimes years) trying to figure out how to apply controls necessary to meet their security and regulatory requirements. Meanwhile, developers are not allowed to use the platform or worse yet, they whip out their credit card and build unsecured and ungoverned solutions in shadow clouds.
We need to shift our thinking from “how can we prevent developers from screwing up” to “how can we empower developers” by providing security and governance services that are inherited as cloud resources are consumed. To do this, we need to get out of our silos and work collaboratively. Instead of enforcing security and governance controls by requiring rigorous reviews, we need to bake policies and best practices into the SDLC.
Start with continuous integration (CI). Automate the build process and insert code scans that enforce coding best practices, security policies, and cloud architecture best practices. Fail the build if the code does not meet the appropriate policy requirements. Let the developers police themselves by using automation that relies on policies established by the security, governance and architecture teams. Set the policies and then get out of the way, letting the build process do the enforcement. Developers will get fast feedback from the CI process and quickly fix any compliance issues – they need to or the build will never get to production.
Once applications are deployed, run continuous monitoring tools that look for violations or vulnerabilities. Here’s a novel idea: Replace meetings with tools that provide real time feedback.
Ahh, the magic of the perfect Software Development Life Cycle empowered by the perfect DevOps continuous integration. That will surely solve the problems of breaking down silos and collaborative working, right?
Sadly I’ve yet to encounter a technology or methodology that magically restructures the IT organization. The IT organization structure has come into place due to business, IT management, and cultural drivers of the organization. There are technology changes that have forced restructuring, but it’s always painful and time consuming. Breaking silos is one of the hardest (as this usually challenges political control and authority structures – and people are loath to give up control / authority / influence.)
Mike focuses on the second part and skips a key idea he presents in the first part. Namely, give the developers the environment that’s the target. Or, expanding on this idea… ARCHITECT your systems for their target environment. Systems architected for cloud or hybrid scenarios (should it matter to the application if it’s deployed locally, locally on dedicated servers, VM’s, soft partitions, private cloud, public cloud…or a mix of all the above?)
Systems can easily be architected for distributed deployment…IF that thought goes into the requirements early on. This may mean messaging and/or event driven architecture instead of real-time web services, even layering internal components to pass events instead of locally calling or instantiating. By doing so the architecture becomes micro-service oriented, which at the macro level means component groups can be bundled into deployment packs and deployed across the various server / resource models as needed.
It’s not can we break down the silos between people and teams – which may be appropriate but long and painful and STILL result in unwieldy systems. It’s how we model the interaction between and within the silos that will give the flexibility to deploy anywhere and coordinate/communicate/integrate practically automatically.