PaaS Is Not Enough
I rarely get it right the first time.
Shortly after Cloud Foundry launched, I realized that I'd made several mistakes. Not so much in architecture or scale — abstracting away all details except applications and services indeed appealed to the new DevOps culture. What I missed was how the first Open PaaS for the enterprise solved little of the real problem.
I often heard the phrase, "running out of runway"
Enterprises constantly struggle to go faster, while also remaining as safe as possible. Cloud Foundry was made to speed up the deployment and lifecycle management of modern greenfield apps. In many enterprises, this made up a small percentage of deployed workloads. Moreover, the presence of multiple systems actually introduced more friction between connected workloads from Cloud Foundry and a VM-based system (like vSphere) or more recently, OpenStack. It was tedious and brittle to manage multiple systems and to understand policies around who can access what across these systems. In the early days, I often heard the phrase, "running out of runway" used to describe Cloud Foundry after the demos and toy systems had been deployed.
A modern platform should be able to deploy a diverse set of workloads
For today and future needs, a modern platform should be able to deploy a diverse set of workloads, from a plain Operating System, all the way up to a greenfield application, and everything in-between. In addition, it needs to present the proper layer of abstraction for each: With an OS, give it to me and get out of my way, as I know what I am doing. For an app, please don't bother me with details of OS versions, CPU architectures, Java versions, etc. — just take what I have working on my laptop and deliver it through the platform.
OS to app and everything in-between
When we say OS to app and everything in-between, it's interesting that "in-between" is quickly being dominated by container-based workloads, e.g., Docker. Although I’ve had some great conversations in the halls of VMware around the weight of hypervisors vs. alternatives like containers, I don’t believe the popularity of Docker is due to this reason alone.
Enterprises want to compose systems and only build what's required
I believe we're seeing the realization that enterprises want to compose systems and only build what's required to make them unique. Composable systems fit well with the Docker model, although the latter doesn’t yet do addressing, discovery, connecting, or scaling a composable system made of Docker images, plain OS images, and greenfield apps. While the dream of identical containers fitting onto ships and railways and trucks is great, we have reason to peek inside.
Know what's inside
When something gets to US customs, customs agents want to know what's inside. This is very similar to moving from dev/test to production. Production Operations wants to know that the kernel doesn't have that zero-day exploit, that the OpenSSL version has been patched for HeartBleed, that the running version of Java is correct, and that even flags to the garbage collector are blessed for production use.
The one thing you need is trust
As we develop more tools and technologies to accelerate the composable enterprise system, how do we gain enough trust in the system to deliver it from dev/test into production? Things like policy, compliance, governance, and security usually run counter to speed and agility. Yet to get into production, the one thing you need is trust. Trust in the system, and the platform, all comes from understanding and implementing at a deep, foundational layer. There, you'll find things that usually work against us: policy, compliance, governance, and security.
When Apcera was founded over two years ago, a key goal was to bring speed and agility to a diverse set of workloads, and the ability to transparently compose systems, without any code changes or dependencies. In addition, all this should be on a policy-driven core that drives compliance, trust, and safety. Applications want to be secure and compliant, but they don't know what that means, nor should they.
Speed and agility with policy
Enterprises need a system that transparently blends speed and agility with policy, compliance, and security into apps and workloads without modification. That's the future that enterprises want and that’s what we’ve built and delivered here at Apcera.
We'll show you next week… San Francisco on June 10 from 4-6 PM
We'd be happy to show you next week. If you’re in San Francisco on June 10 from 4-6 PM for the Cloud Foundry Summit or DockerCon, or for any other reason, attend our event by contacting firstname.lastname@example.org.Preview what we’ll publicly launch later this summer. We’re very excited to share with you what we’ve been working so hard on.