<commit_before># Libswarm

*libswarm* is a toolkit for composing network services.

At its core, it defines a standard way for the components of a distributed system to communicate with each other. This lets you:

1. Use them as building blocks to compose complex architectures
2. Avoid vendor lock-in by swapping any component out with another

An extensive library of adapters is included, and you can also write your own using a simple API.

Here are some examples of what you can do with libswarm:

* Aggregate all your Docker containers across multiple hosts and infrastructure providers, as if they were running on a single host.

* Bridge your in-house DNS-based service discovery with that new shiny Consul deployment, without getting locked into either.

* Swap in a new clustering and service discovery system, without changing any application code.

* Collect logs across an in-house Mesos cluster, a Cloudfoundry deployment and individual servers staggered in 3 different datacenters, forward them to your legacy syslog deployment, then perform custom analytics on them.

* Simulate your entire service topology in a single process, then scale it out simply by re-arranging adapters.

* Organize your application as loosely coupled services from day 1, without over-engineering.

## Adapters

Libswarm supports the following adapters:

### Debug adapter

The debug backend simply catches all messages and prints them on the terminal for inspection.


### Docker server adapter
<commit_msg>Rename "adapter" and "component" to "service"<commit_after># Libswarm

*libswarm* is a toolkit for composing network services.

At its core, it defines a standard way for services in a distributed system to communicate with each other. This lets you:

1. Use them as building blocks to compose complex architectures
2. Avoid vendor lock-in by swapping any service out with another

An extensive library of services is included, and you can also write your own using a simple API.

Here are some examples of what you can do with libswarm:

* Aggregate all your Docker containers across multiple hosts and infrastructure providers, as if they were running on a single host.

* Bridge your in-house DNS-based service discovery with that new shiny Consul deployment, without getting locked into either.

* Swap in a new clustering and service discovery system, without changing any application code.

* Collect logs across an in-house Mesos cluster, a Cloudfoundry deployment and individual servers staggered in 3 different datacenters, forward them to your legacy syslog deployment, then perform custom analytics on them.

* Simulate your entire service topology in a single process, then scale it out simply by re-arranging adapters.

* Organize your application as loosely coupled services from day 1, without over-engineering.

## Built-in services

Libswarm supports the following adapters:

### Debug adapter

The debug backend simply catches all messages and prints them on the terminal for inspection.


### Docker server adapter

{'fraction_non_alphanumeric': 0.035914332784184516, 'fraction_numerical': 0.0026359143327841844, 'mean_word_length': 4.674766355140187, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, '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': '7669900', 'n_tokens_mistral': 727, 'n_tokens_neox': 686, 'n_words': 445}