I got the chance to present at AWS Summit in NYC on 7/12! I’ve had several people ask me what the speech was about so I thought I’d throw together a few blog posts that walk through the talk. I’m going to break it up in to three posts:
- Part 1: My CIO Doesn’t Do Enough Cloud
- Part 2: A Cloud Transformation Program That Gives Confidence
- Part 3: Fit-For-Purpose Platforms
In the first post I covered the common fears that I hear from CIOs when it comes to adopting more cloud. In this post I’m going to dig in to three conceptual things you can do with your cloud transformation to address the fears that come up around security, cost, and effective transformation.
The first point that I made is that the cloud is not ONE place. The analogy that we used was imagine being asked, “Do you want to go on a trip?” A good trip for me and a good trip for you are likely very different. Workloads are very different and you can’t put them all in the same place. This is particularly true in enterprises that have been running long enough to have brittle legacy machines and code that’s not worth refactoring. It’s popular to say that everything should be cloud native and there should never be tech debt, but in the enterprise we know we’re going to need to create environments that have to run workloads that can’t scale horizontally… maybe even some that no how to run CICS or COBOL. To make cloud transformations more successful, you must establish this up front and build fit-for-purpose platforms for each. These will address the varied architectures necessary to optimize security and cost in the cloud.
The second point that I made is that this is not just about place, it’s also about the services. The analogy here is to imagine that we all need help writing English good well, but we all need different kinds of help. If you’re a fluent English speaker maybe all you need is spell check. If you’ve only been speaking English for 6 months you may want a tutor. Similarly, some app teams will want to provision infrastructure as code from their pipelines while others will prefer to order manually via a service catalog (maybe even with some architecture consulting). Too many companies try to make a single service management “plane of glass” and end up stifling innovation in some places and not preventing vulnerabilities and overspend in others.
Finally, I counselled the architects in the room that they have to think of their cloud transformation as never over. The analogy here being, imagine what would have happened if the automotive industry had stopped developing cars as soon as they had something that met the minimum definition. We’d still be driving cars with 30HP and 12mpg.
For cloud transformation, it’s best to imagine this as a graph with the Y axis being the value of the capabilities you provide to app teams and the X axis being time. You never expect those lines to plateau, why would you expect your cloud transformation to be “over”?
In the next post I will break down the architecture implied by “The cloud is not one place.”