Broadleaf Microservices

Deployment Flexibility

Overview

Broadleaf services are designed to maximum flexibility with how they are deployed. The two extremes of this help to give an understanding of the possibilities.

Example 1: High Coupling Service Deployment

One extreme would be to deploy all of the microservices together in a single container as shown in the diagram below. This option has the advantage of being simple and can be significantly lower hardware costs for some installations.

This type of deployment does not get all of the benefits of microservices such as independent scalability or being able to have each service operate in its own maintenance cycle. Because they share the same spring boot application, services deployed together must be able to operate with the same library dependencies.

Generally, this model is good for non-production environments and for clients with lower volume infrastructures. As it is easy to split services out of this model, this is also a good way to get going quickly with the ability to move services out in an incremental way.

High Coupling Deployment Diagram

Example 2: Low Coupling Service Deployment

The other extreme option for deploying microservices is to separate each service into its own deployment as illustrated below. This option allows for each service to be independently scaled and to have its own lifecycle. Some services will be very stable and only upgraded occasionally while others may be under heavy development with more frequent deployments.

Low Coupling Deployment Diagram

How should the services be deployed?

The high coupling approach is appropriate for companies new to complex dev-ops and cloud deployments and for companies that do not have complex, high volume sites.

For most, the best deployment will be in between these two extremes. Considerations should be based on the rate of change of the service, volume of calls to the service, the other systems involved, and other company architecture standards.

Broadleaf can provide assistance with the best architecture based on the requirements of a specific implementation.

Cloud Database

It is important to know that each service has its own database. This could be a separate cloud database per service or a separate schema within a shared cloud database.

Most companies will utilize one (or a few) cloud database with each service configured to a separate schema.

An advantage of the Broadleaf approach is that you can easily move a schema to its own DB or combine schemas into a single DB as you evaluate the usage patterns of your applications.

With some cloud providers, the number of connections required can be very high when each microservice needs its own connection pool. Broadleaf has solved this problem by allowing for services running in the same container that also talk to the same Cloud DB to use the same connection pool in a way that switches the schema between calls.

On-Premise or Cloud

Broadleaf runs on open source technologies and containers and as such can be run in most cloud infrastructures. Broadleaf can also be run in private data centers for customers that require more control of the infrastructure.

Broadleaf has been deployed in AWS, Azure, Alibaba, and Google Cloud.