A few weeks ago, we had a potential customer explain to Eric our sales guy why he didn’t think he needed our software. I ended up chiming in to validate his logic: his company had evolved past the need for our Bitlancer Strings cloud automation software.

There are different “stages” within the cloud and DevOps mindset, and this lead’s company had evolved to the “fully cloud aware” and “full stack DevOps” stage. They manage everything, from the virtual infrastructure to the product code living on top of it, as a unit-with no distinction between code and infrastructure.

At this level of DevOps maturity, a new “deploy” of an application can include new application code and new infrastructure code, such as a new Redis module to configure infrastructure that the new code would then run on top of. Deploying an application could involve deploying entirely new infrastructure at the same time to live underneath the application, rather than reusing existing infrastructure.

Most companies still manage infrastructure and code separately, even if they can “program” their infrastructure much like they can “program” their code base. For example, at most of the startups Bitlancer consults for, and at most of the businesses that are target customers for our software and services, engineers still “spin up” infrastructure in the Amazon Cloud and then deploy to that virtual box as a separate operation. And they’ll most likely redeploy code to that same infrastructure multiple times before tearing it down. In this scenario, the code and infrastructure are managed completely separately.

I also recently had a series of conversations with one of our consulting clients on how you can’t quite have a unified staging and production environment for both infrastructure code and production code if infrastructure code is always launched before the product code-which, again, is the case for most companies. It’s like building a car: new engines are conventionally built before the rest of the car, and the engine needs to be tested separately before being put into the car, and then the complete car must be tested before being handed off to a dealer.

If the engine was built at the same time as the rest of the car, you could test the final product as a unit. But when the engine is built separately (and before) the car, you need a way to test the engine alone, because you don’t want the engine to change after it’s in the car, as this would impact testing the car…

The goal of DevOps is to treat your virtual infrastructure like you would any other software product: writing code, testing, deploying. Does that mean you manage infrastructure and code configurations together? Not necessarily, as our customer pointed out. Configuring separate environments isn’t just about separating code from infrastructure-it’s also about attributes and conditionals. Like, you need different SSH keys in staging versus production, so you can give some people access to customer data and others not. Or, your staging servers might have more debugging tools installed on them then your production servers.

Bitlancer Strings is basically meant to get folks successfully to the “middle ground” of DevOps. This is a place where manual management of cloud servers and services is kept to a minimum, and configuration management is radically simplified and strongly automated. Bitlancer’s consulting services can take you “beyond Strings” to the realm of “full stack DevOps” where the latest ideas and innovations roam free.

Going back to cars, you might feel OK trying to sell a Honda Civic to somebody who rides a bike 20 miles each way to work. But you wouldn’t try to sell a conventional Civic to a Civic Hybrid owner who’s getting 50+ mpg already. If your organization’s peddling harder than it needs to, or is looking to go further on a gallon of developer time, get in touch and let’s talk.

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