Chef, the company behind the popular DevOps tool, has launched a new open source project called Habitat intended to improve application automation.
Habitat centres application configuration, management and behaviour around the application itself, not the infrastructure on which the app runs.
This ought to enable Habitat to be deployed and run on various infrastructure environments, such as bare metal, virtual machines, containers and platform-as-a-service.
"Habitat exists to solve the problem of how we build, deploy and manage applications," wrote Chef chief technology officer Adam Jacob in a blog post.
"[Software is] at the centre of how we build and run our companies, and how we interact with our customers. This shift forces us all to become fast, efficient, software-driven organisations or lose out to a competitor who is.
"This challenge is not simply technical. It is organisational and it is cultural. We have to change the way we work together, hand-in-hand with changing the systems that enable us all."
The problem, according to Jacob, is that too many applications running today are too narrowly focused, leaving organisations constrained by the application and data silos built up over the years and decades.
"The deep silo-ing of responsibility present in most enterprises drives us to design software specifically for one silo or another. We build security software, or we build application deployment software, or we build configuration management software," he said.
"If we endeavour to escape this trap by designing solutions that cut across the silos, we fall prey to another issue: we're forced to integrate into every silo's existing software tool chain.
"The result tends to be systems that are deeply complex and very difficult to understand and operate or, worse, that are only as good as their worst point of integration.
"It is difficult to escape the complexity of the matrix between different eras of technology and deep silo-ing."
Jacob suggested that the most successful internet companies, like Amazon and Google, built the applications they run from the ground up partly in a bid to avoid this problem.
"Habitat started by asking this question: if our goal is to quickly and safely build, deploy and manage applications, what would happen if we took the application's perspective on the problem?" he said.
"Rather than starting from the enterprise point of view, or from the platform-centric view of the 'big web', what if we simply focused on what it means to be easy to build, easy to manage and easy to deploy?
"We call the answer we found application automation. Our great discovery was simply that the automation must travel with the application, rather than be provided by the platform.
"Everything the application needs, from build dependencies, run-time dependencies, configuration, dynamic topologies, deployment strategies, secrets management, security auditing and so on, belongs with the application because we're doing it for the application.
"Runtime and infrastructure layers exist to support the application, but the efficient building, deployment and management of the application are decoupled from those layers.
"The result is that we can take an application, wrap it in a layer of application automation, and the resulting package can be deployed on the infrastructure or runtime that suits it best.
"If your application has hard requirements on physical infrastructure (SAN settings, network topologies, GPUs etc), you can deploy it there, and manage it in the same way you manage the software that deploys on top of a PaaS or in a container."
BT wants to make the public switched telephone network history within eight years
Personal data being purloined by third parties via Facebook Login API
MacOS and iOS are better off apart, says CEO Tim Cook
Or they'll no longer be entitled to updates and bug patches