The 3-legged stool of enterprise Cloud adoption
I work in a large enterprise. We’ve been well along a journey to adopt the offerings of public cloud providers, as with so many others in our industry. My team is at the heart of that journey providing the major platforms and tooling that support/enable cloud adoption. But providing tools is never enough, and I’ve been using the analogy of a 3-legged stool to convey this challenge across our company. It’s been a successful model for us, teams using our enterprise pipelines have shifted about 80% of their workloads to one of our strategic cloud targets.
I don’t mean to say tooling is not important, because it is critically important to choose the right tools that are intuitive, reliable and scalable. We’ve certainly made bad tooling choices in the past, we invest far too much money trying to polish the sharp edges ourselves but ultimately find we’ve build our solution on an impractical foundation. Fortunately there is lots of great offerings on both the delivery and run side. My best piece of advise here is to not turn to vendor white-papers promising incredible ROI and legendary service. Look to the community, look to your competitors, look to your idols. Continuous integration systems and cloud providers are now commodity solutions, they are not your differentiators. Choosing something that no one else is using will not give you a competitive edge.
But in a large enterprise there is looming presence of regulations, governance and attestation. So even if you find the right tools, you can’t just hand over access to your application teams. We first need to build the next leg of our stool..
I use instrumentation as a bit of an aggregate term for the inspection, collection and enforcement of enterprise controls including inspection, enforcement and prevention of roque behavior. It’s critical this instrumentation is not an impediment or roadblock. The slickest software delivery pipeline is moot if teams have to perform manual sign-off or approvals in some tangental process.
My best piece of advice here is a piece of advise a mentor gave me, a principle known as Chestertons’s Fence. Don’t run around challenging every security and compliance policy in existence complaining thy slow you down and are archaic. It’s critical to understand that when these policies were created they were the best way we knew how as an organization to reduce risk, and accomplish a goal. Until you deeply understand that intention, and can demonstrate understanding to your security and change governance teams, they have no reason to understand your needs. With some great collaboration we have been able to modify policies and introduce automation that allow teams to move fast and stay compliant.
So if you can find the right tooling, and instrument the critical policies you still have one major hurdle to cross…
The truth is that when you’re trying to move 5,000 IT staff to a a fundamentally different paradigm, it takes lots of education. I highlight this as the last leg of the stool however because it should, in my opinion, proceed the other work. You will inevitably have a small percent of the population that is ambition, savvy and progressive enough to figure it out on their own. Its these teams and individuals that will help you get the right tooling and instrumentation in place, willing to overcome small hiccups and even roll up their sleeves to submit improvements.
Once your early adopters make progress, and proven a viable path you need to enlighten others. We’ve been holding a series of hands-on workshops where teams start new apps from scratch, and get them deployed to Cloud Foundry in AWS within the course of 1-day lecture & labs. The lectures cover principles of being cloud native, a.k.a. 12/15 factors, while the labs give them a chance to apply the practice first hand. We’ve also been exploring smaller and more focused migration workshops where out experts help a team modernize a legacy monolith by carving, abstracting and re-architecting the pieces to be cloud ready, if not cloud native.