Services for micro-service based applications Flashcards
MONOLITHIC APPLICATIONS
In a traditional monolithic
application, all functionality is
in the same application.
The application is scaled by
running the whole application
at multiple servers.
Micro-service application
In a micro-service application,
different functionalities are
separated into smaller
services.
A microservice-based
application scales out by
deploying each service
independently, creating
instances of these services
across servers/virtual
machines/containers.
Desirable properties of micro-services
Some desirable properties:
* Consists of code, and optionally state, both of which are
independently versioned, deployed, and scaled.
* Interacts with other microservices over well-defined
interfaces and protocols.
* Has a unique name (URL) that is used to resolve their
location.
* Can be written in any programming language.
* Should remain consistent and available in the presence of
failures.
Advantages of micro-services
- Small Modules – easier to program and maintain.
- Easier Evolution and Process Adaption – easier to evolve the
system and adapt new technologies, as it is possible to
adapt only some of the micro-services. - Independent scaling – possible to scale each micro-service
independently. - Independent faults – a fault in a micro-service does not
affect other micro-services.
Challenges of micro-services
- Monitoring and management – Necessary to manage a
potential large number of micro-services, continuously
monitoring the state of the services. - Configuration and Deployment – Need to keep the
configuration for all micro-services and automate its
deployment. - Application support – what services exist for simplifying
inter-service communication and coordination? - Debugging and testing – Debugging and testing become
very complex, as a request leads to multiple requests;
difficult to test micro-services independently.
TRANSPORT SUBSYSTEM
The Transport Subsystem is used for communication within
a cluster and with clients.
Supports one-way and request-reply communication patterns.
This subsystem is used internally by Service Fabric and is not
directly accessible by application.
FEDERATION SUBSYSTEM
The Federation Subsystem serves for managing a cluster. It
provides the distributed systems primitives needed by the other
subsystems - failure detection, leader election, and consistent
routing.
The federation subsystem is built on top of DHT.
RELIABILITY SUBSYSTEM
The Reliability Subsystem provides the mechanism to make
the state of a Service Fabric service highly available.
The Replicator replicates the state of micro-services – default
replicator uses primary/backup replication.
The Failover Manager reconfigures the cluster and replicas to
distributed load and maintain availability.
The Resource Manager manages resources to guarantee that
micro-services are operational.
MANAGEMENT SUBSYSTEM
The Management subsystem provides end-to-end service
and application lifecycle management.
Cluster Manager: The cluster manager manages the lifecycle
of the applications from provision to de-provision.
Health Manager: This service enables health monitoring of
applications, services, and cluster entities.
Image Store: This service provides storage and distribution of
the application binaries.
COMMUNICATION SUBSYSTEM
The Communication subsystem provides reliable messaging
within the cluster and service discovery through the Naming
service. The Naming service resolves service names to a
location in the cluster.
Using the Naming service, clients can securely communicate
with any node in the cluster to resolve a service name and
retrieve service metadata.
Reliable services
Reliable Services is a light-weight framework for writing
services that integrate with the Service Fabric platform and
benefit from the full set of platform features.
