Why BOSH?

First, let's answer the question:

What is a Running Software System?

Your bespoke or user-facing application is either a compiled application (Golang) or source code that runs within an interpreter (Ruby or Python) or is compiled and requires an interpreter (JVM languages).

Your bespoke application will be composed of bespoke code plus third party software libraries (RubyGems for Ruby, NPM for Node, Wheels for Python, etc).

Your application will need to be configured (combination of local configuration files, environment variables, service discovery system) to run and connect to any dependent systems.

Your application will require local dependencies to be already installed - its interpreter, linked libraries, executable applications, etc.

Your application and its dependencies all require an operating system. And formatted disks. And networking to be configured.

All this runs in a virtual server/virtual machines (VMs) either in someone else's data centre called "the cloud" (AWS, GCP, Microsoft Azure) or someone else's data center called, "on premise" (but it's really normally not in your building, is it?) running virtualisation software (vSphere, OpenStack).

Your applications and databases running on virtual machines will require disks: local or ephemeral disks that might not survive VM downtime or replacement; and persistent networked disks that are independent of each VM and will be available again if you need (or are forced) to replace your VMs.

All of this runs upon physical machines connected to actual storage systems and interconnected by real-world networking.

Servers need to be powered, so you'll need stable affordable electricity. Servers get hot, so you'll need cooling. Servers can be stolen or physically hacked, so you'll need security guards with appropriate lapel badges.

It's incredible that it all works. Click on https://google.com to check that it all works.

Note: The Ultimate Guide to BOSH will include unsolicited sarcasm and humour. With luck, you'll enjoy both the Ultimate Guide to BOSH and the humour.

Choose Your Own Deployment Level

You might define "deploying my system" at a different level to other people:

• using an application platform, such as Cloud Foundry or Heroku
• using a container orchestration system provided by someone else, such as Kubernetes, Docker, Amazon ECS
• using virtual machines provided by someone else, such as AWS, GCP, vSphere
• using bare metal machines provided by someone else
• racking bare metal servers or putting Raspberry Pis into the field

From the perspective of your organization and their goals of efficiently using your time and energy, hopefully you can start as high up this stack as possible. For example, there is simply nothing faster, more time efficient, and UI consistent as cf push-ing an application to any Cloud Foundry. Every system you deploy should have to first justify why it cannot be deployed to Cloud Foundry, Heroku, or Google App Engine.

If you do need to "go down the stack" and take responsibility for more, then you will need more help. Either your organization will need to expect less from you and your team, or you'll need more tooling, automation, and education.

Assumptions

The Ultimate Guide to BOSH assumes you need the latter: you need tooling, automation, and education.

It also assumes that you have direct access to your virtualisation/cloud infrastructure - you have suitable AWS credentials, a Google Compute account, or vSphere admin access.

The Ultimate Guide to BOSH assumes you are prepared to learn a new tool, its features, and its quirks.

Continuous Integration and Continuous Delivery

BOSH slots in very nicely into any continuous deployment systems you might already be using. The bosh command-line tool is a perfect abstraction for, "Please make this happen," that will make it pleasurable to move BOSH deployments into your CI/CD systems.