Service Overview

For organizations that are planning to migrate an existing monolithic application to microservices, the upfront infrastructure investment is very significant. Some essential services must be implemented before deploying a large number of services.

Usually, you can start building several services and deploy them to your existing data center; however, once you have a dozen services running with multiple instances, you will need supporting services for security, tracing, monitoring, metrics, etc.

The following are some of the important services recommended by the Light platform. Some of them are built by ourselves as existing products on the market cannot meet our requirement with microservices in the cloud. For example, light-oauth2 and light-portal. Other services are our picks of industry leaders, and the list is changing as the landscape of cloud-native computing is changing these days dramatically.

light-oauth2 is our security service built on top of light-rest-4j to protect services accessed by the unauthorized client. It has a unique feature to facilitate the service to service communication with two tokens.

light-portal is an API runtime management and marketplace. In the service mesh context, it is the control plane.

light-router is a proxy service that can help an external or a legacy client to access cloud-native microservices by encapsulating consumer side cross-cutting concerns into a microservice as a distributed gateway.

light-proxy is a proxy service that can bring legacy REST API to the Light ecosystem by encapsulating all provider side cross-cutting concerns into a microservice as a distributed gateway.

Messaging service is provided by Apache Kafka for high throughput and high availability.

Logging is provided by ELK stack for centralized logging

Metrics is provided by InfluxDB or Prometheus with Grafana as front-end.

Tracing is provided by OpenTracing and Jaeger Tracer and SkyWalking is working in process.

Light Portal

A service for consumer and provider runtime management and marketplace to bridge between consumers and providers. When you build microservices in large scale on top of light-4j and related frameworks, you need a portal service to manage the entire life-cycle of your services and to provide a marketplace for bridging API consumers and API providers. We have explored the open sources projects on github.com and could not find any existing product that meets our requirement, so we decide to build it on top of the light-4j framework. Read More »

Light Proxy

All the services developed on top of Light-4J frameworks support client side service discovery, load balance, and cluster natively. So there is no need to put a reverse proxy instance in front of our services like other API frameworks that support only server side service discovery. Also, light services embed a distributed gateway to address all the cross-cutting concerns in the request/response chain and work with the ecosystem that consists: Read More »

Light Router

All the services developed on top of light*4j frameworks support client side service discovery, load balance and cluster natively. However, for some of the client that cannot leverage our client modules, we have provided light-router which moves the client modules on the network to allow the original client to consume service as it is today without considering how dynamic these services are in the cloud. Another usage for the light-router is to act as a BFF(backend for frontend) for Single Page Applications or Mobile Native Applications. Read More »

Messaging Infrastructure

When you make architecture decision on how to communicate between service to service, chances are you want to use the event-driven approach instead of request/response approach. It gives you the flexibility, reliability, and scalability. To leverage the full potential of the light platform, you should use different frameworks for different services. Some of the services serve the application API calls from SPA and mobile applications, then these services will be built on top of light-rest-4j, light-graphql-4j or light-hybrid-4j to serve client synchronously. Read More »

Centralized Logging

Logging is very important for large-scale enterprise applications as it is crucial for the support team to figure out what has happened if something is wrong with the application. Once we move from the monolithic architecture to microservices architecture, logging becomes more complicated as we cannot allow support team to go to dozens or hundreds VMs or Docker containers to check the log in order to diagnose issues. A centralized logging is a must and some sort of tracing and correlating need to be built into the log from each service. Read More »

Light OAuth2

The light platform follows security first design. Given the complexity of microservices architecture, there is no existing OAuth 2.0 provider on the market that is suitable for microservices. Most commercial products are focusing on the perimeter, and they don’t have solutions for the service to service communication inside the corporate network. This is the reason we have provided an OAuth 2.0 provider light-oauth2 which is based on light-4j and light-rest-4j frameworks. Read More »

Metrics and Alerts

Proper monitoring is one of the most important parts of building a production-ready microservice and guarantees higher microservice availability. In this section, microservice monitoring are covered, including which key metrics to monitor, how to log key metrics, building dashboards that display key metrics. Another part of production monitoring is alerts. We cannot let support guys looking at the dashboard in a reactive mode but need the monitor system to issue alter is something abnormal happens. Read More »

Config Server

Services built on the light platform are composed with many plugins as part of the embedded gateway, and each plugin(or middleware handler) has its configuration file to control if they are enabled and the runtime behavior. Developers usually are don’t need to worry about these config files as these can be added later on by operation team. Unlike other application frameworks, we are not using a single config file but multiple config files as each service decides which plugins should be utilized and how they are utilized. Read More »

Tokenization

When working with microservices, the chances are that sensitive data need to be passed through several services before reaching the target service. For example, credit card number is collected in the shopping cart service and needs to pass through order service to reach the payment service. To make your application PCI compliant, the credit card number should be encrypted or tokenized at the shopping cart service and only payment service can decrypt or detokenize it. Read More »

Tracing

Traditionally, most applications have been developed as monolithic. Monolithics are compiled and packaged into a single deliverable and deployed as a single unit. That single unit contains thousands or even millions of lines of code. This method of software delivery has been eclipsed in the last several years by microservice architecture. An application can consist of dozens or hundreds of microservices which can be developed and deployed independently. Each microservice performs one essential function of the application, and nothing more. Read More »

Elasticsearch

To be completed. Read More »

Grafana

To be completed. Read More »

Redhat Openshift

To be completed. Read More »

Kubernetes

To be completed. Read More »

Prometheus

To be completed. Read More »

Influx DB

To be completed. Read More »

Consul

There are numeric options for service registry and discovery in the light platform; however, Consul is the most important one as almost all our customers are using it. For development purpose, you can use Docker to start a single instance Consul server. The command line can be found in the discovery tutorial. For production, the deployment is more complicated. If you have multiple data centers, you’d better use the enterprise edition and let HashiCorp install it. Read More »