Table of Contents

Microservices Definition.................................................................................................................2
SOA Definition................................................................................................................................3
Microservices vs SOA......................................................................................................................4
Microservices Characteristics.........................................................................................................4
Microservices Advantages and Disadvantages...............................................................................5
Microservices Principles.................................................................................................................6
Microservices Guidelines................................................................................................................6
Microservices Patterns....................................................................................................................7
Improving Performance...................................................................................................................8
Phoenix Server................................................................................................................................8
Microservices Definition

Q: What is a Microservices?
A: Some definitions of Microservices

“The concept of a microservice initially crept into the software development community’s
consciousness as a direct response to many of the challenges of trying to scale (both
technically and organizationally) large monolithic applications. A microservice is a small,
loosely coupled, distributed service. Microservices let you take an extensive application and
decompose it into easy-to-manage components with narrowly defined responsibilities.
Microservices help combat the traditional problems of complexity in a large codebase by
decomposing it down into small, well-defined pieces. The key concepts you need to embrace as
you think about microservices are decomposing and unbundling” (Spring Microservices in
Action-2nd Ed)

“Adrian Cockcroft, formerly of Netflix, defines a microservice architecture as a service-

oriented architecture composed of loosely coupled elements that have bounded contexts.”
(Microservices Patterns)

“A microservice application is a collection of autonomous services, each of which does one

thing well, that work together to perform more intricate operations. Instead of a single
complex system, you build and manage a suite of relatively simple services that might interact
in complex ways. These services collaborate with each other through technology-agnostic
messaging protocols, either point-to-point or asynchronously” (Microservices In Action)

In software engineering, a microservice architecture is a variant of the service-oriented

