A microservices architecture is a type of application architecture where the application is developed as a collection of services. It provides the framework to develop, deploy, and maintain microservices architecture diagrams and services independently.
Microservices are the blocks of your application and perform different services, while REST APIs work as the glue or the bridge that integrates these separate microservices. APIs can be made up, wholly or partially, out of microservices. Developers can use Microservices for a lot more, though
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
