What is Microservice Architecture?

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 consuletcd and SkyDNSare perfect for Service Discovery.

Adopting Microservices is not a free lunch. Steps to mitigate inherent complexity include distributed logging and MDCmicroservices 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

QBit Java Micorservices lib tutorials

The Java microservice lib. QBit is a reactive programming lib for building microservices - JSON, HTTP, WebSocket, and REST. QBit uses reactive programming to build elastic REST, and WebSockets based cloud friendly, web services. SOA evolved for mobile and cloud. ServiceDiscovery, Health, reactive StatService, events, Java idiomatic reactive programming for Microservices.

Find more tutorial on QBit.

Reactive ProgrammingJava MicroservicesRick Hightower

High-speed microservices consulting firm and authors of QBit with lots of experience with Vertx - Mammatus Technology

Highly recommended consulting and training firm who specializes in microservices architecture and mobile development that are already very familiar with QBit and Vertx as well as iOS and Android - About Objects

Java Microservices Architecture

Microservice Service Discovery with Consul

Microservices Service Discovery Tutorial with Consul

Reactive Microservices

High Speed Microservices

Java Microservices Consulting

Microservices Training

Reactive Microservices Tutorial, using the Reactor

QBit is mentioned in the Restlet blog