Various philosophical traditions talk about harmonizing the Five Elements: air, earth, fire, water and space. Leveraging the cloud involves balancing three elements: abstraction, insight and control.
Broadly speaking, the cloud itself is an abstraction mechanism, which virtualizes computing resources and services on-demand. The advantage of abstraction is that it reduces or eliminates the need to concern yourself with those resources directly.
The disadvantage? If cost, reliability and/or performance become issues, you may lack visibility into what’s actually happening under the hood, and/or control over changing it.
What happens if you need to answer questions like: Where does my data reside? Has the data we just lost been deleted from all existing backups? Why has my application’s performance just nosedived? Can I run my application on Windows instead of Linux?
In a public cloud environment like AWS, you might not have visibility into all the information you need to answer these kinds of questions-let alone the control to customize things to your liking. Commodity hardware and vanilla provisioning can sometimes hurt more than it helps. If you run into a problem and you can’t work around it, you could be dead in the water.
Lack of visibility and control over shared resources is overall perhaps the #1 stumbling block on the path to cloud computing. Especially in DevOps cultures where diagnosis and troubleshooting are happening all the time on multiple levels, the limited visibility and control inherent in highly abstracted environments could be more than your team can live with.
But there are plenty of managers out there, including some we’ve worked with at Bitlancer, who embrace maximum abstraction (i.e., “all AWS all the time”) and are fine with the resulting lack of insight and control. For teams like these, simplicity and a clear technology decision path have priority over the ability to tweak cloud infrastructure and code deployments.
At the opposite end of the spectrum are those teams that want maximum flexibility. They choose commodity hardware and shun provider-specific services. Being completely provider-agnostic gives them full control, at the cost of more intensive focus and management.
In an ideal world, teams would have maximum abstraction along with maximum insight and as much control as possible. That’s what we were aiming for when we designed Bitlancer Strings-a “Puppet-as-a-Service” offering that provides 100% abstraction with 100% insight and about 50% control. Strings is simple to use, simple to tweak and very transparent.
Strings supports numerous clouds on commodity hardware and abstracts away a lot of underlying services without locking you into provider-specific technology. Say you’re using Strings to setup your MySQL servers on AWS. Because Strings isn’t provider-specific, you can move to a different provider or a private cloud with almost no changes. If you were using AWS-specific services instead, you’d have to recreate that automation from scratch in the new environment.
UPDATE: Bitlancer Strings is now open source. For more information, visit Strings Documentation on Github.