Cloud consumption and DevOps automation is not just a technology change. It is a paradigm shift that managers participate in as well, but don't always realize it. One of the paradigm shifts involves cloud governance. If managers apply governance tactics developed over the years, they risk many of the benefits obtained by cloud consumption including speed to market. Having seen this transformation at several organizations, I've some thoughts on the topic. Please take time to comment if you've thoughts that I haven't reflected here.
Place automated guardrails on cloud usage instead of manual review processes. In short, when new policies are needed or existing policies modified, work with a cloud engineering team instead of adding manual review points. The benefits are:
- Fewer review meetings
- Reduced manual labor with both management oversight and application team compliance
- Added security as enforcement is more consistent and comprehensive
- Evolves as your cloud usage grows and changes
- Allows decentralized management of cloud resources which frees application teams to innovate more.
This is a paradigm shift over what was needed in data centers. Hardware infrastructure found on premises makes governance and its enforcement manual. This leads to long lead times to acquire and configure additional infrastructure and makes governance a constraint to bringing additional technical capabilities to application teams and users. Manual approvals and reviews are needed costing time and management labor.
In the cloud, infrastructure automation is possible because everything is now software. Networking, infrastructure build-outs, security privileges/policies, and much more are now completely software configuration and don't involve hardware. The software nature of the cloud makes the automation of governance in the cloud possible. Once automated, governance is no longer manual. Governance is enforced automatically that will provide enterprise safety. As a consequence, the need for manual approvals decreases if not entirely eliminated. This frees application development teams to innovate at a faster pace.
What types of automated guardrails are possible?
Whitelist cloud services application teams can use. As an example, some organizations have legal requirements, such as HIPPA or FERPA, that need to be adhered to. These organizations usually have a need to whitelist services that are HIPPA or FERPA compliant. As another example, some organizations standardize on third-party CDN or security products. They commonly want to prohibit cloud-vendor based solutions that aren't a part of the standard solution.
Whitelist cloud geographic regions application teams can use. Some organizations don't operate world-wide and want cloud assets existing only in specific regions.
Automatically remediate or alert for security issues. Most organizations have specific plans for publishing cloud assets on the internet. As an example, one of my clients automatically removes non-authorized published ports to all internet addresses (CIDR 0.0.0.0/0) within a few seconds after such a port is opened. Another example, a customer of mine provides alerts when people are provided security privileges in addition to non-security administration privileges.
Automatically report and alert on underutilized cloud resources. Underutilized resources often cost money to no benefit. These resources are generally computing resources such as virtual machines. Alerts like these provide ways to lower cloud spend as it's often possible to downsize the compute resources.
Automatically report and alert for unexpected cost increases. Alerts like these need sensible thresholds. This alert usually prompts a review and possible remediation of the application causing the cost increase.
Schedule uptime for non-production resources to save money. Often, organizations don't schedule downtime for non-production environments off-hours. Enterprises operating worldwide might not have this option as effectively there aren't "off-hours".
How can automated guardrails avoid becoming a bottleneck?
Application teams do not like constraints of any type. Having been on application teams for many years, I understand their sentiment. There are ways to keep guardrail development from becoming a bottleneck.
Fund automated guardrail development and maintenance. Like any other software produced by the enterprise, automated guardrails need development and support resources. Without adequate funding, they won't react to changing needs on a timely basis. Additionally, recognize that inadequate funding for automated guardrails will result in productivity losses for individual application teams across the enterprise.
Work with application development teams to identify and prioritize needed enhancements. This provides visibility into the guardrail backlog. Additionally, application teams can participate in prioritizing enhancements. Make them part of the process.
As cloud platforms evolve and change, automated guardrail development and maintenance is an activity that never "ends". Cloud governance is a continually evolving feedback loop. There must be a reasonable process for application teams to propose modifications to existing guardrails. As cloud technology changes over time, advances are made in current cloud services and new services invented. as an example, one of my clients must restrict cloud services used to those that are HIPPA compliant. As advances are made, that list grows over time and needs to be revisited.
As a manager in charge of cloud governance, what does this change mean to me?
Declare "war" on manual approvals. Instead of adding manual review/approval processes to govern cloud usage, engage a DevOps or cloud engineering team to enforce your desired behavior. A colleague of mine calls these "meat-gates". They slow everything down, both for management and application teams. They hamper delivering new features to end-users by slowing down application teams.
DevOps automation is your friend and ally. It allows you to set policy and not need to devote as much to enforcement. You specify "what" policies you want to be enforced. DevOps automation engineers construct and maintain the enforcement of the policies you choose.
Conclusion
I hope you find these thoughts useful. I'm always open to additional thoughts. Thanks for reading this post and taking the time to comment.
No comments:
Post a Comment