Microservices via Containers
According to Wikipedia , “The term “Micro-Web-Services” was first introduced during a presentation at CloudComputing Expo in 2005 by Dr. Peter Rodgers.” The article goes on to say that “Juval Lowry also had similar precursor type of thinking about classes being granular services, as the next evolution of Microsoft architecture. Services are composed using Unix-like pipelines (the Web meets Unix = true loose-coupling).”
The microservices architectural style is also described as a pattern. 
Martin Fowler , adds that “While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”
His observation is readily apparent in the various forums discussing the topic. What constitutes the architectural style known by convention as microservices? The most basic of survey into the topic will show the challenges people have in answering that question.
Tom Huston from Smartbear.com  writes “To begin to understand microservices architecture, it helps to consider its opposite: the monolithic architectural style.”
Vijay Alagarasan via InfoQ.com  writes “The goal of microservices is to solve the three most common problems i.e. improve customer experience, highly agile to the new requirements and drive down cost by delivering the business functions as fine grained services. This is not a silver bullet and requires a disciplined platform, where delivering the services in an agile fashion with high quality is possible.”
Chris Richardson at NGiNX  writes “Like every other technology, the Microservice architecture has drawbacks. One drawback is the name itself. The term microservice places excessive emphasis on service size.”
Vivek Juneja via The NewStack.com  offers “Microservices: Four Essential Checklists when Getting Started”
The papers referenced above are just a small sample of available material. But most compare microservices to SOA in one sense or another. It seems to me, however, that these styles are compatible – SOA can be accomplished via microservices.
Of course, these are broad reaching lines of thinking that has led to multiple potential definitions of the architectural style – one of which is that of the application or component container.
An application container virtualizes an execution context within a host. It shares the resources of the host with other containers on that host. It can expose or consume resources such as:
- Service Ports
The benefit of application containers are minimalist, fine-grained services that can be developed, versioned, deployed independently of one another. Depending on the orchestration ecosystem employed these services are easily scaled across many hosts. And tend to enable continuous deployment.
When clustered, hosts can be grouped into ecosystems in which containers may be deployed. Systems such as Docker Swarm support features such as private networks, shared data volumes, multi-host networks, service discovery and resilient scheduling.
Docker relies on a sandboxing method known as containerization. Unlike traditional virtualization, containerization takes place at the kernel level. Most modern operating system kernels now support the primitives necessary for containerization, including Linux with openvz, vserver and more recently lxc, Solaris with zones, and FreeBSD with Jails.
As can be imagined, many ecosystems have appeared in which to run containers. Here are just a few.
The use of containers allows us to compose solutions from reusable components. Need a web server? No problem! Simply start a container, map the app location, map the internal port 80 to an appropriate external port and use it. No more installing web servers or requiring a centralized farm of web servers to be used.
While containers have been around for a few years now, the technology is very much in its infancy. This is evidenced by the constant maneuvering by various companies involved. See  and  for examples of this.
The benefits are, however, being felt in the wild and as such container-based computing as an expression of the microservices architectural style is attracting a lot of attention. In this age of cloud computing some mechanism for delivering and discovering services in a cluster of nodes was inevitable.
However, as described in “Microservices – not a Free Lunch”  – “a lot of complexity exists at a higher level in terms of managing these services and orchestrating business processes throughout them” – it remains to be seen as to whether the current definition of application containers delivers the promised benefits.
In the next few posts I will describe some Docker basics and how I solve for a specific use case. Stay tuned …