Building internal cloud platforms: Balancing control vs. usability

July 25, 2019

A blog post Mike Kavis, managing director, chief cloud architect, Deloitte Consulting LLP

Companies are primarily embracing public cloud for three core benefits: cost reduction, business agility, and access to innovation. The combination of infrastructure as code and fully managed services, such as database as a service (DBaaS), allows application builders to focus on meeting business requirements. Most of the infrastructure and the “IT plumbing” responsibilities can be offloaded to the cloud providers.

The rate of change being introduced in the age of the cloud far exceeds anything we have ever seen, and with great speed comes great risk. Without the right controls, organizations could go down a path that might lead to large breaches, external attacks, and other significant issues. To mitigate these risks, many companies stand up a cloud platform team to build guardrails around the chosen cloud service providers (CSPs) and become the central authority for cloud access and policy.

Why becoming an internal cloud provider makes sense

Cloud providers provide a robust service catalog that includes features for security and auditability. Each service goes through an audit process for regulatory certifications such as PCI, HIPAA, SOC, and others. The cloud providers cover the bases for about 80 percent of their customers’ needs. The last 20 percent represents the specific policy requirements unique to each organization. Building a cloud platform with guardrails on top of a CSP’s services is how most organizations attempt to address the remaining 20 percent .

Without an internal cloud platform, builders are left to implement the remaining 20 percent of policies. This is not a recipe for success. Builders are great at building software assets, but rarely are they skilled at things like network security, operating system patching, vulnerability scanning, and other tasks required to mitigate risk.

Cloud platforms can and should manage that on the builders’ behalf. But there is more to it. There are also security architecture best practices. These can be baked into the underlying infrastructure templates so that the builders inherit policy enforcements by provisioning from an approved and hardened image. Adding security scanning to the CI/CD process is another way to enforce security best practices.

But even that is not enough. There are other considerations like identity access management (IAM), access to public IPs, firewall rules, and many other areas where the wrong design decisions or lack of a design decision can expose a company to great risk. Cloud platforms are designed to minimize these risks and standardize policies. By inheriting the policy enforcements of the platform, builders can focus on meeting business requirements.

When platforms become too restrictive

A problem that I keep seeing across organizations is that these platforms get so locked down that builders have a hard time getting work done. Platform teams too often only consider the needs of the security team and the governance, risk, and compliance (GRC) teams, with little to no regard to the usability of the platform. The more roadblocks developers face, the less agility they get from the cloud.

Another issue is that platform teams often like to bring their favorite corporate security tools to the cloud; many of these tools are not cloud ready or have been tweaked to work in the cloud. Many legacy tools are cost prohibitive and some organizations don’t even allow open source solutions to be considered. This can drive up overall cloud costs as the builders pay a huge tax to build on top of a platform that doesn’t meet their needs.

Then there is the innovation value proposition of the cloud. Many platform policies treat all environments the same. Whether a builder is deploying to production or asking for a sandbox, very rigid controls are often in place. Sometimes, the controls are so restrictive that builders can’t experiment and learn from new services or new approaches to solving problems.

If the value of the public cloud is cost, agility, and access to innovation, and the internal cloud platform makes everything expensive, slow, and hard to innovate, the value of the platform is very low. Mitigating company risks are important, but handcuffing the ability to deliver value can put the company at risk of losing market share. Platform teams must balance risk with creating business value. To do this, the builders must be viewed as customers and the security and GRC teams must be viewed as stakeholders, not the other way around.

Balancing the needs of GRC and builders

To build an internal cloud platform that meets both the builders’ needs and addresses the company’s policies, start by understanding who is the platform’s customer and who is the stakeholder. Public cloud is a development platform. It can empower builders to create value for their customers faster, cheaper, and gives access to innovative capabilities that typically were not available to them before. In the digital age, most industries are undergoing disruption and a key competitive advantage is a having a high performing software development culture.

The goal of the platform should be to empower and enable high performance while providing the appropriate guard rails to mitigate risks with the customer acting as the builder. Usability of the platform should be just as important as security and compliance. Cloud platform teams should have a model that puts the customer (builders) front and center and the stakeholders around the platform to provide value in a controlled, repeatable, and fiscally-responsible way.

When implementing policies, that platform team should ask “how can the user experience be as frictionless as possible?” For example, if there are policies not to allow certain ports, IPs, or other network requirements, instead of just blocking or removing configurations, try alerting or at least notifying the end user of policy violations. Eliminating configurations without feedback is not productive for anyone. Platform teams must shift their mindset from command and control to assist and advise. Most builders want to build highly secure and compliant software but often need help to do so. Serving as the “department of no” and providing hurdles without consultation is counterproductive. I have witnessed too many instances of builders being blocked for good reason but with no notification or information. It often leads to days of troubleshooting, emails, meetings, and conflicts. The end result is usually a builder seeing the platform team as non-productive and the platform team seeing the builder as incompetent. In reality, both are trying to do the right thing for their organization.

When the builder is seen as the customer, then the engagement between the two becomes more consultative than combative. After all, we wouldn’t interact with our external customers the way many builders and platform teams interact with each other internally.

The path forward

Platforms teams need to take a more customer-centric approach. Security and GRC are of upmost importance but not at the expense of creating business value to our customers. Platform teams that don’t heed this advice risk pushing their customers (the business units trying to build software) to seek other solutions either inside or outside the company. In the true spirit of DevOps, builders and platform teams should work together closely to create value while mitigating risks. Think like a cloud provider: what the major providers are so good at is listening to their customers and then rapidly delivering new features or services to delight their customers. Internal cloud platform teams should do the same for their customers—they are the builders within their own walls.

Please contact cloud@deloitte.com for any inquiries around this or other previous On Cloud blogs.