Microservices ArchitectureFundamental and Practice

Fundamental

What is Microservices?An approach to developing a single application as a suite of small services, each running of its own process and communication with lightweight mechanism, often HTTP resource API. ~ Martin Fowler

Start from MonolithicMonolithic is opposite of microservices. It is a common system that nowdays used. It is application built as single unit.

Applications are often built in three main parts: client-side, database, server-side.

Server side handle HTTP request, execute domain logic, retrieve & update DB, select the view or respond to client.

This server side application is a monolith.

The limit of monolithicMonolithic applications can be successful, but increasingly people are feeling frustrations with them, especially more applications are being deployed to the cloud.

Change cycles are tied together

Over time it's often hard to keep a good modular structure

Scaling requires scaling of the entire application

Monolithic

Microservices

Characteristic of Microservices ArchitectureComponentization via services

Organized around Business Capabilities

Products not Projects

Smart endpoints and dumb pipes

Decentralized Governance

Decentralized Data Management

Infrastructure Automation

Design for failure

Evolutionary Design

Componentization via servicesa component is a unit of software that is independently replaceable and upgradeable.

One main reason for using services as components (rather than libraries) is that services are independently deployable.

Organized around Business CapabilitiesAny organization that designs a system (defined

broadly) will produce a design whose structure is a

copy of the organization's communication structure.

-- Melvyn Conway, 1967

The microservice approach to division is different, splitting up into services organized around business capability.

Products not ProjectsMicroservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime.

The product mentality, ties in with the linkage to business capabilities.

The smaller granularity of services can make it easier to create the personal relationships between service developers and their users.

“You build, You run it” - Werner Vogels - CTO of Amazon

Smart endpoints and dumb pipesApplications built from microservices aim to be as decoupled and as cohesive as possible.

The two protocols used most commonly are HTTP request-response with resource API's and lightweight messaging.

By using simple RESTish protocols rather than complex protocols

By using messaging over a lightweight message bus. The infrastructure chosen is typically dumb. simple implementations such as RabbitMQ or ZeroMQ don't do much more than provide a reliable asynchronous fabric

Be of the web, not behind the web

-- Ian Robinson

Decentralized GovernanceOne of the consequences of centralised governance is the tendency to standardise on single technology platforms.

Experience shows that this approach is constricting - not every problem is a nail and not every solution a hammer.

In this case microservices could be like this:You want to use Node.js to standup a simple reports page? Go for it. C++ for a particularly gnarly near-real-time component? Fine. You want to swap in a different flavour of database that better suits the read behaviour of one component? We have the technology to rebuild him.

Decentralized Data Management ( 1 )At the most abstract level, it means that the conceptual model of the world will differ between systems.

This issue is common between applications, but can also occur within applications, particular when that application is divided into separate components. A useful way of thinking about this is the Domain-Driven Design notion of Bounded Context.

As well as decentralizing decisions about conceptual models, microservices also decentralize data storage decisions.

Decentralized Data Management (2)

Infrastructure Automation

Teams building software this way make extensive use of infrastructure automation techniques.

as much confidence as possible that our software is working, so we run lots of automated tests. Promotion of working software 'up' the pipeline means we automate deployment to each new environment.

Design for failureAny service call could fail due to unavailability of the supplier, the client has to respond to this as gracefully as possible.

Since services can fail at any time, it's important to be able to detect the failures quickly and, if possible, automatically restore service.

That’s why, microservices have a lot of monitoring process, real-time monitoring, business relevant metrics, log and so on.

Evolutionary DesignEvolutionary Design is see service decomposition as a further tool to enable application developers to control changes in their application without slowing down change.

Whenever you try to break a software system into components, you're faced with the decision of how to divide up the pieces. what are the principles?

The key property of a component is the notion of independent replacement and upgradeability.

Pattern & Practice

The PatternMonolithic Architecture

Microservices Architecture

API Gateway

Client-side discovery

Server-side discovery

Service Registry

Self Registration

3rd party Registration

Multiple service instance per host

Single service instance per host

Service instance per VM

Service instance per Container

Database per service

Monolithic Architecture (1)●Simple to develop●Simple to deploy●Simple to scale

However:The large monolithic code base intimidates developers, especially ones who are new to the

team. The application can be difficult to understand and modify. As a result, development typically slows down.

Overloaded IDEOverloaded web container

Monolithic Architecture (2)However:

Continuous deployment is difficult - a large monolithic application is also an obstacle to frequent deployments.

Scaling the application can be difficult - a monolithic architecture is that it can only scale in one dimension.

Obstacle to scaling development - A monolithic application is also an obstacle to scaling development.

Requires a long-term commitment to a technology stack - a monolithic architecture forces you to be married to the technology stack (and in some cases, to a particular version of that technology) you chose at the start of development .

Microservices Architecture (1)● Each microservice is relatively small

○ Easier for a developer to understand○ The IDE is faster making developers more productive○ The web container starts faster, which makes developers more productive, and

