Microservices-enabling service ecosystem

In order to successfully run microservices, there are certain enabling components/services that are needed. These enabling services can be tagged as PaaS that are needed to support the building, releasing, deployment, and running of the microservices.

In the case of the cloud-native model, these services are available as PaaS services from the cloud provider itself:

• Service discovery: When the application is decomposed into a microservices model, a typical application may be composed of hundreds of microservices. With each microservice running multiple instances, we soon have thousands of microservice instances running. In order to discover the service endpoint, it is pertinent to have a service registry that can be queried to discover all of the instances of the microservice. In addition, the service registry tracks the heartbeat of every service instance to make sure that all services are up and running.
  Further, the service registry helps in load balancing the requests across the service instances. We can have two models for load balancing:
  • Client-side load balancing:
    • A service consumer asks the registry for a service instance
    • The service registry returns with the list of services where the service is running
  • Server-side load balancing:
    • The service endpoint is hidden by Nginx, API Gateway, or another reverse proxy from the consumer

  Typical products in this space are Consul and Zookeeper:

• Config server: The microservice needs to be initialized with multiple parameters (for example, database URL, queue URL, functional parameters, and dependency flags). Managing properties in file or environment variables beyond a certain number can become unwieldy. To manage these properties across environments, all such configurations are managed externally in a configuration server. At boot time, microservices will load the properties by invoking the API on the config server.
  Microservices also make use of listeners to listen for any changes to the properties on the config server. Any runtime change of properties can be picked up immediately by the microservices. The properties are typically categorized at multiple levels:
  • Service-specific properties: Hold all properties tied to the microservice
  • Shared properties: Hold properties that might be shared between services
  • Common properties: Hold properties that are common across services

  The config server can back up these properties in a source-control system. Typical products in this space are Consul, Netflix Archaius, and Spring Cloud Config server:

• Service management/monitoring: An average business application typically tends to get decomposed into about 400 microservices. Even if we ran two to three instances of these microservices, we would be talking about managing over 1,000  instances of our microservices. Without an automated model, managing/monitoring these services becomes an operational challenge. The following are the key metrics that need to be managed and monitored:
  • Service health: Each service needs to publish its health status. These need to be managed/tracked to identify slow or dead services.
  • Service metrics: Each service also publishes throughput metrics data, such as the number of HTTP requests/responses, the request/response size, and the response latency.
  • Process info: Each service will publish JVM metrics data (like heap utilization, the number of threads, and the process state) typically available as part of the Java VisualVM.
  • Log events as stream: Each service can also publish log events as a set of streaming events.

  All of this information is pulled from the services and tied together to manage and monitor the application services landscape. Two types of analysis—event correlation and correction decisions—need to be done. Alerts and actuation services are built as part of the service monitoring systems. For example, if a certain number of service instances need to be maintained and the number reduces (service not available due to health check) then an actuation service can take the event as an indicator to add another instance of the same service.

  Further, in order to track the service call flow through the microservices model, there is third-party software available that can help create a request identified and track how the service call flows through the microservices. This software typically deploys agents onto the containers, which weave them into the services and track the service metrics:

• Container management/orchestration: Another key infrastructure piece of the microservice environment is container management and orchestration. The services are typically bundled in a container and deployed in a PaaS environment. The environment can be based on an OpenShift model, a Cloud Foundry model, or a pure VM-based model, depending whether they are deployed on a private or a public cloud. To deploy and manage the dependencies between the containers, there is a need for container management and orchestration software. Typically, it should be able to understand the interdependencies between the containers and deploy the containers as an application. For example, if the application has four pieces—one for UI, two for business services, and one for data store—then all of these containers should be tagged together and deployed as a single unit with interdependencies and the right order of instantiation injected.
• Log aggregation: 1 of the 12 factors is treating logs as event streams. The containers are meant to be stateless. The log statements are typically stateful events that need to be persisted beyond the life of the containers. As a result, all logs from the containers are treated as event streams that can be pushed/pulled onto a centralized log repository. All the logs are aggregated and various models can be run on these logs for various alerts. One can track security and failure events through these logs, which can feed into the service management/monitoring system for further actions:

• API Gateway/management: The services are meant to be simple and follow the single responsibility model. The question arises: who will handle other concerns, such as service authentication, service metering, service throttling, service load balancing, and service freemium/premium models? This is where the API Gateway or management software comes into the picture. The API Gateway handles all such concerns on behalf of the microservice. The API Gateway provides multiple options for managing the service endpoints and can also provide transformation, routing, and mediation capabilities. The API Gateway is more lightweight, compared to the typical enterprise service bus.

• DevOps: Another key aspect is the continuous integration/deployment pipeline, coupled with the automated operations that need to set up the microservice-based applications. As the developer writes code, it goes through a series of steps that need to be automated and mapped with gating criteria to allow the release of regression-tested code: