Creating a Custom PaaS with Mesos & Marathon

Creating a Custom PaaS with
Mesos & Marathon

Tehmasp Chaudhri | @tehmaspc

the goals:

to build an internal container centric infrastructure to allow for the rapid delivery of business applications

to support our business requirements around application deployments

to potentially support many applications and teams

to increase happiness for and amongst developers and operations teams

why containers?:
the good, the bad

```
speeding up development
```

speeding up deployment (and consistency)

creating a clean deliverable by dev to ops

good:

bad (challenges):

```
management of containers?
```

application linking & discoverability?

```
enterprise concerns?
```
...

tackling the bad:

after understanding our reqs and researching the best tools available, we decided upon Mesosphere's Marathon on top of Apache Mesos for this new internal infrastructure.

these tools would allow us to build a custom PaaS solution supporting containers in a manageable way for our business needs.

mesos:
the what, the why

what:

a system for scheduling and distributing work across a cluster of nodes abstracted into a large resource pool

why:

well supported; top level Apache project

raw management and support for Docker containers

attractive means of managing many app services by an operations team

```
multiple frameworks (e.g. Marathon) 
```

mesos:
architecture

mesos:
GUI

marathon:
the what, the why

what:

a framework for Apache Mesos that manages the running of applications (PaaS-in-a-box)

why:

excellent feature set for our application services needs:

e.g. app constraints, scaling, events, discovery and load balancing

a REST API to support creating our own PaaS rules on top of

marathon:
architecture

marathon:
GUI

utopia:
the what, the why

what:

our internal CLI tool interfacing with our Marathon deployment which every developer uses in order to develop, deploy, and maintain their applications with

enforces our internal development and deployment requirements

greatly increases developer productivity and ease of deployments

forces an operations team to think like systems developers

why:

utopia:
architecture

utopia:
architecture cont'd

```
application web routing via Bamboo
```
```
Zookeeper for configuration persistence
```

application (container) logging captured via Fluentd into ElasticSearch cluster

application monitoring via New Relic / Docker integration

server configuration management via SaltStack

going forward:

Mesosphere DCOS (forget everything I said?)

Docker 1.5 - current, brings useful infrastructure features

questions?