How a Decomposed Monolith Looks in ElectricFlow
OpenStack Tokyo had a bunch of great sessions about Docker, microservices, and how to decompose monoliths.
Join the DZone community and get the full member experience.Join For Free
me at the imperial palace
as you may know, i’ve recently returned from a trip to tokyo, japan.
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 o penstack summit tokyo.
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:
this is what the software delivery pipeline looks like in electricflow:
electricflow pipeline model
this is what the application looked like:
electricflow app model
and this is how straight-forward, serial, deployment process looked like:
electricflow deployment process model
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 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
electricflow microservices app model
the deployment process:
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:
Published at DZone with permission of Nikhil Vaze. See the original article here.
Opinions expressed by DZone contributors are their own.