This week’s Gartner panel on PaaS (video here) marked an important milestone in market education on fundamentally different approaches to building container based cloud application platforms for enterprise customers. I’m thankful to Eric Knipp (@erichknipp) from Gartner for hosting it, and for the great spirited participation by everyone involved.
As my colleague Andrew Shafer, one of the founders of the Devops movement, remarked in a blog this week:
“Furthermore, all platforms are not equivalent. Platforms make different assumptions and optimizations to the extent that trying to put them all into the same category without regard to the capabilities creates more confusion. If you aren’t able and willing to evaluate the differences, what are you using to decide?”
Since Cloud Foundry’s creation in 2011, it has held two key fundamental design principles constant:
- The platform is responsible for scheduling its own application processes across an arbitrarily large system using Linux containers—of which it owns the full lifecycle controls as well as supporting functions such as networking, logging, etc.
- The platform is responsible for the application’s availability, and will constantly work to maintain application availability using four layers of HA.
If an application process node fails, Cloud Foundry fundamentally does not believe in manual system administration remediation. Our customers count on us to radically change the economics of not only deploying applications but also operating them in production. Pivotal has also created supporting technologies such as the Spring session store so Java applications can seamlessly store session state in HA database systems, and we provide an HA MySQL service as part of Cloud Foundry.
As explored on the Gartner panel Tuesday Red Hat’s approach to PaaS does not include automated application process HA. They further posed to Eric, the moderator of the panel, this week on Twitter that application node availability is the responsibility of the IaaS layer, and system administration scripting toolchains such as Puppet.
For our customers, like Philips, they want to use Cloud Foundry to power a whole new generation of iOT style medical devices with connected APIs. During initial architectural explorations they loved our focus on providing as much application HA as possible out of the box with zero manual intervention. These PaaS capabilities fundamentally changed the economics of their new API driven devices. Another Pivotal customer Monsanto has observed an initial 50%+ reduction in their operations costs for applications due to our built in health management features.
When pressed on the viability of the manual recovery approaches to PaaS, Red Hat deflected focus onto container scaling and container security, so let’s quickly close on those topics where we agree on the importance but have seen demonstrably better results with Cloud Foundry.
On Container Security and Isolation:
Our advantages are clearly evident in this demonstration (video here). Using Cloud Foundry there is clear multi-tenant isolation with no visibility or access into neighboring processes on the same host. With Red Hat’s approach, neighboring processes and connections are all visible. This was tested this week on their production public multi-tenant service.
On Container Scaling and Health Management:
This video demonstrates the incredible speed with which Cloud Foundry can scale health managed application processes in real time. Scaling a java application from 1 to 100 instances takes just 1:15! Adding another 300 nodes takes only another 1:50.
True to our philosophy though we don’t stop there, we further demonstrate not only the scaling of the application, but programmatically kill 40 instances of the application at once. Instead of HTTP errors, the dead instances are immediately pruned from the routing tables, requests are retried by our HA routing tier, and all 40 instances are restored by our health manager in around 1 minute. Imagine how long it would take to manually restore forty instances of this application.
In our tests with the hosted commercial platform yesterday, not only does Red Hat’s killed app fail to recover a single instance application without intervention, but scaling to 4 additional instances also fails as did 3 consecutive attempts adding 9 or more instances with different errors each time, and scaling up to 2 extra instances took over 1min 30sec. The absence of both automated health management or reliable, fast scaling in these results is in stark contrast to the nearly real time performance of Cloud Foundry on both dimensions. I personally challenge Red Hat to match Cloud Foundry’s performance on container scaling and health management and to report their times with demo video as well.
Overall it was a great week for PaaS, we are seeing incredible momentum and transformative enterprise adoption of Cloud Foundry. The great work by folks at Gartner is helping us advance the conversation around our key philosophical and design principles for building next generation container based platforms.
See how some top industry cloud experts reacted to the stark differences, and feature gaps we revealed this week.
Mark Imbriaco , former head of operations for PaaS pioneer Heroku, and current head of Operations at Digital Ocean:
https://twitter.com/markimbriaco/status/500325695986618369
Simon Crosby, founder of Xen, virtualization security expert:
https://twitter.com/simoncrosby/status/500309145988636673
Lydia Leong, VP of cloud, Gartner Inc.:
https://twitter.com/cloudpundit/status/500310672191012864
Tobias Kunze, former CTO, Red Hat Openshift:
https://twitter.com/tkunze/status/500335951856431104
Colin Humphries, CEO and Founder Cloud Credo:
http://www.infinitelooper.com/?v=ZLs7ocw8wFI#/964;1040
About the Author
Follow on Twitter
