name: inverse-center layout: true class: inverse, center --- name: top layout: true class: inverse --- name: inverse-title layout: true class: inverse, title --- name: title slide background-image: url(images/docker-whale.jpg) # Moving to Microservices ## With Docker .footnote3[Nick Humrich] .footnote2[Canopy - DevOps Guru] .footnote[OpenWest - 7/15/2016] ??? We will talk about how Canopy used Docker to move us to microservices and the journey we took. - Dockerize all the things - Split up the repos - Pipelining - Independent deploys - Stabbed in the Backwards Compatibility - DevOps training began - Add new services - Not enough environments - Docker-compose to the rescue - Ok docker-compose is too much - Shadow-prod - Feature Toggles notes for myself on moving to microservices (aka not part of my submission) At first we tried to dockerize everything. This was intially just a container around the monolith. Then we had to split repositories into two, frontend, and backend, then create a container for each. Next, a deployment pipeline was created for each so that they could be deployed independently. Then we struggled with backwards compatibility and had to train everyone. Once things were working, we then added a new service in Java. We used docker-compose to allow everyone to run all the services in their development environment without needing to worry about the services they don't touch. As we added more and more services, this got out of hand, and there were too many services in the docker-compose files, and too many files to update if you wanted to change your service configuration. Docker didn't completely offer the "add it and forget about it" that we had hoped for. To fix this we created a "prod-like" environment, so that you could point your dev environment to a prod-like environment for the services you are not directly interacting with. Also, we had a single prod and stage environment, but that created a bottleneck so we had to create multiple integration environments. Lastly we moved away from feature branches to feature toggles using a feature toggle service. --- class: inverse, middle # What are Microservices? ??? * m11 is a subset of SOA * not the only form of soa * created by google/amazon * each context is its own full service * dont get carried away by the term "micro" * the word was coined in LARGE companies * Micro does not imply size of code base --- template: inverse-center name: disclaimer ## Disclaimer  # Mileage may vary* *This is just me talking about the journey Canopy had. Hopefully you will learn some things that will help you. ??? * We are not there yet * this is our journey --- layout: true class: inverse, middle --- name: canopy # Some info on Canopy - First hire: Sept. 2014 - 14 Software Engineers - 3 "squads" - 5 backend services - 4 frontend SPAs - Languages Used: - Java - JavaScript - PHP - Python --- name: me # What about me ??? * worked at amazon * what I do at canopy --- # How we started ??? one php app with server side rendered php "blades". CEO wrote it --- # Here comes Java ??? Started work on other services using Java --- # Docker for local dev ## (sorta) ??? PHP app was dockerized. This helped frontend not need to understand php. Docker was on top of vagrant. Devs still had to know vagrant. Java land didnt use docker because java and php didnt ever communicate, all the java devs understood gradle/java --- # Here is where I come in ??? - PHP docker in vagrant - Deploying code in prod with composer install - Yikes! - Only 3 environments: - stage - prod - local dev --- template: top # Why Microservices? -- ## * ## Fail Fast, Fail Often -- * ## Independent deployment -- * ## Autonomy -- * ## Orgazational Scalability --- template: top # Cons of Microservices -- * ## Performance -- * ## Duplication -- * ## Dependency Management --- background-image: url(images/netflix.png) --- # Our Story --- #First step, CI ??? Using drone You really cant do microservices without a CI (ok to be fair, there was a CI, kinda) - Always building/testing - CI builds artifacts - Can only deploy from the CI --- # Having an internal app really helps --- # Dockerize all the things --- # Docker in Prod ??? Using rancher --- background-image: url(images/rancher-screen1.png) --- background-image: url(images/rancher-screen2.png) --- # Now do the split --- # Move to independent deploys ??? At first this was technically challenging because we kept forgetting about backwards compatibility "Stabbed in the Backwards Compatibility" Whats really interesting is we found that once the tech for this existed, we were still releasing everything "all at once", cause that is what we were used too. - part of this couldnt be aleviated without feature toggles --- # Issues with Java Services --- #Training was inevetible ??? * need to be aligned on how "big" is a services * When do we break things up? * do we start --- # Docker-compose to the rescue ??? this was great until more and more services where being added Pulls took forever --- # Need more environments --- # More environments == pipelines ---  --- # Environment Frenzy ??? * Everyone wanted an environment for everything * I kept saying "use docker compose, use local" but no one wanted too * Docker compose was too painful --- background-image: url(images/docker-compose.png) --- # Shadow Prod ??? it never happened but its an idea we are still striving for --- # Front-end Microservices ??? Our front-end is completely static --- # Sofe --- # Sofe overrides --- background-image: url(images/sofe2.png) --- background-image: url(images/sofe1.png) --- template: section # github.com/CanopyTax/sofe --- # Single-Spa --- background-image: url(images/sspa.png) --- template: section #github.com/CanopyTax/single-spa --- # Feature Toggles --- # github.com/CanopyTax/toggle-meister --- # Back to the backend ??? Still in a monolith deploy state Hardest thing is prioritizing Need features for money, but not doing this is slowing down features --- # Service Discovery --- # Message Bus --- # Adding languages --- template: section # Thanks .pull-right[ \#openwest @nhumrich joind.in/talk/f3804 ]