The document discusses microservices as an advanced form of service-oriented architecture, emphasizing their independence, communication via APIs, and design principles like scalability and failure resistance. It contrasts microservices with traditional SOA, highlighting advantages such as the ability to scale applications easily and the need for asynchronous communication. However, it also mentions challenges such as debugging complexities and communication gaps between services.

1. MICROSERVICES

2. MONOLITHIC APPLICATION
 Typical applications using a framework, or all the applications we have been
developing are divided into different parts, such frontend, backend and
database, an also use Model-View-Controller (MVC) pattern or Client/Server
Applications or even Host/Terminal applications.

3. WHAT ARE MICROSERVICES?
 We can define a microservice as an extended Service Oriented Architecture. In
other words, it is a way to develop an application by following the required
steps to turn it into various little services.
 Each service will execute itself and communicate with others through
requests, usually using APIs on HTTP.
 A microservice is simple, isolated entity with a concrete proposal.
 It is independent and works with the rest of the microservices by
communicating through an agreed channel.

4. SOA VERSUS MICROSERVICES
 SOA focuses on integrating monolithic applications between themselves and it uses as Enterprise Service
BU to achieve this.
 SOA includes:
 Business process Management (BPM)
 Service repositories
 Register
 BPEL
 Microservices tried to connect different components between themselves using APIs.

5. SOA VERSUS MICROSERVICES
 Microservice architecture:
 Ready to fail: Microservices are designed to fail. In a web application, microservices
communicate with each other and if one of them fails, the rest should work to avoid a cascading
failure. Attempt to avoid communicating synchronously using async calls, queues, system based
on actors, and streams instead.
 Unix philosophy: Each microservice must be designed to do one thing only, and should only be
small and independent.
 Communication layer: Each microservice communicates with the others with the others through
HTTP requests and messages, executing the business logic, querying the database, exchanging
messages with the required systems and, an the end returing a JSON (or HTML/XML) response.
 Scalability: The main reason to choose a microservice architecture is that it is possible to scale
the application easily.

6. DISADVANTAGES OF MICROSERVICES
 Debugging
 Maintain every single microservice as an entire server, in other words, every single microservice can have
one or more database, logs, different services, or library versions, and even the code can be in different
language
 Communication gaps
 Learn tools for Full automatization (Continuous Integration – Continuous Delivery) (CI/CD)
 Jenkins, Docker, Terraform, Packer, Ansible, Chef, Puppet, Kubernetes.
 Network latency

7. DEVELOPMENT ON MICROSERVICES
 The most important idea behind microservice is the need to decompose your application into smaller
logical pieces.
 Always create small logical black boxes. Each microservice is likea a black box with a public interface,
which is the only way to interact with your software.
 Each service can be scaled up or down.
 Use a lightweight communication protocol. Like HTTP or REST.
 Use queues to reduce a service load or make async executions.
 Be ready for the worst case scenario, like cascade failure.
 Each service is different, so keep different repositories and build environments.

8. BASIC PLATFORM FOR MICROSERVICES
REVERSE PROXY to balance the load
NGINX as a gateway for the API build
CACHE to reduce the load and increase
performance
QUEUE system to execute big resource
consuming tasks or tasks need to be
executed deferred
DATA STORE for saving data for authorized
users
Telemetry for stats system from the container
Autodiscovery helps to see which container
is working properly