The document discusses microservices architecture, which is an approach to developing applications as a suite of small, independent services that communicate via lightweight mechanisms. It highlights the limitations of monolithic applications, such as challenges in scalability and frequent deployments, and outlines the characteristics, benefits, and principles of microservices, including decentralized governance, infrastructure automation, and fault isolation. Additionally, it covers various design patterns, such as API gateways and service registries, and emphasizes the importance of service independence and organization around business capabilities.

1. Microservices Architecture
Fundamental and Practice

2. Fundamental

3. 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

4. Start from Monolithic
Monolithic 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.

5. The limit of monolithic
Monolithic 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

6. Monolithic Microservices

7. Characteristic of Microservices Architecture
Componentization via services
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure

8. Componentization via services
a 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.

9. Organized around Business Capabilities
Any 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.

10. Products not Projects
Microservice 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

11. Smart endpoints and dumb pipes
Applications 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

12. Decentralized Governance
One 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.

13. 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.

14. Decentralized Data Management (2)

15. 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.

16. Design for failure
Any 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.

17. Evolutionary Design
Evolutionary 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.

18. Pattern & Practice

19. The Pattern
Monolithic 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

20. 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 IDE
Overloaded web container

21. 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 .

22. 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

23. 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.

24. Related Pattern

25. API Gateway
Implement 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.

26. 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.

27. 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.

28. Server-side Discovery
When 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

29. 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:
Eureka
Apache Zookeeper
Consul
Etcd

30. 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

31. Self Registration
A 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 services
A service instance that is running yet unable to handle requests will often lack the self-awareness to
unregister itself from the service registry

32. 3rd Party Registration
A 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.

33. Multiple Services per host
Run 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 versions
Difficult to limit the resources consumed by a service instance
Difficult to monitor process

34. Single Service per host
Deploy each single service instance on it’s own host.
The benefits of this approach include:
Services instances are isolated from one another
There is no possibility of conflicting resource requirements or dependency
versions
A service instance can only consume at most the resources of a single host
Its straightforward to monitor, manage, and redeploy each service instance
Drawbacks:
Potentially less efficient resource utilization

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

36. 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.

37. Additional

38. The Scale Cube
X-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.

39. 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.

40. CAP Theorem (2)

41. Reference
http://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