Did you change your governance structure as a result of Public Cloud adoption within your organization? Have you found that application owners are still bypassing your centralized offering and going directly to Public Cloud providers? And finally, do you find you end up supporting these snowflake applications and therefore eliminating the economies of scale associated with centralized enterprise IT? I don’t believe you are alone. Let’s talk about what we can do.
Let’s blame OpenStack
In the days of Kubernetes, it’s easy to look back and poke fun at how naive we were about private cloud. As an industry between 2012 and 2015, we believed we could take a fast-moving project such as OpenStack and build cloud-like capabilities within the private data center. No doubt, there were some early success stories. I recall talking to Comcast about their deployment and how they couldn’t keep up with the demand from internal application owners and developers.
Companies such as Comcast staffed teams dedicated to deploying and managing private cloud platforms. We’ve come to know these teams as Platform teams within the enterprise. OpenStack was a great rallying cry to implement the governance needed to support the innovation promised by cloud technologies. However, the industry realized purpose-built offerings such as AWS, Azure, and now GCP were simply much better at offering the cloud experience.
Over the next few years, we realized the enormity of digital transformation and, more importantly, the complexity of cloud operations. Many platform groups’ scope changed as the enterprise uncovered vastness of the talent deficient for cloud-proficient engineers. The industry couldn’t keep up. In my experience, organizations did a poor job of transitioning internal cloud R&D from the Platform group to general operations. The demands on the Platform group snowballed.
If you look at a typical Platform group, the charter of supported technologies may include:
The legacy OpenStack deployment
Message queuing (Kafka, TIBCO, RabbitMQ)
Automation (Ansible, Chef, Puppet, vRealize)
Public Cloud control plane (Azure, OCI, GCP, AWS)
Misc. developer tooling
PaaS (OpenShift, Tanzu, CloudFoundry)
Essentially, the Platform group became the dumping ground for any technology that’s cloud-related. Or at least any technology that requires a similar skill set. Amid the scope creep, it’s been my experience that many of these Platform groups lost sight of their charter – Providing a Platform.
Internal customers drifted away as there wasn’t a clear differentiation of value. How did engaging centralized IT improve the business outcomes of my projects?
What do you offer that’s unique?
AWS has 175-services as of this writing. It also has something along the lines of $10B in revenue a quarter from these services. Enterprise IT doesn’t have the same economics. Platform teams must learn to operate within the boundaries of these economics and resource constraints. So, ask yourself, what value do you bring to application owners? What’s the platform, and how is it uniquely different than the Public Cloud?
I’d challenge IT leaders to re-think the charter of the Platform team. Is the uniqueness of the team the ability to replicate or even abstract Public Cloud services? Or is the value less about the technology and more about enabling the successful adoption of the technology within your domain/industry?
I’m of the mindset to leverage these technology companies for what they do best, commoditizing the technology. Even Dell Technologies, with its PowerOne platform, is looking to abstract the complexity of automation. Let your team become advisors to the business. The Platform team’s task should be that our trusted advisor ensuring architectures and processes scale appropriately for your enterprise. Maybe it’s time to get out of the business of building cloud capabilities and refocus on the mission of enabling the business via the direct knowledge of your industry.