[Document] What is Microservice Architecture?

MICROSERVICES ARCHITECTURE

Introduction To Microservices

Microservice architecture is a method of developing software systems. Its focus is building small, reusable, scalable services. Applying Microservices becomes very important when you have to create services for polyglot devices: wearables, Internet of Things (IOT), mobile, desktop, and web. The trend towards providing services for rich, native mobile application and web applications started the trend towards Microservices adoption. This is one reason why microservices lean heavily on web technologies like HTTP/REST/WebSocket with JSON, Message Pack, and their ilk. The web technologies provide a low barrier to entry and least common denominator to communication.

The closest to a standard definition of microservices is Microservices by James Lewis and Martin Fowler.

Key ingredients to microservices architecture are:

• independently deployable, small, domain-driven services
• communication through a well-defined wire protocol usually JSON over HTTP (curl-able interfaces)
• well defined interfaces and minimal functionality
• avoiding cascading failures and synchronous calls - reactive designing for failure

SOA vs. Microservices

This comes up a lot so let's address this now.

It is very common for some to confuse Service-Oriented Architecture (SOA) and Microservice Architecture. In a sense, SOA and Microservice Architecture are related in some goals and purposes.

It’s not the daily increase but daily decrease. Hack away at the unessential. --Bruce Lee

Microservices is a refocus and refinement of some of the original goals of SOA to meet the demands of a polyglot device environment that can scale and support continuous deployments in a cloud / third generation virtualization environment.

Since SOA was later muddled with BPEL, ESBs, SOAP, WSDL, and their ilk, it is easier to drop the SOA moniker and just focus on the parts that worked well. Keep the parts that work. Get rid of the rest.

The focus on Microservices Architecture is web technologies to provide scalability, modular, domain-drive, small, and continuously deployable cloud-based services.

Microservices Architecture is taking what perhaps started out as SOA and applying lessons learned as well as pressure to support polyglot devices, deploy more rapidly and the architecture liquidity that cloud computing and virtualization/containerization provide. You mix all that together and you can see where Microservices Architecture started. Microservices Architecture is in general less vendor driven than SOA and more needs driven by demands of application development and current cloud infrastructure.

For more thoughts on SOA vs. Microservices read Microservices Architecture.

Continuously deployable services

The focus on Microservices is a focus on business capability, and a refocus on object oriented programming roots and organizing code around business domains with data and business rules co-located in the same process or set of processes.

The focus is on breaking up applications into small reusable services which might be useful to other services or other applications. The services can be deployed independently. This allows each of these services to be tweaked, and then redeployed independently. This is where the "micro" part of microservices comes into play. The services are small and independent. This is where microservices have been compared to Unix philosophy, they provide services that handle requests and give responses. Ken Thompson, Unix creator, said Unix has a philosophy of one tool, one job.

The Unix philosophy emphasizes building short, simple, clear, modular, and extendable code that can be easily maintained and repurposed by developers other than its creators.

Cope with failure

Microservices are designed to cope with failure. Since microservices tend to call each other, a downstream service that fails should not block upstream services and clients. Synchronous communication is avoided to avoid cascading failures. Thus Microservices tend to embrace async calls, streams, queues and actor systems. To handle failure, it is easier to embrace Queue theory so you can detect failure and provide alternatives or just fail gracefully without blocking clients. The ability to react to failure is a key characteristic of Microservices.

In order to learn about downstream failure or learn about other functioning nodes and implement some sort of circuit breaker, one needs Service Discovery. Tools like consul, etcd and SkyDNS are perfect for Service Discovery.

Adopting Microservices is not a free lunch. Steps to mitigate inherent complexity include distributed logging and MDC, microservices monitoring and stats, and reactive programming to coordinate async calls. The reactive call coordination would encompass what to do if there is a failure and what to do if a downstream service does not fail, but just times out or worse hangs.

more coming