<commit_before>---
title: How BOSH Works
---

BOSH is complex enough that it's a good idea to take your learning about it in stages.


## <a id="high"></a>A High-Level View ##

To understand BOSH, start by assuming that for each major area of functionality, BOSH has a component.
When you think about what BOSH does, you can piece together a portrait of BOSH component by component.

Consider the interactions between BOSH and an operator, a cloud, and a distributed service that has been deployed to the cloud using BOSH.

The operator sends commands to BOSH, which responds with output.
BOSH communicates with the cloud infrastructure.
BOSH communicates with the VMs on which the service is running.

Given these interactions, it makes sense that BOSH has:

* An endpoint that accepts uploads of data.
* A Command Line Interface (CLI) for communication with an operator.
* A Director component that receives commands from the CLI, through an API, and in turn communicates with other BOSH components to realize the intent of the operator.
* A Cloud Controller component that keeps track of the state of the VMs.
* A Blobstore where BOSH can store code that has been uploaded and needs to be deployed.
* A Health Manager that monitors actual VM state and compares it with desired VM state as described in manifests, then informs the Cloud Controller about any discrepancies.

Though not part of BOSH itself, every VM for the service that was deployed using BOSH has a BOSH Agent.
The Agent is a process that is always running when the VM is alive.
BOSH communicates with a VM by "talking to" the Agent.

Finally, BOSH communicates with the interface of the cloud infrastructure itself.
Each cloud provider has its own characteristic interface.

This is a good basic picture of BOSH.
Naturally, there is more to know about each of the elements discussed so far.
For example, the CLI is scriptable, so BOSH can receive automated commands.
Likewise, the Director is responsible for some system operations that are not directly initiated by the operator.

More importantly, BOSH has several components whose role is to enable the Director, Cloud Controller, Blobstore, and Health Manager function as a system.

## <a id="deeper"></a>Looking Deeper ##

* Router
* Messaging


<commit_msg>fix some prose per dev<commit_after>---
title: How BOSH Works
---

BOSH is complex enough that it's a good idea to take your learning about it in stages.


## <a id="high"></a>A High-Level View ##

To understand BOSH, start by assuming that for each major area of functionality, BOSH has a component.
When you think about what BOSH does, you can piece together a portrait of BOSH component by component.

Consider the interactions between BOSH and an operator, a cloud, and a distributed service that has been deployed to the cloud using BOSH.

The operator sends commands to BOSH, which responds with output.
BOSH communicates with the cloud infrastructure.
BOSH communicates with the VMs on which the service is running.

Given these interactions, it makes sense that BOSH has:

* A Command Line Interface (CLI) for communication with an operator.
* A Director component that receives commands from the CLI through an API, and in turn communicates with other BOSH components to realize the intent of the operator. The Director also keeps track of the state of the VMs.
* A Blobstore where BOSH can store code that has been uploaded and needs to be deployed.
* A Cloud Provider Interface (CPI) that BOSH uses to communicate with the cloud infrastructure.

Finally, every VM for the service that was deployed using BOSH has a BOSH Agent.
The Agent is a process that is always running when the VM is alive.
BOSH communicates with a VM by "talking to" the Agent.

This is a good basic picture of BOSH.
Naturally, there is more to know about each of the elements discussed so far.
For example, the CLI is scriptable, so BOSH can receive automated commands.
Likewise, the Director is responsible for some system operations that are not directly initiated by the operator.

## <a id="deeper"></a>Looking Deeper ##

BOSH has several components whose role is to enable the Director, Cloud Controller, Blobstore, and Health Manager function as a system.

* Router
* Messaging
* A Health Manager that monitors actual VM state and compares it with desired VM state as described in manifests, then informs the Cloud Controller about any discrepancies.



{'fraction_non_alphanumeric': 0.04066877541798464, 'fraction_numerical': 0.0, 'mean_word_length': 4.35956416464891, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '784015', 'n_tokens_mistral': 1133, 'n_tokens_neox': 1089, 'n_words': 707}