The Trend Towards Microservices and Containerization

January 7th, 2015 by

Let me start by giving my one line view of the reason for the uprising in awareness of microservices, containers, SDN and the ever-present SDDC (Software-Defined Data Center): This is about agility, not speed.

I have always been a proponent of SDN (Software-Defined Networking) and have also been acutely aware that SDN will be inherently slower to some very small degree because of additional overhead. This is not a bad thing because of the trade off to providing an agile architecture that allows for programmatic, intelligent workload management despite the nominal overhead due to packet alteration.

The amount of overhead is so minimal that it will not affect the consumer experience in any noticeable way. The advantages provided by the new, agile capability come with using APIs to control the architecture, version control to maintain consistency, and enhanced visibility into the topology, which many tools are able to provide.

Now that I’ve touched on that, let’s dive in a little into microservices and containerization to see the specifics of how they are providing agility to organizations to help also drive the DevOps culture.

A brief history of microservices

SOA (Service Oriented Architecture) has been around for quite a long time. The concept of creating isolated services, which are accessible via API to create loosely coupled systems, has long been recognized as a more flexible and adaptive architecture style. The rise of the use of the term microservices is an indication that this practice is becoming more widely utilized and accepted.

Modern software and SaaS (Software-as-a-Service) products are built on the tenets of the SOA and microservices methodology. Creating loosely coupled systems allows for better development and deployment practices. Using CI/CD (Continuous Integration/Continuous Deployment) alongside the microservices architecture gives us the best of both worlds.

The true advantage of microservices architecture is the scale-out capability it enables for us. Loosely coupled, API driven architecture creates a natural scale-out capability where we can cluster services together for stateless applications. Even stateful applications are able to leverage microservices architecture, so it is not limited to “new” application designs only.

Here we can see what a sample architecture looks like illustrating the different services offered to the applications as microservices within SAP:

microservice sap sample

We can see the logical separation of functions within the overall application.  This style provides the agility to manage each microservice as its own application environment which decouples services from each other.  The traditional, monolithic application structure usually requires much more rigorous testing and care during development and build stages.

Operationally, this also creates a more manageable infrastructure.  If a microservice were to fail or falter in any way, it may only affect a subset of the overall application.  This is a much more ideal situation for both the development and operations teams, not to mention the consumer of the application itself.

Microservice architecture is a culture shift

In the same way that DevOps and Infrastructure-as-Code is a shift in the culture of organizations developing their application infrastructure, microservice architecture is a change in the methodology as much as it is the actual code itself.

It is also entirely possible for us to continue to use legacy practices with brand new tools. This is an unfortunate result as many development and operations teams have adopted new products and tools without changing the way in which they are used. It is entirely possible to write legacy-style code using Go and to deploy Chef and Puppet without really leveraging the real advantages the products can provide.

Microservices and Containers as enabling technology

Container technology has also been around for some time with LXC (Linux Containers), but we are obviously seeing much more attention being brought to it with the rise in visibility of Docker, and the burgeoning Rocket from CoreOS.

Microservices architecture has also been in the industry for decades, but the rise in popularity is due to the recent popularity and visibility. Organizations like Netflix, LinkedIn, eBay and others are helping to bring their software development practices to the mainstream.

The value of microservices and containers is being realized as the velocity of development rises for organizations. Rapid development is enabled by more agile infrastructure. Rapid growth in business is enabled by all of these technologies combining together.

State(less) of the Union

This may not be the most widely adopted practice yet, but the microservices architecture and containerization of applications is becoming a decently sized segment of modern application development being used by organizations.

There will continue to be legacy development in place for quite some time as the application infrastructure is already in place and requires continued care and feeding. What we are seeing happen in many cases is the creation of abstractions to legacy systems to allow for the hybrid development going forward.

The shift is definitely underway. The only question is the rate of acceptance, and the rate of change.

2 responses to “The Trend Towards Microservices and Containerization

  1. How distributed can Riak be? A lot of ERP Systems are multi-site. Set up on a sginle fat server for medium big data’. When many of the users are in Asia, the Citrix box is set up in a Hong Kong office. US users access the same box (and latency is not that bad). But this limits the number of users on typical affordable client server ERP to about 300 concurrent users on sginle SQL server db (more due to the locking scheme employed by the ERP client). Running the same ERP application, another larger company ends up with about 10 servers (all on premise) supporting about 2100 users (again 300 seats limits any one ERP administration instance). Locations use a common item master. NY, FL, OR, Ireland, Netherlands, Indonesia, Vietnam, China (x2), Hong Kong. Synchronized hourly, daily or sometimes weekly depending how the ETL jobs run ok (about 25 percent of jobs fail). What would be much cleaner is if the database could automate selective synchronization of about 6 tables on each instance out of about 80 tables. Real-time sync is not really required because users time zones are following the sun and cross the date line. Reliability, predictability and the ability to automate is turning far more crucial because inventory demand is converting to direct demand via the web (not a sales forecast). Generally factories in Asia supply the locations in the EU/US.

    1. These are great examples. There are definitely still many applications that will hold onto what some call the “legacy” approach, but that is because they are architected to do so. In the case you’ve highlighted, the application leverages table synchronization, and other NoSQL alternatives use sharding. Those platforms don’t always lend themselves to the microservices approach at the data layer. That is more effective further up the stack at the application layers.

Leave a Reply

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