We’ve chatted about the CAPS orchestration bundle before here, but one that has been left out of that (only because BCAPS is not a word) is the BOSH platform which was developed as an open source project by the team at Cloud Foundry.
Built on four key tenets, Bosh looks to solve some very distinct problems that have been highlighted:
Each of these areas is a common challenge that is found in many configuration management solutions, especially when systems administrators are relying heavily on standalone scripts for management of their infrastructure. This is where Bosh looks to step in.
Not Just Another Orchestration Tool
With a goal of being well-suited for large distributed systems according to the documentation, BOSH looks to be acutely aware of every step of the process of configuration and release management. This is interesting because it touches on some of the areas that other traditional configuration management tools may fall slightly short out of the box.
Using the stemcell concept, BOSH allows the creation of a baseline system (VM, AMI, etc.) which contains the BOSH agent and some other basic utilities. This basic template will be used to model all changes in the application lifecycle management process. This means that the same build manifest for that particular platform can also be used with some slight modifications to deploy to other cloud platforms and hypervisors.
The reproducability comes with the manifest driven deployment. Consistency is available using the same manifest approach, and the agility is enabled because of the relative portability of your applications once deployed within BOSH.
Why Isn’t BOSH More Common?
This is a great question, and it is as much a result of history of the platform. BOSH was originally designed to fit with the Cloud Foundry platform as you can imagine. Extensions to make BOSH a true cross-platform system have come a long way since its inception, so there are many more eyes on BOSH today compared to in the past. As more organizations look towards embracing configuration management and true
Getting up and Running with BOSH
It’s really rather simple to try out BOSH. Bootstrapping BOSH can be done using their various documented methods depending on which environment that you are running within. For IaaS platforms, there is support for AWS, OpenStack, vSphere, and vCloud. There are additional methods to deploy into Google Compute Engine, Microsoft Azure and CloudStack as well using community supported Cloud Provider Interface examples.
The BOSH architecture is itself a distributed environment which ensures scalability and resiliency:
General Health Monitoring
Once your application environment is up and running with BOSH, you can also enable some service monitoring which uses heartbeats for VM and services. External monitoring and configuration tools are able to interact with BOSH monitoring plugins. For example, if a VM no longer responds to a heartbeat, it can trigger the Health Monitor to recreate the original VM using the resurrector plugin.
This brings the cycle of continuous configuration management and state awareness which is much of what drew folks to Puppet over some other products. At the same time, there can be interaction between different systems such as BOSH, Puppet, Chef, Ansible, Salt, and many more. Ultimately, these are all part of an overall need to attack systems configuration management as a whole.
This is just a taste of what BOSH has to offer, but the theme is something that you are seeing over and over again as we walk through these products and frameworks. We are moving up the stack, and as distributed systems are expected to rapidly expand and grow, being able to have an intimate awareness of the configuration while applying consistent process within each platform is key. Everything you are doing today will be done a hundred, or even a thousand times over in the future. The ability to scale just doesn’t match at a human level. Time to embrace configuration management 🙂