OpenStack Tokyo, Docker, and Moving from Monolith to Microservices

palace-nikhil

Me at the Imperial Palace

As you may know, I’ve recently returned from a trip to Tokyo, Japan.

skytree-nikhil

Tokyo Skytree

As I learned from my Japanese colleagues, October is a great time to visit Tokyo as the weather is very temperate and the peak season has just passed. My favorite tourist attraction was the Tokyo Skytree and seeing the breathtaking 360 views. Being a tourist was fun but, the main reason I went to Tokyo was to deliver a talk at OpenStack Summit Tokyo.

openstuck-summit-nikhil

OpenStack Summit, Tokyo

My session was titled “Managing Microservices at Scale With OpenStack + Docker”. And as you’d expect I spent a lot of time talking about Docker, Microservices and Software Delivery pipelines.

We’ve all heard about Microservices and Monolith applications. They each have their own pros and cons for development, testing and deployment.  The consensus forming, currently, in terms of best practices, is to start with a Monolith architecture, and work on your product and get some business traction and customers, before you decompose your monolith into Microservices.  (BTW – for an in-depth look into Microservices architecture and deployment patterns, check out our CTO’s, Anders Wallgren, excellent talk at the recent DOES15).

In my talk, I went into further detail about these theories, including a live demo (see recording below). In this post, I wanted to focus on a modeling of decomposition of a Monolith app into Microservices, using our free version of ElectricFlow.

To illustrate the decomposition, I created a demo application that queries a weather feed (based on a weather widget by davefp) and displays the temperatures in 16 cities around the world. For a UI, I created a Dashing dashboard that could be deployed as a monolith via one Docker container. Each widget in the dashboard was written as a dashing job that would run every 30 seconds and query the Yahoo weather API to display the results. I wrote a few Selenium tests that also ran in Docker to test the monolithic application.

Modeling the Pipeline, Application and Deployment process of Microservices in ElectricFlow:

The Monolith:

This is what the software delivery pipeline looks like in ElectricFlow:

ElectricFlow monolith pipeline model 1

ElectricFlow Pipeline model

This is what the application looked like:

ElectricFlow monolith application model 2

ElectricFlow app model

And this is how straight-forward, serial, deployment process looked like:

ElectricFlow monolith deployment process model 3

ElectricFlow deployment process model

Microservices decomposition:

Next, I wanted to show how this application would be decomposed, and decided to split each city into its own microservice. Granted, this is a simplistic decomposition scheme, only to illustrate the point. In a real-world scenario, you would likely re-architect the microservices based on the types of data feed (i.e. temperature, traffic alerts, geo-based recommendations), supported languages, etc.

In my example, each microservice would now have its own pipeline to go from source (git repository) to artifact repository (docker registry).

sample-pipeline-microservices-and-containers

Sample Pipeline: Microservices with Containers

To assemble all of these microservices, I created a loose concept of an “application manifest” in the form of JSON input. This is one way to pick up microservices and deploy them as an application. The JSON input is a parameter to the ElectricFlow pipeline.

Now, let’s compare how the decomposed monolith looks in ElectricFlow in Microservices form:

This is what the software delivery pipeline of the application looks like:

ElectricFlow microservices pipeline model 4

ElectricFlow Microservices Pipeline model

The application:

ElectricFlow microservices app model 5

ElectricFlow microservices app model

The deployment process:

ElectricFlow monolith deployment process model 6

ElectricFlow microservices deployment model

Notice that each Microservice (in our case, city) can be deployed in parallel, independent of the other services. There’s still a serial deployment in the first couple of steps in the process, as the application matures- you would have likely found a way to decompose those, too.

How does OpenStack fit in:

As you fragment your application, testing becomes even more critical to ensure there are no issues or failures with each Microservice. You will find that your requirements for testing environments grow considerably as you add more microservices. OpenStack and Docker lend themselves well to enable elastic usage of your infrastructure, during testing or deployment. You can easily add/remove instances to accommodate the needs of your app as you continue to decompose it, or as you add more team members, or as you add redundancy to meet HA needs.

Watch the recording of my talk:

If you’re interested to learn more, you can watch the recording of my talk, which also includes a cool product demo:

Nikhil Vaze

Nikhil Vaze is a Staff Software Engineer on the Electric Cloud engineering team. He is a full stack engineer and loves to hack on things. You can also find him on github and ask.electric-cloud.com. Nikhil holds a Bachelor of Science in Computer Engineering and Master of Science in Security Informatics from Johns Hopkins University.

Share this:

2 responses to “OpenStack Tokyo, Docker, and Moving from Monolith to Microservices”

  1. Jeff Winkelman says:

    Nikhil,

    Lots of good blogs on docker on ECs website.

    Are there any plans to deliver EF itself as a set of docker containers?

    Thanks,

    Jeff

Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe

Subscribe via RSS
Click here to subscribe to the Electric Cloud Blog via RSS

Subscribe to Blog via Email
Enter your email address to subscribe to this blog and receive notifications of new posts by email.