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 Light. Some of them are built 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 dramatically these days.

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.

oauth-kafka is our enterprise OAuth 2.0 provider built on top of light-kafka and kafka streams for event sourcing and CQRS. It is scalable and integrated with light-portal. The light-oauth2 will still be available for users who want to put everything together on a desktop or a laptop. The API interface is the same and the serviceIds are slightly different. This component is available for enterprise customers and subscription services will be available from light-portal site.

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

light-controller is a standard edition of global registry and discovery service with runtime monitoring.

light-scheduler is an distributed schedueler based on Kafka and Kafka Streams for cloud applications.

light-router is a proxy service that can help an external or a legacy client 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.

http-sidecar is a service mesh sidecar to address cross-cutting concerns for both incoming and outgoing traffic for a backend API in the same pod.

kafka-sidecar is a service mesh sidecar to address cross-cutting concerns for backend API to interact with Kafka.

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.

COVID-19

This is an open-source application that enables the local community to help each other get through the COVID-19 pandemic. Why do I build this app Usage Guide Design Consideration Application Roadmap Read More »

Light Portal

Light-portal is a set of services for consumer and provider runtime management and marketplace to bridge the gap between consumers and providers. When you build microservices on a 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-source projects on github.com and could not find any existing product that meets our requirement, so we decided 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. Light services also 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 Mesh

Several sidecars in the light-mesh project can be used as a sidecar container in a Kubernetes pod along with your API built with any frameworks or languages to address cross-cutting concerns. With most of the cross-cutting concerns addressed, your developers can focus on the business logic only in the backend API. What Is a Sidecar Pattern Segregating the functionalities of an application into a separate process can be viewed as a Sidecar pattern. 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 clients who cannot leverage our client module, we have provided the light-router, which moves the client modules on the network to allow the original client to consume services 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 decisions on how to communicate between service to service, chances are you want to use the event-driven approach instead of the request/response approach. It gives you flexibility, reliability, and scalability. To leverage the full potential of Light, 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 clients 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 the 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 needs to be built into the log from each service. Read More »

Light OAuth2

Light follows a 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 focus on the perimeter and don’t have solutions for 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. The light-oauth2 consists of 7 microservices that can be deployed in one cluster with multiple instances of token and code services and one instance of other services. 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 is 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 look at the dashboard in a reactive mode, and need the monitor system to issue alterations if something abnormal happens. Read More »

Config Server

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

Tokenization

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

Light Controller

When deploying large-scale microservices to the cloud environment in a zero-trust network, the traditional pull from each service to check if it is healthy is not feasible. Instead, we need each service instance to register the IP and Port to the Portal Controller service through API calls during the server startup and de-register during the server shutdown. It requires the API framework to have a component that is responsible for registering and de-registering. Read More »

HTTP Sidecar

There are two ways to implement a complete distributed microservices application with Light in a Kubernetes cluster: Embedded and Sidecar. If you use Java 8 or Java 11 to implement your service, you can leverage one of the Light frameworks with cross-cutting concerns embedded in the request/response chain. The other option is to use the HTTP Sidecar container in the same pod to address the cross-cutting concerns at the network level. Read More »

Light Scheduler

In any enterprise with distributed cloud applications, task scheduling is a key requirement. A high available and fault-tolerant task scheduler will help to build robust cloud applications to meet business goals. Traditional task schedulers like Quartz using a database for task definition store, and it is hard to scale the services horizontally. By using Kafka, Kafka Streams and State Store, the scheduler can be scaled easily. Design Task definition commands will be pushed to input topic (light-scheduler by default) with multiple partitions when a REST endpoint is called. Read More »

Kafka Sidecar

The Kafka sidecar is designed to address the following concerns for distributed microservices to leverage asynchronous event-based communications instead of synchronous request/response over HTTP. Hide the complicity of Kafka client Unlike traditional server-heavy messaging systems, Kafka’s server is just a set of appended logs; however, the Kafka client is much more complicated. It is not an easy task to build a producer or consumer in microservices within a multi-threaded context. Read More »

OAuth Kafka

While working on the light-portal to provide subscription services to small and medium-sized customers, we realized that the light-oauth2 is not very suitable for the internet scale. First, it is based on a SQL database that is not scaling very well. All though we have a cache layer to share data between different microservices, it is not very friendly with Docker and Kubernetes. Our OAuth 2.0 provider has a lot of extra features to support microservices deployment. Read More »

Light Reference

Reference API is a microservice designed to populate UI dropdown lists in real-time with relationship support. Try the link for a demo with react-schema-form. https://maproot.net/#/app/form/covidMapForm In the above form, you have to select a country before the province is populated from the reference API. Once a province is select, the cities in the province will be populated in real-time. The category and subcategory have a similar relationship. With the high-performance implementation, we can support loading the reference data from the browser when users are updating one field in the form. 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 Light; 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 »