The platform-as-a-service winner is ... Puppet?

How did a devops framework come to rule PaaS?

With Cloud Foundry, OpenShift, and various cloud-washed legacy virtualization stuff like vCloud, it's time to take stock of who's winning the private PaaS (platform as a service) race. Enterprises continue to resist putting their code in the public cloud -- sorry,Amazon, App Engine, Azure, CloudBees, and Heroku -- leaving private cloud PaaS as the modern, practical alternative to the good old application server.

The vCloud stuff is certainly being used, but not by itself (and advertises itself as IaaS). OpenShift and CloudFoundry are well hyped -- but what are most people doing? In the end, one product is used more than any other in implementing an on-premise PaaS: Puppet.

"Wha ... ?" you ask. "Isn't a Puppet a devops tool, not a PaaS?" Yup. Here's why Puppet is being misused.

Remember how for the last couple of decades every company has thought it managed its website or internal documents in such a special way that it needed to build its own content management system? Well, now each company is doing something so special, it needs to manage its infrastructure and deploy its apps "just so" -- and it needs its own custom PaaS. Forget about simply customizing an open source PaaS like OpenShift or Cloud Foundry. No, use Puppet and create your own from scratch.

Some of this unnecessary activity stems from the weird perversion that is the modern open source business model among big vendors. It's open source, but if you take advantage of it being open source, then it's unsupported. And if you have unsupported instances, then you're violating your support contract. I blame some of this on my buddy Sacha Labourey, the founder and CEO of CloudBees, because his company is staying out of the on-premise game and causing smart people who want a full-cycle PaaS like his (which integrates nicely with Git and Jenkins) to either jump to his public cloud or roll their own.

Not that there aren't other viable on-premises PaaS offerings -- you just have to use them. The first step on the road to adoption is to take a quote from "Fight Club" to heart: "You are not special. You are not a beautiful or unique snowflake." Likewise, whatever you're doing with your IT infrastructure, someone else is probably doing the exact same thing. If what you're doing is so damn unique, then you're probably adding needless layers of complexity and you should stop.

To convince yourself or your boss or your subordinates to adopt an on-premises PaaS, identify which applications you're likely to deploy. What services do those applications need? Likely, database storage, networking, some application server-type thing, and maybe a place to put logs. Any on-premises PaaS can do those things.

Maybe you need specific security features, some form of encryption? Most PaaS offerings support something here, but even if they don't, you can most likely plug that in, layer it on top, or as a worst-case scenario, contribute that feature back to the open source project.

"But then we'll be unsupported!" you cry. Not as unsupported as if you had rolled your own -- that's like building your own car because the one you can afford has only a 90-day warranty. News flash: The one you're building has a zero-day warranty.

Sure, Puppet will be supported -- but all the things you did with it, not so much. To be clear, there is nothing wrong with Puppet, just like there is nothing wrong with your hammer, until you try and clean the ice off your windshield with it. Clearly, most people who use Puppet aren't creating their own, custom private PaaS, but I've been seeing more homegrown PaaS than anything else thus far.

You still think that your network and your computers and the way you deploy apps is sooooo different from the way others do it? Sorry. You are not special.

This story, "The platform-as-a-service winner is ... Puppet?" was originally published by InfoWorld.

Join the discussion
Be the first to comment on this article. Our Commenting Policies