Platform-as-a-Service (PaaS), to me, basically means out-of-the-box hosting: I push a button, and my application is accessible. That means several things need to happen:

  • The infrastructure gets spun up and fully configured
  • My application gets deployed
  • The application also gets orchestrated; that is, all the individual application, database, etc. servers are brought together to work as one.

PaaS started out as a way to spare startups and SMBs the need to invest capital in physical servers, while still enabling them to host applications reliably. The whole point of a PaaS is to make things quicker and easier for developers by standardizing the deployment of infrastructure and code to virtualized environments.

Early PaaS environments, like Heroku, were public platforms that abstracted away the need for expertise but also took away hosting options, architecture options and/or other technology choices. Not a big deal if you’re a startup that hasn’t invested in a traditional “data center” type stack.

But many companies need their cloud automation platform to provide the flexibility to migrate existing tools, processes and applications to the cloud, support a wide range of programming languages, and so on. Many teams also want some visibility into what’s going on with their stack, and the option to easily tweak things.

Besides a hosted service, another way to create a “platform” for cloud automation is to start with an open source configuration management tool like Puppet or Chef. These are powerful, flexible and portable across environments, but they don’t give you much out-of-the-box except building blocks. You’ll also need other tools or components to create an on-demand “service” for users: something to spin up and orchestrate the infrastructure, for example.

For teams that are short on specific expertise, as well as money and time to hire someone and have them build out a configuration management platform, the DIY method is problematic. In our experience at Bitlancer, many teams are conflicted about which tool to choose, let alone ramping up to use it effectively.

The SMB PaaS space is still evolving rapidly, but right now it’s hard to find a solution that doesn’t force you to compromise on either flexibility or built-in automation. That’s why we created Bitlancer Strings, and why we refer to it Puppet-as-a-Service: it gives you “as-a-service” levels of turnkey ease with DIY-like levels of flexibility and agility.

Strings is built on Puppet and gives you everything Puppet offers, including an open approach and community-but with vast amounts of baked-in, value-add goodness as well. One hallmark of Strings is that you can host it in your own environment. Or Bitlancer can host everything for you, “as-a-service,” including monitoring and application level support.

Another hallmark of Strings is that you have the option to leverage not only the software but also our devoted, 24x7 customer support, as well as training and expertise. Either way you get lots of Puppet profiles and other code and documentation to help you get rolling.

If you’re managing Windows servers (we focus on Linux) or you have a religious passion about a specific configuration management tool other than Puppet, Bitlancer Strings probably isn’t for you. It’s also very possible that your environment is “too mature” to make using Strings worthwhile.

But otherwise, Strings’ Puppet-as-a-Service model might be just what you need to help you get more benefit from utility computing.

UPDATE: Bitlancer Strings is now open source. For more information, visit Strings Documentation on Github.