I ran Docker yesterday, and I thought to myself, "Docker is nice to run a bunch o server junk."



## What, junk?

Of course, "junk" doesn't sound thrilling or particularly nice, and I guess that's how I felt the other day.  That's what makes Docker nice.  You can throw something into a black box and now have to worry too much about it.

For instance, I might throw in a database, a messaging server, and a REST API.

## Lots of junks

And once you have more than one junk, a tool called `docker-compose` is nice.  You get it when you install Docker Desktop.

It's nice because you can define several processes to run at once in a `docker-compose.yml` file.  It might contain the things mentioned above:

```
version: '2'
services:
  rabbit:
    image: rabbitmq:3.7.6-management
    hostname: rabbit
    ports:
      - "15672:15672"
      - "5672:5672"
  postgres:
    image: kiasaki/alpine-postgres:9.5
    volumes:
      - my-postgres:/var/lib/postgresql/data
    ports:
      - '5432:5432'
  my-api
    image: some-custom-image-host:latest
    ports:
      - "3000:3000"
    environment:
      VAR_NAME: valueHere
volumes:
  my-postgres:
```

You can see the many and sundry options: exposing ports, exposing filesystem volumes, and setting environment variables.

## Starting up the junk

If you never have to look inside `docker-compose.yml`, it's even better.  All you have to do is start the processes.  This is done with by going to the file path where `docker-compose.yml` is stored and typing:

```
docker-compose up -d
```

This will start it all. `-d` will fork the process as a daemon.

## Accessing the junk

Then what's available?  In the example, there will be a Rabbit messaging admin portal mapped to localhost:

```
open http://localhost:15672
```

And a postgres instance to access:

```
psql -U postgres -h localhost
```

And another REST API to access

```
open http://localhost:3000
```

## Not mixing junk

Note that once you start all these processes, resources like http ports on localhost or tcp ports for postgres are going to be shared.  Make sure you stop any local junk instances so that there are no conflicts.  

You wouldn't run local junk anyway, right?

## Monitor the junk

Once the junk is running, you might want to see what it's doing:

```
docker-compose logs -f
```

This will show a combined log of all processes. `-f` will show new logs continuously (`-f` = "follow").

If you're not sure things are running at all, you can run:

```
docker ps
```

## Throw junk away

Sometimes junk takes up a fair bit of space.  We could all use a bit of downsizing and decluttering.  Say "Thank you, junk" and let it go.  Type:


```
docker-compose down
```

A bit of cleanup, and you're back to a pristine state.  Docker's nice like that.  It seems junk contained.

Any other ways you like to run server junk?

Docker is nice to run a bunch o server junk

Docker Runs Server Junk

Devops is a mindset and a practice that asks a lot.  Engineers must learn a two worlds of ops and dev.  This encourages some good things, and needs to be tempered in order to be more realistict.



## Ownership is Awesome

Devops encourages ownership of the code, the product, and the environment in production all the time.  This ownership engenders a feeling of responsibility, craftsmanship of better quality code, and removes the tendency to make your problems someone else's.  This ownership is wonderful.

Where ownership starts to feel overly intense is when it feels like you're out of your element, and you're all on your own -- it's your responsibility after all.

## Modern Dev & Ops Fields

Our systems are becoming more and more complex.

In dev terms, gone are the days of starting a repo and writing a single app. Now your app is spread across multiple codebases.  You might span languages and paradigms.  You have to coordinate the implementation of these systems with a wide array of contributors and stakeholders.  You have a wide array of tests to exercise and verify your code. You are focused on long-term viability of your design in its clarity and refactorability.  In order to remain relevant in the marketplace, your product is always changing, as is your implementation to support it.  There is a lot here.

In ops terms, gone are the days of your app sitting behind a simple webserver.  Now a request will hit a load balancer and pinball across the network. A labyrinth of microservices await the request.  There are many deployables, performing independent tasks, yet intertwined in larger workflows.  They have central logging and monitoring requirements.  They are individually tuned for scale.  They are controlled through arcane infrastructure configuration.  There is a lot here.

## Doing it All

To do both dev and ops requires a wide breadth of knowledge. Having considered the state of both dev & ops on the web today, they seem to require a depth of expertise.  Now devops seems to be asking us to combine the fields into one.  To find such an engineer that embodies the breadth and depth of both fields is rare.  To train such an engineer will take time, experience, proper training, be expensive, and put a lot on her shoulders.

## Making it More Realistic

As a software creator, I like to say that anything is possible.  It usually comes down to how long you want to wait and pay.  Perhaps you're frustrated or intimidated by a devops expectation that you know and do all of dev and ops. Perhaps you're feeling that it *is* possible but that the price is quite high. To mitigate this cost and to encourage realistic devops mindsets and practices, perhaps we can do a few things to help.

We can give development time and space to write quality code.  So much depends on us creating stable systems so that dev time is not eaten in ongoing production runtime maintenance costs.  The only way to go fast is to go well.

We can welcome specialists into our teams.  These fields are deep.  We shouldn't be afraid to lean on the deeper understanding of a specialist, whether she be in dev or ops.  Likewise, interests are often broad, but they are sometimes focused.  We can make it ok to not be interested in one side or the other. This isn't a lack of interest in the principle of responsibility -- just in going deep on expertise.  We can form teams around varied strengths and not require people to cultivate interest and expertise in absolutely everything.  We can ask for help.

We can provide platform level help.  There are complex tasks that can be wrapped up and made more consumer ready.  Procurement, build, deployment, logging, and monitoring setup all have great potential to be simplified for users.

Surely these are just a few things that could help.  Let's encourage ownership through devops.  Let's make devops more workable for everyone.

Have you felt the pressure to know and do all in a devops world?  What are some things that you've done to keep your head above water in a sea of tools and practices in these two deep fields?  What are some steps that you have made or see we could make to make the good parts of devops shine without being overwhelming?

The devops mindset asks a lot.  They must learn a whole new world of ops, in addition to development.