# Microservices

## Summary


Microservice Architecture describes an approach where an application is developed using a collection of loosely coupled services. Previously, applications were based on centralized multi-tier architecture. This worked well in the age of mainframes and desktops. But with cloud computing and mobile devices, backend must be available at all times for a wide range of devices. Bug fixes and features must be delivered quickly without downtime or deploying the entire application. 

Microservices are independently deployable, communicating through web APIs or messaging queues to respond to incoming events. They work together to deliver various capabilities, such as user interface frontend, recommendation, logistics, billing, etc.

Microservices are commonly run inside containers. Containers simplify deployment of microservices but microservices can run even without containers.

## Discussion

### What are Microservices?

A microservice is an **autonomous independent service** that encapsulates a business scenario. It **contains the code and state**. Usually a microservice even contains its own data store. This makes it independently versionable, scalable and deployable. A microservice is loosely coupled and **interacts** with other microservices through well-defined interfaces using protocols like http. They remain **consistent and available** in the presence of failure. A microservice is independently releasable. Each microservice can be scaled on its own without having to scale the entire app. 


### What are the types of Microservices?

Broadly, there are two types of microservices: 

    + **Stateless**: Has either no state or it can be retrieved from an external store (cache/database). It can be scaled out without affecting the state. There can be N instances. Examples: web frontends, protocol gateways, etc. A stateless service is not a cache or a database. It has frequently accessed metadata, no instance affinity and loss of a node is non-evident.
    + **Stateful**: Maintains a hard, authoritative state. For large hyper-scale application the state is kept close to compute. N consistent copies achieved through replication and local persistence. Example: database, documents, workflow, user profile, shopping cart, etc. A stateful service consists of databases and caches and the loss of a node is a notable event. It is sometimes a custom app that holds large amounts of data.As a variation, one author has identified three types: stateless (compute), persistence (storage), aggregation (choreography). Aggregation microservices depend on other microservices, thereby have network and disk I/O dependence. 


### What are the types of microservices in a layered architecture?

When we look at microservices as a layered architecture, we can identify the following types: 

    + **Core/Atomic services**: Fine-grained self-contained services. No external service dependencies. Mostly business logic. Often no network calls.
    + **Composite/Integration Services**: Business functionality composed from multiple core services. Include business logic and network calls. Implement routing, transformations, orchestration, resiliency and stability patterns. Often interface to legacy or proprietary systems.
    + **API/Edge Services**: A selected set of integration services and core services offered as managed APIs for consumers. Implement routing, API versioning, API security and throttling.

### How are microservices different from APIs?

APIs are not microservices and microservices are not the implementation of an API. API is an interface. A microservice is a component. The term "micro" refers to the component and not the granularity of the exposed interfaces. Microservices can be used to expose one or more APIs. However, not all microservice components expose APIs. 


### What's the relationship between Microservices Architecture and Service Oriented Architecture (SOA)?

SOA and Microservice architecture relate to different scopes. While SOA relates to enterprise service exposure, microservice architecture relates to application architecture. Both try to achieve many of the same things (creation of business functions as isolated components) but at a different scale. They differ in maintainability, granularity, agility, etc. SOA is a very broad term and microservices is a subset of that usage. Netflix noted that microservices is "fine-grained SOA". Microservices have been recognized as "SOA done right". 

Some microservices principles are really different to SOA: 

    + Reuse is not the goal: Reuse of common components is discouraged due to the dependencies it creates. Reuse by copy is preferred.
    + Synchronous is bad: Making synchronous calls such as API or web services creates real-time dependencies. Messaging is used whenever possible between microservices.
    + Service Discovery at run time: Components are assumed to be volatile. So it's often the clients’ responsibility to find and even load balance across instances.
    + Data Duplication is embraced: Techniques such as event sourcing result in multiple independent "views" of the data, ensuring that microservices are truly decoupled.

### What are the important principles to keep in mind while designing a Microservices Architecture?

Broadly speaking the following principles are good to know while designing a microservices architecture: Modelling around a Business Domain, Culture of Automation, Hide Implementation Details, Highly Observable, Decentralise all things, Isolate Failure, Consumer First, Deploy Independently. 


### What are the advantages of using a microservices architecture?

Advantages span both development and operations. Briefly we note the following advantages: Build and operate service at scale, Improved resource utilisation to reduce costs, Fault isolation, Continuous Innovation, Small Focused Teams, Use of any language or framework. 

Scalability comes because of the modularity that microservices enable. Because of containers, microservices have become easier deploy in various environments. Because of the isolation of services, there's also a security advantage: an attack on one service will not affect others. 

Microservices are about code and development. Containers are about deployment. Containers enable microservices. Containers offer isolated environments, thus making them an ideal choice for deploying microservices. However, it's possible to deploy microservices without containers. For example, microservices can be deployed independently on Amazon EC2. Each microservice can be in its own auto-scaling group and scaled independently. 


### Why should I probably not adopt microservices for my app?

Since application is distributed across microservices, such distributed systems are harder to manage and monitor. Operational complexity increases as the number microservices and their instances increases, particularly when they are dynamically created and destroyed. Network calls can be slow and even fail at times. Being distributed, maintaining strong consistency is hard and application has to ensure eventual consistency. 

Microservices require more time for planning and partitioning the app. They should be designed with failure in mind. When you are building a Minimum Viable Product (MVP) or experimenting to assess what works or can add value to business, then a monolithic approach is faster and easier. Adopt microservices only when you need to scale after your idea and its business value is proven. 

If you're managing a legacy application, the effort to migrate to microservices might involve considerable cost. The technology stack may be considerably larger than a monolithic app. Applications have a great dependence on networking and its performance. Microservices can be tested independently but to test the entire application is more difficult. 

## Milestones

1970

Although not directly influencing the birth of microservices, it's been noted that from an architectural/philosophical perspective similar ideas existed in the 1970s: Carl Hewitt's Actor Model; or pipes in UNIX that connect many small programs, each of which did something specific rather than having a large complex program that did many things. 

1990

This is the decade when **Service-Oriented Architecture (SOA)** starts to gain wider adoption. The term itself is first described by Gartner in 1996. The idea is to use services as isolated and independent building blocks that collectively make up an application. Services are loosely bound together by a standard communications framework. 

2000

To enable applications to communicate with one another over a network, W3C standardizes SOAP. Over the next few years, WSDL and UDDI gets standardized as well. XML is the preferred format of communication. Through this decade, **Web Services**, a web-based implementation of SOA, becomes popular over proprietary methods such as CORBA or DCOM. 

2009

Netflix redefines the way it develops apps and manages operations by relying completely on APIs. This later develops into what we today call microservices. 

May  
2011

The term **microservices** gets discussed at a workshop of software architects near Venice, to describe a common architectural style that several of them were exploring at the time. 

2012

**REST** and **JSON** become the de facto standard to consume backend data. These would later prove to be foundational for inter-service communication when building microservices-based apps.

Mar  
2013

Closely related to microservices, **Docker**, a computer program that performs operating-system-level virtualization (containerization), gets open sourced. 

Jun  
2014

**Kubernetes**, a container orchestration system for automating deployment, scaling and managing containerized applications, gets open sourced by Google. 

Nov  
2015

An app developer survey from NGINX shows that microservices are entering mainstream with about two-thirds either using or investigating them. Adoption is higher with medium and small companies.