architecture structural style. It is an architectural pattern that arranges an application as a
collection of loosely coupled, fine-grained services, communicating through lightweight
protocols. One of its goals is that teams can develop and deploy their services independently
of others. This is achieved by the reduction of several dependencies in the code base, allowing
developers to evolve their services with limited restrictions from users, and for additional
complexity to be hidden from users.[1] As a consequence, organizations are able to develop
software with fast growth and size, as well as use off-the-shelf services more easily.
Communication requirements are reduced. These benefits come at a cost to maintaining the
decoupling. Interfaces need to be designed carefully and treated as a public API. One
technique that is used is having multiple interfaces on the same service, or multiple versions of
the same service, so as to not disrupt existing users of the code.
(https://en.wikipedia.org/wiki/Microservices)

“Also known as the microservice architecture - is an architectural style that structures an

application as a collection of services that are: Independently deployable, Loosely coupled
Services are typically organized around business capabilities. Each service is often owned by
a single, small team.” (microservices.io)

“Microservices are an architectural and organizational approach to software development

 where software is composed of small independent services that communicate over well defined
APIs. These services are owned by small, self-contained teams. Microservices architectures
make applications easier to scale and faster to develop, enabling innovation and accelerating
time-to-market for new features” (https://aws.amazon.com/microservices)

SOA Definition

Q: What is a SOA?
A: Some definitions of SOA

“In software engineering, service-oriented architecture (SOA) is an architectural style that

focuses on discrete services instead of a monolithic design. By consequence, it is also applied
in the field of software design where services are provided to the other components
by application components, through a communication protocol over a network. A service is a
discrete unit of functionality that can be accessed remotely and acted upon and updated
independently, such as retrieving a credit card statement online. SOA is also intended to be
independent of vendors, products and technologies” (https://en.wikipedia.org/wiki/Service-
oriented_architecture)

“Service-oriented architecture (SOA) is a paradigm for the realization and maintenance of

business processes that span large distributed systems. It is based on three major technical
concepts: services, interoperability through an enterprise service bus, and loose coupling.

 A service is a piece of self-contained business functionality. The functionality might

ben simple (storing or retrieving customer data), or complex (a business process for a
customer’s order). Because services concentrate on the business value of an interface,
they bridge the business/IT gap.
 An enterprise service bus (ESB) is the infrastructure that enables high interoperability
between distributed systems for services. It makes it easier to distribute business
processes over multiple systems using different platforms and technologies.
 Loose coupling is the concept of reducing system dependencies. Because business
processes are distributed over multiple backends, it is important to minimize the effects
of modifications and failures. Otherwise, modifications become too risky, and system
failures might break the overall system landscape. Note, however, that there is a price
for loose coupling: complexity. Loosely coupled distributed systems are harder to
develop,maintain, and debug.”
(SOA in Practice)

“Service-oriented architecture (SOA) is a method of software development that uses software

components called services to create business applications. Each service provides a business
capability, and services can also communicate with each other across platforms and
languages. Developers use SOA to reuse services in different systems or combine several
 independent services to perform complex tasks.” (https://en.wikipedia.org/wiki/Service-
oriented_architecture)

Microservices vs SOA

Q: What are the differences between microservices and SOA

A: The main intent of microservice is independent and SOA is reusability and integration.
Some of other differences are

Microservices SOA
Communication Generic Specific
Data Per services Shared
Scope Small Large

Microservices Characteristics

Q: What are some microservices characteristics

A: Below are some characteristics of microservices applications

 Application logic is broken down into small-grained components with well defined,
coordinate boundaries of responsibility.
 Each component has a small domain of responsibility and is deployed independently of
the others. A single microservice is responsible for one part of a business domain.
 Microservices employ lightweight communication protocols such as HTTP and JSON
(JavaScript Object Notation) for exchanging data between the service consumer and
service provider. Because microservice applications always communicate with a
technology-neutral format (JSON is the most common), the underlying technical
implementation of the service is irrelevant. This means that an application built using a
microservice approach can be constructed with multiple languages and technologies.
 Microservices—by their small, independent, and distributed nature—allow organizations
to have smaller development teams with well-defined areas of responsibility. These teams
might work toward a single goal, such as delivering an application, but each team is
responsible only for the services on which they’re working.

Microservices Advantages and Disadvantages

Q: What are the advantages and disadvantages of microservices ?

A: Some advantages and disadvantages of microservices
The advantages are

 It enables the continuous delivery and deployment of large, complex applications.

o Easier automated testing
o Independent services (ownership and deployment)
 Services are small and easily maintained.
 Services are independently deployable.
 Services are independently scalable.
 The microservice architecture enables teams to be autonomous.
 It allows easy experimenting and adoption of new technologies.
 It has better fault isolation.

The disadvantages are:

 Finding the right set of services is challenging and requires substantial domain
knowledge
o The mistake of distributed monolithic
o You may need to refactor across multiple distinct codebases.
o You may need to migrate data from one service’s database to another.
o You may not have identified implicit dependencies between services, which could
lead to errors or incompatibility on deployment
 The right boundaries and contracts between services are difficult to identify and, once
you’ve established them, can be time-consuming to change.
o Good contract
 Complete —Defines the full scope of an interaction
 Succinct —Takes in no more information than is necessary, so that
consumers can construct messages within reasonable bounds
 Predictable —Accurately reflects the real behaviour of any
implementation

 Distributed systems are complex, which makes development, testing, and deployment
difficult.
 By distributing system components across networks, and increasing technical
heterogeneity, microservices introduce new modes of failure.
o Fallacies
 The network is reliable.
 Latency is zero.
 Bandwidth is infinite.
 Transport cost is zero.
 Deploying features that span multiple services requires careful coordination
 Deciding when to adopt the microservice architecture is difficult.
 It’s more challenging to understand and verify what should happen in normal operation.
o Observability is difficult to achieve
o Multiplying services multiplies points of failure
o Questions
  If something goes wrong and your user’s order isn’t placed, how would
you determine where the fault occurred?
 How do you deploy a new version of a service without affecting order
placement?
 How do you know which services were meant to be called?
 How do you test that this behaviour is working correctly across multiple
services?
 What happens if a service is unavailable?

Microservices Principles

Q: What are the architectural principles underpin microservices development ?

A: Five cultural and architectural principles underpin microservices development:
 Autonomy
o Loosely coupled
o Independently deployable
 Resilience
 Transparency
 Automation
 Alignment

Microservices Guidelines

Q: What are some main guidelines in building microservices ?

A: Below are some main guidelines in building microservices

 Right-sized—How you ensure that your microservices are properly sized so that you
don’t have a microservice take on too much responsibility. Remember, properly sized, a
service allows you to make changes to an application quickly and reduces the overall risk
of an outage to the entire application.
 Location transparent—How you manage the physical details of service invocation. When
in a microservice application, multiple service instances can quickly start and shut down.
 Resilient—How you protect your microservice consumers and the overall integrity of
your application by routing around failing services and ensuring that you take a “fail-
fast” approach.
 Repeatable—How you ensure that every new instance of your service brought up is
guaranteed to have the same configuration and codebase as all the other service instances
in production.
 Scalable—How you establish a communication that minimizes the direct dependencies
between your services and ensures that you can gracefully scale your microservices.
Microservices Patterns

Q: What are some microservices patterns

A: Below are some microservices patterns

 Core development pattern

o Service granularity
o Communication protocols
o Interface design
o Configuration management of service
o Event processing between service
 Routing patterns
o Service discovery
o Service routing
 Client resiliency patterns
o Client side load balancing
o Circuit breaker pattern
o Fallback pattern
o Bulkhead pattern
 Security patterns
o Authentication
o Authorization
o Credential management and configuration
 Logging and tracing patterns
o Log correlation
o Log aggregation
o Microservices tracing
 Application metrics patterns
o Metrics
o Metrics service
o Metric visualization suite
 Build and deployment pattern
o Build and deployment pipeline
o Infrastructure as code
o Immutable servers
o Phoenix servers

Improving Performance

Q: What are some ways to improve API performance ?

A: Below are some ways to improve API performances
Backend Level
- Load balancing and add more instances
- Parallel processing for big tasks
Code Level
- Improve algorithm
Database level
- Index
- Sharding
- Sub clause to join
- Add column
- Cut data
- De-normalize
Feature level
- Limit feature

Phoenix Server

Q: What does phoenix server mean ?

A: The term "phoenix server" in the context of microservices refers to a design pattern or
approach where servers are treated as ephemeral and disposable resources. Instead of
updating and maintaining long-lived servers, new instances of the server are created and
deployed, and old instances are terminated. This approach is named after the mythical
phoenix, which is reborn from its ashes, symbolizing the continual recreation and renewal
of the server instances. Here's a more detailed explanation of what it means and its
implications in a microservices architecture:

Key Characteristics of Phoenix Servers

1. Immutable Infrastructure:
 Phoenix servers are built using the concept of immutable infrastructure, where
once a server is deployed, it is not changed or updated. If changes are needed, a
new server with the updated configuration or software is created instead.
2. Automation and Orchestration:
 Automation tools and orchestration platforms (such as Kubernetes, Terraform,
and Ansible) are often used to manage the lifecycle of phoenix servers. These
tools ensure that new servers are provisioned, configured, and deployed
automatically.
3. Version Control and Rollback:
 Every change to the server configuration or software is tracked and versioned. If
an issue arises, it is easy to roll back to a previous, known-good version by
redeploying the corresponding server instance.
4. Consistency and Reliability:
 By always deploying new servers, phoenix servers ensure consistency across
deployments. This reduces the risk of configuration drift and ensures that all
instances are running the intended configuration and software versions.
5. Scalability:
  Phoenix servers make it easier to scale services up and down. New instances can
be created to handle increased load, and excess instances can be terminated when
they are no longer needed.

Benefits in Microservices
 Improved Resilience:
 If a server becomes unhealthy or experiences an issue, it can be terminated and
replaced with a new instance, minimizing downtime and improving overall
system resilience.
 Simplified Deployment Pipeline:
 The deployment process is simplified because it focuses on creating new
instances rather than modifying existing ones. This reduces the complexity of
deployments and the potential for errors.
 Enhanced Security:
 Regularly replacing servers with new instances reduces the window of
opportunity for attackers and ensures that security patches and updates are
consistently applied.
 Easier Maintenance:
 Maintenance tasks are simplified since there is no need to perform in-place
updates or maintenance on long-lived servers. Instead, new servers are deployed
with the required updates or fixes.

Example Use Cases

 Continuous Deployment:
 In a CI/CD pipeline, phoenix servers can be used to ensure that each deployment
is fresh, reducing the risk of deployment issues caused by lingering state or
configuration.
 Auto-scaling:
 Auto-scaling groups can use the phoenix server pattern to dynamically adjust the
number of server instances based on demand, ensuring that each new instance is
correctly configured and up-to-date.

Conclusion
The phoenix server approach in microservices promotes a dynamic, flexible, and robust
infrastructure. By treating servers as disposable and ensuring that each deployment starts fresh,
organizations can achieve greater consistency, reliability, and security in their microservices
architecture.