Understanding Microservices

Learn about microservices and how they are implemented in Oracle Communications Unified Assurance environments.

Microservices Overview

Microservices are simple, single-purpose components that work in unison to create an application. Being made of up smaller, modular pieces makes applications easier to build, test, and maintain. This allows continuous development and maintenance of individual microservices, in contrast to traditional monolithic or service oriented applications which must be developed and maintained in one piece.

Microservices are:

Technology Components

Unified Assurance uses the following components to implement microservices:

Docker

Docker is the platform for creating and running container images.

Using containers with microservices lets you easily manage and dynamically replace components. Containers contain the minimal viable pieces needed to accomplish a single goal, rather than packing multiple functions into the same virtual or physical machine.

In Unified Assurance, the Docker daemon runs on all internal presentation servers and all servers installed with Cluster roles.

Docker Registry

The Docker Registry is a stateless, highly scalable web server that stores and distributes Docker images within each Unified Assurance instance. Docker Registry runs as a standalone Docker container on each Unified Assurance internal presentation server. The Registry runs behind the Unified Assurance web server which acts as a reverse proxy and secures the Registry with TLS client certificate authentication. Docker images are pushed into the Registry when specific Unified Assurance image packages are installed and updated. Images are pulled down from each Docker daemon on behalf of a Kubernetes cluster.

Kubernetes

Kubernetes is a platform for managing containerized workloads and services. It facilitates both declarative configuration and automation. Kubernetes provides a framework to run distributed systems resiliently. It takes care of scaling and failover for your application, provides deployment patterns, and more.

Rancher Kubernetes Engine (RKE) is a CNCF-certified Kubernetes distribution that runs within Docker containers. It works on bare-metal and virtualized servers. RKE simplifies and automates Kubernetes installation and operation, independent of your operating system and platform.

Helm

Helm helps you manage Kubernetes applications. Helm is a package manager for Kubernetes that allows you to package, configure, and deploy applications and services onto Kubernetes clusters. Helm Charts help you define, install, and upgrade Kubernetes applications.

ChartMuseum

ChartMuseum is a stateless, highly scalable web server that stores and distributes Helm charts within each Unified Assurance instance. ChartMuseum runs as a standalone Docker container on each Unified Assurance internal presentation server. This chart repository runs behind the Unified Assurance web server which acts as a reverse proxy and secures the repository with TLS client certificate authentication. Helm charts are pushed into the repository when specific Unified Assurance image packages are installed and updated. Charts are pulled down from each Helm client for deployment into a Kubernetes cluster.

Unified Assurance Hyperscale Clusters

Unified Assurance runs stateless microservices for the collection and processing application tiers in Kubernetes clusters. Any existing Service Oriented Architecture (SOA) collection and processing application tiers exist outside of these clusters.

One or more clusters can exist for each Unified Assurance instance, but all servers of each cluster must reside in the same data center or availability zone.

The following image shows an example of redundant and non-redundant Kubernetes clusters, namespaces, and server roles.

Cluster and Namespace Examples

Description of illustration cluster-and-namespace-examples.png

Cluster Server Roles

Each cluster requires at least one primary server running the Kubernetes control plane and etcd stateful configuration stores. Production clusters should include at least three primaries. The Cluster.Master role provides the definition to deploy the Kubernetes primary applications on desired servers.

The Cluster.Worker role provides the definition to run any additional Kubernetes workloads. Sufficiently resourced servers can have both Cluster.Worker and Cluster.Master roles.

See Understanding Server Roles for more information about server roles.

Namespaces

Kubernetes supports multiple virtual clusters, called namespaces, backed by the same physical cluster. Unified Assurance has an opinionated view of namespaces, requiring certain naming conventions.

When you create a microservice cluster, the following namespaces are created automatically:

When you install Vision, you must also add the a1-vision namespace manually. See Vision Installation Overview for information about installing Vision.

See Microservice Cluster Setup in Unified Assurance Implementation Guide for more information about creating microservice clusters.

Monitoring

The health of the Kubernetes cluster components and the containers in each cluster are monitored from applications in the a1-monitoring namespace. Performance metrics are pulled and stored locally in each cluster. The metrics are moved to long term storage in the Unified Assurance Metric database. Metric KPIs collected not only provide analytics coupled with alerting thresholds, they can also be used by the Kubernetes Horizontal Pod Autoscaler to increase the number of replicas of Pod deployments dynamically as needed.

Pulsar Message Bus

Apache Pulsar is a multitenant, high-performance solution for server-to-server messaging. It provides very low publish latency and end-to-end latency and guarantees message delivery with persistent message storage. Pulsar provides the backbone for Unified Assurance microservice pipelines and runs in the a1-messaging namespace.

Microservice Pipelines

Microservices are simple, single-purpose applications or system components. They can work together in a pipeline to achieve a common goal through a lightweight communication mechanism, frequently a publish-subscribe messaging system. Publish-subscribe systems decouple communications so that producers do not know who subscribes, and consumers do not know who publishes. This system makes it easy to add new listeners or new publishers without disrupting existing processes.

Unified Assurance includes several microservice pipelines. See Understanding Microservice Pipelines for more information.

Control Plane High Availability and Redundancy

