Microservice architectures promise benefits such as faster delivery, independent scalability, and resilience but also present several challenges. Determining the granularity of microservices is often a hot topic among enterprise architecture teams.

While microservice purists might argue for truly “micro” contexts with 100s or even 1000s of services, most companies benefit from more coarse-grained service organizations. Key to this decision is determining the proper boundaries for your organization. What’s even more challenging is that there is not just one type of boundary to consider; there are 3:

1. Logical Service Boundary—This boundary concerns business capabilities and a purposeful domain. It is the typical boundary that most focus on when thinking about microservices. It is initially one of the most challenging pieces to get right as it is highly dependent on your business and team. Considerations for this boundary include bounded contexts, domain and functionality definitions, and team composition and expertise.
2. Code Development Boundary is primarily an organizational boundary defining how a team should work with source code. This becomes increasingly relevant as codebases grow to support large enterprise applications. The typical decision factor typically revolves around a mono-repo vs a poly-repo setup. For example, should you store or separate all your code in a single source repository (e.g., GitHub Repo)? Each has its strengths and weaknesses with typical considerations, including managing dependencies and shared libraries, CI/CD workflows and pipelines, and developer setup and onboarding efficiency. Luckily, this boundary tends to have a lower “switching cost” and is more amenable to change than the “Logical Service Boundary.”
3. Deployment Boundary - not many consider this a separate boundary because, in most people’s view, there is a one-to-one relationship between a “Logical Service Boundary,” the “Code Development Boundary,” and how it is deployed - in a lot of cases, if you are designing your microservices from the ground up, this will likely be the case. Decoupling these concerns surfaces some essential benefits, mainly cost savings, easier infrastructure maintenance, and future flexibility. Our approach to addressing these concerns will be outlined in more detail below.

At Broadleaf, these challenges and boundary concerns are magnified as our goal is to provide an extensible microservices framework for enterprise commerce that can support the needs and opinions of many organizations. Our architecture team faced a vital issue: the proper boundaries for one company might need to be more relevant or ideal for another. For example, in one solution, a few more minor services may make sense in the same deployment, while in another, they need to be separated. The wrong choice on any of the boundaries can significantly impact the overall costs and benefits of using microservices.

One of Broadleaf's core products includes a set of headless enterprise commerce microservices built using Java and the Spring Framework. Thinking about how to deal with these three boundaries was at the top of my mind.

Logical Service Boundary—The Broadleaf Platform was developed with years of experience in a reasonably well-traveled domain (e.g. eCommerce Architecture), resulting in logical service boundaries like Cart, Customer, Catalog, Pricing, Inventory, Order, etc.… making this delineation reasonably straightforward.

Code and Deployment Boundaries—We wanted to provide the most flexibility with these boundaries. Given the needs and opinions of many large organizations on best handling microservices, one of our primary objectives was to provide a solution that supports differentiated options and use cases.

These challenges led to a critical component of Broadleaf’s Microservices Accelerator Framework that we refer to as Flex Packages.

Broadleaf's Flex Package technology is a unique deployment configuration and packaging concept that allows multiple microservices to exist in a single JVM runtime under a Spring application context (effectively functioning as an individual Spring Boot application). This technology is designed to maximize the flexibility of deployment options for those microservices. For example, Broadleaf provides three compositions to help illustrate and understand the various possibilities. Note that Broadleaf Flex Packages are not the only options you can achieve, as they can be constructed in any combination (you can even add your services to the mix) to support your own eCommerce platform needs.

One (or the Single Deployment Footprint)

This option represents a highly coupled service deployment footprint consisting of the full Broadleaf microservices stack. This composition has the advantage of having a simple and lower hardware footprint. If you think this sounds like a “monolith,” it is! This option does not get all of the benefits of microservices, such as independent scalability or having each service operate in its maintenance cycle. However, this option is an excellent option for local development, allowing you to experience the whole ecosystem without having to incur the overhead of running a ton of containers (all running their own JVMs)

Granular 

The Low Coupled Service Deployment. This option allows each service to be deployed independently in its container. This is the “typical picture” most people have when they think about microservices. This option allows for maximum scalability and flexibility of each service and its lifecycle. However, this option also requires more infrastructure, CI/CD boundary considerations, management overhead, and complexity.

Balanced

The Balanced Service Deployment. This is our initial recommended deployment footprint for most enterprise use cases. The services are broken down into four primary flex packages that make the most sense from a commerce perspective and represent a good balance of service composition based on typical use cases: browse, cart, supporting, and processing. Broadleaf commerce microservices are broken down into different composable “flex packages” that facilitate a consumer storefront experience, a transactional heavy deployment, a deployment focused on longer-running background tasks, and a supporting service deployment that underpins the others in the ecosystem. This option leverages read and process replicas and allows for each flex package's independent scaling and lifecycle management. This option also uses a message interlink to ensure data consistency and avoid data staleness across flex packages.

Broadleaf's Flex Package technology is best for the advanced needs of enterprise composable commerce applications. With the following benefits:

• You can adapt your footprint to meet your culture or team needs. For example, some teams may wish to combine concerns in a single deployment if those teams control multiple concerns and want to improve team efficiency.
• You can adapt your deployments to fit your budget. You can scale your cloud footprint up or down as needed, depending on the demands and performance required from your Flex Packages, or adapt to seasonal swings in your business.
• You can adapt your deployments to meet developer needs. For example, if developers wish to experience the entire ecosystem on a local machine without the overhead of running dozens of separate services
• You do not have to refactor your project to use Flex Packaging. Switching composition is just a matter of updating a single manifest configuration file. Many clients utilize this technology to run the entire ecosystem locally on a developer machine using the “one” composition but then deploy the same codebase to higher environments using the “balanced” or “granular” composition.
• Finally, it helps simplify microservice adoption. For organizations new to Microservices, it allows the engineering team to build more granular services without worrying as much about the deployment characteristics, which can be determined later. This removes one of the blockers that can plague architecture teams as they debate design.

One of the key benefits of using Microservices is the ability to scale and deploy services independently, allowing for greater flexibility and agility in development. This means that teams can work on different services simultaneously without being held back by dependencies on other components. With Flex Package technology, you have the ability to keep these isolated project teams so that developers can focus on delivering valuable business capabilities and move packaging and actual deployment concerns to solution architects and the operations teams.

With that said, it is still important to consider the increased complexity of managing a larger number of services. Monitoring, debugging, and testing can become more challenging as the number of services grows. It is crucial to have a solid DevOps strategy in place to effectively manage and maintain the overall eCommerce solution running on a Microservices architecture. Broadleaf’s Microservices Accelerator framework provides several levels of tooling, patterns, and recommendations to help tame this complexity, with Flex Packaging being one of the core components.

While there are challenges associated with adopting Microservices, the benefits of increased flexibility, scalability, and fault isolation make it a valuable architectural pattern for organizations looking to modernize their software development practices. By carefully considering the design of your Microservices, keeping the three boundaries in mind, and implementing best practices, you can harness the power of this architecture to drive innovation and efficiency within your organization.