The Fundamentals of Microservices

Microservices is composed of independent processes which communicate with each other via language-independent programming interfaces. The services are largely decoupled and do a small job. In this way, they enable a modular design of application software. The idea behind microservices is largely in line with the Unix philosophy – Do One Thing and Do It Well. The services should usually have the following characteristics:

• The services can be easily replaced.
  The scope of a microservice should be manageable for each team member.
  A microservice should be able to be recreated and replaced by the appropriate team (usually 5 to 7 developers) with reasonable time (within one month).
• A microservice should implement a bounded context in the sense of domain-driven design.
  The services have a single business function. For example, you can include an order process, registration, or invoicing, but not several of these things.
• The user’s benefit is the focus.
  The core functionality should be delivered early to provide the earliest possible benefit.
  Interfaces should be self-documenting via Humane Registries. For example, Swagger for JSON-based REST services.
  After a new version of the service is deployed, the old version of the endpoint must be deployed for some time.
• A microservice is developed by only one team. Conway’s law ensures that the architecture is also protected by organizational measures. Similarly, a team can be responsible for several professionally related microservices.
  Communication overhead and conflicts of interest between teams are avoided.
• The interfaces hide implementation details.
  It should not be clear which architecture was used to implement a service. Standard low overhead methods, such as REST, are preferably used.
  Databases are not used by multiple services, but only by a single service. This also applies to views and stored procedures. Otherwise, the architecture is published through the database and transaction security, data integrity, and versioning cannot be ensured.
• Microservices are isolated from other services.
  Each microservice can use a different programming language, database, or a completely different technology stack.
  Each microservice can be put into production independently of other microservices. This facilitates a high degree of automation and enables continuous delivery.
  Objects that occur in multiple bounded contexts are implemented separately in each service. For example, in an authentication system, an ordering system, a logistics system, and an invoice system, the same customer is represented by different objects because the objects are subject to different requirements.
  Microservices are delivered in separate OS containers, virtual machines, or servers. This ensures the service against another service overloading the host system.
• Like all services, microservices must be secure:
  Microservices should be decentralized and scaled horizontally. Functional architectures with state-of-the-city architectures are preferred. This includes caches (for storing user sessions) that must be run as a separate service, such as an in-memory key-value database.
  Microservices isolate error events and states from other services.
  Logging, monitoring and operations databases enable observability.
  Authentication, authorization, and cryptography protect the data from unwanted access.

The size of a microservice is limited by the fact that network communication between microservices can be resource-intensive and a separate deployment must be provided for each microservice.

 

Typical Components of a Microservice Architecture

 

Microservices require a lot of infrastructures, which is implemented by standalone services. Load balancers are used for load distribution of external HTTP requests from clients. Static content is delivered via a content delivery network.

The services responsible for business requirements are supported by a range of platform or infrastructure services. These perform key tasks such as application and service monitoring, logging web services, operations databases, configuration management, encryption, authorization and authentication, as well as autoscaling, software distribution, A/B testing and fault injection testing (FIT). There are also central routing services that are used to map URLs to instances with the respective services. Also, there are services for data persistence, especially caching, relational databases and NoSQL databases, as well as BLOB storage for any files.

Both SOA (Service-Oriented Architecture) and Microservices use services as architectural elements. SOA uses services to integrate different applications. The combination of services is done by orchestration or choreography, and portals can provide a common user interface (UI) for all services. Microservices structure an application through services. Each microservice can contain a user interface and implement business processes found in the orchestration in SOA.

Also read Advantages and Disadvantages of MicroServices.

This Article Has Been Shared 183 Times!

Facebook Twitter Pinterest