You can set up Kubernetes and its supporting components for high availability, so that there is no single point of failure.

A single primary cluster can easily fail, whereas a multi-primary cluster uses multiple primary nodes, each of which has access to the same worker nodes. In a single primary cluster, the important components, like the API server and controller manager, lie only on the single primary node, and if it fails you cannot create more services or pods. However, in a highly available Kubernetes environment, the important components are replicated on multiple primaries. If any of the primaries fail, the other primaries keep the cluster up and running.

Kubernetes nodes pool their resources to form a more powerful machine. When you deploy microservices onto the cluster, it intelligently handles distributing work to the individual nodes for you. If any nodes are added, removed, or failed, the cluster will shift work around as necessary.

Cross-Data Center Redundancy

Microservice redundancy ensures high availability for microservice-based applications across multiple separately managed Kubernetes clusters. This protects services from critical events, such as hardware, platform, or network failure and ensures no loss in functionality for the end-user.

At the cluster level, Kubernetes natively handles high availability in the event of node failures by mitigating the migration of application pods from one node to another within the same cluster. However, in event of partial or entire data center failure, another worker node assigned to that cluster may no longer be available for pod migration, and the application is unable to run.

To counter this problem, microservice redundancy provides a means for the workload of the application to be performed on an identical application running inside a pod on a completely different cluster. The secondary redundant cluster can be running on physical or virtual machines outside of the primary cluster's network, or even located in a different data center.

Kubernetes clusters are joined using Submariner to create a secure tunnel between the two clusters, allowing seamless communication between microservices and their redundant counterparts. By joining a cluster to the Submariner broker, a cluster gains service discovery capabilities for any Kubernetes service exported to the broker from another joined cluster.

In Unified Assurance, both the primary and secondary clusters are joined to the Submariner broker, which is deployed on the secondary cluster. An HTTP endpoint for each microservice running on the primary cluster can be exposed to its duplicate running on the secondary cluster. The secondary microservice can use the endpoint to perform a health check on the primary microservice.

In the event of a catastrophic failure in the primary cluster, the health check fails and, depending on user-defined thresholds, the microservice fails over to the secondary cluster. The secondary cluster takes on any ongoing and future work. When the primary cluster is restored and the health check is successful again, the microservice falls back to the primary cluster and the system returns to normal.

Microservice Cross-Data Center Redundancy

Description of illustration microservice-cross-data-center-redundancy.png

Submariner

Submariner provides service discovery and OSI Layer 3 communication across clusters using either encrypted or unencrypted connections. It facilitates geo-redundancy, scaling, and fault isolation for applications that can span across multiple data centers, regions, and networks.

Microservice Autoscaling

A classical monolithic application runs on a host operating system and uses a physical machine's resources for its components and other applications. Scaling often requires redesign, splitting components manually, managing different physical machines, observing the system using monitoring tools, and making scaling decisions by a person or a team.

With microservices, you can scale applications more automatically. Physical machines are part of a resource pool controlled by Kubernetes and each component is a small composable unit of work which can be scaled seamlessly. Each work unit gathers operational metrics on the unit's performance, efficiency, and resource use, and these metrics can be collected and exposed in a standardized way using Prometheus.

Kubernetes Event-driven Autoscaling (KEDA) uses metrics like web traffic, messaging queue throughput, network bandwidth, and system resource use, to provide scaling decisions for Kubernetes. If the application has been running slowly, becomes unresponsive, or cannot keep up with its nominal operation, Kubernetes assigns more work units to keep the application running optimally. When the additional work is no longer required, Kubernetes scales back the work units to keep resource use optimal and efficient.

By combining autoscaling, high availability, and redundancy, you can prevent unresponsive systems, lost data, and service outages. Some part of system will be available and responsive at all times.

The following image shows an example of the interaction between KEDA, Prometheus, the pod autoscaler, and the microservice pods and metrics.

Microservice Auto-scaling

Description of illustration microservice-auto-scaling.png

KEDA

KEDA is a single-purpose and lightweight component that runs in each cluster. KEDA works alongside standard Kubernetes components and can extend functionality without overwriting or duplication. With KEDA you can choose which applications use event-driven scaling, which makes KEDA a flexible and safe option to run alongside any number of any other Kubernetes applications or frameworks.

KEDA exposes rich event data like queue length or stream lag to the Horizontal Pod Autoscaler (HPA) to drive scale out. It defines the formulas and thresholds that can be customized to configure the scale of those deployment replicas.

KEDA is automatically deployed as a microservice in the a1-monitoring namespace when you create a cluster.

Prometheus

Prometheus is an open-source systems monitoring and alerting toolkit that scrapes metrics from instrumented jobs, either directly or from an intermediary push gateway for short-lived jobs. It exports all scraped samples to a metric database and can run rules to either aggregate and record new time series from existing data or generate alerts. Grafana or other API consumers can be used to visualize the collected data.

The Prometheus stack is automatically deployed as a microservice in the a1-monitoring namespace when you create a cluster.

Deploying and Managing Microservices

You can deploy and manage microservices using the Unified Assurance user interface or the command line. Before you can deploy microservices, you must set up a Kubernetes cluster.

See Microservice Cluster Setup and Managing Microservices in Unified Assurance Implementation Guide for more information.