speeds up deployments● Each service can be deployed independently of other services● Easier to scale development. It enables you to organize the development effort around

multiple teams. Each (two pizza) team is responsible a single service.● Improved fault isolation. For example, if there is a memory leak in one service then

only that service will be affected. ● Eliminates any long-term commitment to a technology stack

Microservices Architecture (2)Another challenge is deciding how to partition the system into microservices. This is very much an art, but there are a number of strategies that can help.

Partition services by verb or use case.Partition the system by nouns or resources.

Related Pattern

API GatewayImplement an API gateway that is the single entry point for all clients. The API gateway handles requests in one of two ways.

The API Gateway must use either the Client-side Discovery pattern or Server-side Discovery Pattern to route requests to available service instances.

Client-side Discovery (1)Services typically need to call one another.In a traditional distributed system deployment, services run at fixed,

well known locations (hosts and ports) and so can easily call one another using HTTP/REST.

a modern microservice-based application typically runs in a virtualized or containerized environments where the number of instances of a service and their locations changes dynamically.

Client-side Discovery (2)The Benefit is fewer moving

parts and network hops compared to Server-side registry.

This pattern couples the client to service registry.

Server-side DiscoveryWhen making a request to a service, the client makes a request via a router (a.k.a load balancer) that runs at a well known location. The router queries a service registry.

More network hops are required than when using Client-side discovery

AWS provide this functionality, e.g. AWS Elastic Load Balancer

Service Registry (1)a database of services, their instances and their locations.

Service instances are registered with the service registry on startup and deregistered on shutdown.

Examples of service registries (or technologies that are commonly used as service registries) include:

EurekaApache ZookeeperConsulEtcd

Service Registry (2)The Service Registry is a critical system component. Although clients should cache data provided by the service registry, if the service registry fails that data will eventually become out of date. Consequently, the service registry must be highly available.

You need to decide how service instances are registered with the service registry. There are two options:

● Self registration pattern - service instances register themselves● 3rd party registration pattern - a 3rd party register the service instances with the

service registry

Note: Service registry instances must be deployed on fixed and well known IP addresses

Self RegistrationA service instance is responsible for registering itself with the service registry. On startup the service instance registers itself (host and IP address) with the service registry and makes itself available for discovery.

Drawbacks:You must implement service registration logic in each programming language/framework

that you use to write your servicesA service instance that is running yet unable to handle requests will often lack the self-

awareness to unregister itself from the service registry

3rd Party RegistrationA 3rd party registrar is responsible for registering and unregistering a service instance with the service registry.

Examples: Netflix Prana, AWS Autoscaling Groups, Joyent's Container buddy, Registrator, Clustering frameworks such as Kubernetes and Marathon (un)register service instances with the built-in/implicit registry.

Drawback:Unless the registar is part of the infrastructure it’s another component that must be installed, configured and maintained. Also, since it’s a critical system component it needs to be highly available.

Multiple Services per hostRun multiple instance of services on a host (Physical or Virtual machine).There are various ways of deploying a service instance on a shared host including:

Deploy each service instance as a JVM process. For example, a Tomcat or Jetty instances per service instance.

Deploy multiple service instances in the same JVM. For example, as web applications or OSGI bundles.

Drawbacks:Risk of conflicting resource requirements / dependency versionsDifficult to limit the resources consumed by a service instanceDifficult to monitor process

Single Service per hostDeploy each single service instance on it’s own host.The benefits of this approach include:

Services instances are isolated from one anotherThere is no possibility of conflicting resource requirements or

dependency versionsA service instance can only consume at most the resources of a single

hostIts straightforward to monitor, manage, and redeploy each service

instance

Drawbacks:Potentially less efficient resource utilization

Database per service (1)Keep each microservice’s persistent data private to that service and accessible only via its API. The following of example:

Database per service (2)if you are using a relational database then the options are:

Private-tables-per-service – each service owns a set of tables that must only be accessed by that service

Schema-per-service – each service has a database schema that’s private to that service

Database-server-per-service – each service has it’s own database server.

Additional

The Scale CubeX-axis scaling consists of running multiple copies of an application behind a load balancer.

Y-axis axis scaling splits the application into multiple, different services.

Z-axis splits are commonly used to scale databases. Data is partitioned (a.k.a. sharded) across a set of servers based on an attribute of each record.

CAP Theorem(1)Consistency (C), Availability (A), and Partition tolerance (P) across distributed systems.

Simply put, the CAP theorem demonstrates that any distributed system cannot guaranty C, A, and P simultaneously, rather, trade-offs must be made at a point-in-time to achieve the level of performance and availability required for a specific task.

CAP Theorem (2)

Referencehttp://martinfowler.com/articles/microservices.html

http://microservices.io/patterns/microservices.html

https://auth0.com/blog/2015/11/07/introduction-to-microservices-part-4-dependencies/

http://microservices.io/articles/scalecube.html