Platforms play a critical role in the modernization plans for most enterprises. There are a variety of reasons for this, including speed to market for software projects, consistency of Day 2 operations, and heavy automation of everything from code reviews to key rotation. However, one large customer recently demonstrated to me how platform adoption can change one of the most challenging process-alignment issues in IT: consistent, auditable security and compliance.
A little background
This customer is a large, heavily regulated enterprise that operates in numerous lines of business. Its portfolio of services numbers in the thousands, and increasingly its customers rely on web and mobile user interfaces to interact with those services. Its rate of application deployments is in the thousands per week, and each of those must meet stringent compliance requirements. The challenge the customer accepted a few years ago was to look into cloud-native options for modernizing its approach to application development and operations.
Initially, our intrepid enterprise faced the same issues most companies face when adopting a new platform. It had to prove to multiple regulatory and internal compliance stakeholders that the platform would not only meet their requirements, but would do so without having a negative impact on developer or operator productivity. So, proof-of-concept projects were initiated, engagement plans were drafted, and the first production applications were deployed within a year.
Here’s where things get interesting. Once the various security, auditing, and other compliance and regulatory teams had an opportunity to study cloud-native development, and integrate platform data into their control processes, they became extremely supportive of the project. The security and audit teams gained visibility into what was actually deployed and which systems were affected by CVEs and regulatory changes. They also gained control over the technologies without unnecessarily limiting the options available to developers. These teams—traditionally seen as roadblocks—actually became strong advocates for the platform, standing shoulder to shoulder with the platform operations team.
Developers as roadblocks
Ironically, the only serious objections to use came from some developers. This is the inverse of what we usually see in software modernization efforts. Very often, developers push the hardest to adopt tools that simplify how they work. New development languages, open source automation tools, and debugging aids are readily available, enabling experimentation by developers eager to reduce toil and bureaucracy.
Conversely, the operations, security, and audit teams usually enforce checks and balances, demanding time to review each proposed tool. They only grant permission after seeing extensive proof of each tool’s viability. This isn’t a bad thing, but it has to be applied to each project with each new technology, and it’s frustrating to the developers who want to move faster than the process allows. In this case, however, they are pushing for new automation to reduce their own toil.
So, why are the biggest challenges to cloud-native coming from developers? I believe it’s quite simple, really. Until now, software developers were forced to own the entire stack that define their application, from operating system through user interfaces, in order to ensure the security and compliance of their application. Changes to operating system configurations, for example, could have significant impact on compliance, and the developer has traditionally been seen as responsible for any violations. Thus, developers evolved a reasonable concern about control of their stacks—or at least control of when and how those stacks changed.
Cloud-native is a different world
However, strong cloud-native operations practices enable many key security and logging functions to be managed independent of applications. Things like OS patching, credentials management, and network configuration can take place at the platform level, and often are applied to all applications at once without disrupting developer productivity. Application teams can start with a base set of approved elements to build their own security and compliance case, and those elements can be updated as needed—usually with no downtime.
For this customer, getting development teams that have not yet embraced cloud-native to do so is a challenge. There is good news, however. The platform enables detailed reporting of both developer and platform operations activity. When these activities are combined in a single timeline, the operations team can clearly demonstrate to development teams that compliance activities have little or zero impact on developer productivity, deployment success, or availability. Cloud-native automation makes its own case for a win-win outcome.
As you look at the ways your enterprise modernizes software practices over the next few years, consider that cloud-native platforms provide more than just deployment and operations automation. They can also have meaningful and positive impact on traditionally bureaucratic processes. Identify those individuals or teams that might not understand the benefits of that impact, and plan accordingly to address those audiences.
More importantly, don’t assume that the resistance to change will come from traditional actors, but be ready for the possibility that you will experience an "objection inversion" that presents new opportunities to demonstrate real value across your organization.
