Migrating to microservices starts by first defining your Domains. Organizing your reusable components and services into a Domain Driven Design is key to a successful implementation of a service-based architecture. Because it is so key, it should be the first step you take in your modern architecture journey. This is often called Domain Driven Design (DDD). The good news is that you can start the process by looking at your current monolithic application in terms of components and Domains. From that perspective you can slowly and successfully see what migrating to microservices will look like. DeployHub supports a Domain catalog that helps you build out your Domains for component sharing and reuse. It facilitates migrating to microservices by helping you visualize your common services and defining a location for publishing and sharing. Domains are critical when you begin to decompose functions into independently deployable services. They allow you to catalog similar microservices together, making it easier for other developers to find and share them.
To understand this first step when you migrate to microservices, let’s break down a monolithic into components. If we take a simple web store application, you may have a .jar file, the database, the infrastructure components and environment variable settings. While the .jar file may be your primary focus, you need to start seeing the database, infrastructure and environment variables as independent components of your overall application. You can build a strategy for managing each of these layers as individual services. DeployHub does this using Domains. Domains track, catalog and expose reusable components allowing them to be easily shared, a critical step in the shift to microservices. Domains are managed using DeployHub’s back end versioning engine. This is not suggesting that all microservices of the same Domain are installed in the same container. Each microservice remains independent and in its own container. DeployHub tracks the logical Domains so all microservices of a similar type can be more easily cataloged, referenced and tracked.
Your monolithic Domains may include:
· Infrastructure Components (java runtime, Tomcat, Environment. Variables)
· Database and SQL (.sql)
· The Website (.jar)
To visualize this, we can use a triangle that shows the lowest to highest level of dependencies. This is a simple organizational method that can be useful for our more complex service-based architectures.
With DeployHub, these Domains are controlled by different User Groups and can contain lower level Sub-Domains. For example, Operation Teams may control the Infrastructure Domain, DBAs the middle tier and developers control the website frontend. As you break down your application into services, you will expand on these Domains. Starting at this monolithic level helps you begin thinking ‘functions’ and prepares you for the next step.
Migrate to Microservices with Domains
One of the first steps to migrate to microservices is to take an application and break it down into its smaller parts, or Domains. We then organize these parts in a fashion that will allow reuse.
If we think about the potential microservices for a simple store website, we’ll have:
• the website front-end,
• a cart,
• credit card processing,
• a check out system,
• advertisements and recommendations,
We can show who to migrate to microservices and decompose our monolithic by representing it in a simple triangle. We start by expanding the triangle into specific sections, the most commonly reused at the bottom, and team specific at the top. Think about what’s most common. Like our monolithic, the lowest level is infrastructure and database. In our service-based architecture, these are followed by credit card processing and the login/sign up. Above that, we may have the cart and on top of that are the more specific pieces such as the ads and recommendations. At the peak of the triangle is the front-end. While this seems like a simple exercise, it allows you to begin to see the patterns in all applications across the organization. The lower level sections should be reused.
This triangle shows how we build up from the most common pieces and represents how we would define Domains. Each section of our triangle becomes a Domain.
Domains and Sharing
Say we have another team that’s writing a store website, Website B. With DeployHub they find common pieces based on the Domains. Once you define your Domains, your developers can begin publishing and deploying microservices under the Domain structure making it possible for other teams to easily find and then reuse the services. When our next team creates a new store, they begin the process of re-use.
Between Website A and B we have accomplished a level of reuse for all the shareable layers from the infrastructure to the cart. This allows us to write the login, sign up, the cart, and the credit card processing once. DeployHub facilitates this level of design by supporting a highly customizable Domain structure allowing you to migrate to microservices by defining your triangle into a catalog. The domains catalog make it easy to find and share the microservices.
The OOPS in Object-Oriented Programming – Let’s Not Repeat that Mistake
Object Oriented Programming (OOPS) attempted to achieve a similar level of reuse. Part of the problem of OOPS was the inability for teams to accurately run builds where linking was carefully managed from a central ‘common’ location. To solve this problem, developers would add the ‘common’ object, like our login service, to their local repository so the build could use it. Their build would always reference that version of the library. Updates to the library would be private. There would be little, if any, contribution of updates to the ‘common’ version. This mistake could be easily repeated in microservices. That would be unfortunate and represent a failure in the implementation of a service-based architecture.
The question always is ‘how backward compatible is the new versions?’ Are we breaking any signatures on the methods? If we’re not breaking any of the interfaces, then can we consume those latest versions? And which application is consuming what version of a service?
For example, website B is going to use v2 of the login and website A will use v3. We need to track which Website is using which version. If you want to deprecate v2, it will require Website B move to v3. What is needed is a method for impact analysis to accurately make these types of decisions. This tracking ability is key to a successful microservice implementation and part of DeployHub’s Domain dependency management features. DeployHub provides this level of tracking, versioning and reporting to make every microservice deployment successful and visible for high frequency updates.
- A Microservice Service Catalog for Incident Response
- Domain Driven Design Catalog to Tame Microservice Sprawl
- Microservice Architecture and Your Logical Application
- Microservice Configuration Management
- Continuous Deployment and DevOps at Scale
- Register for DeployHub Team
- Reverse Proxy Setup for SaaS Deployments
- DeployHub Team User Guide
- The Hipster Store Tutorial
Ortelius Open Source Project
All Blogs on Kubernetes Microservices
- How to Navigate the Deathstar
- Microservice Continuous Integration – Where’s the Build?
- Working with Helm for your Microservices Releases
- On Versioning your Container Content
- How to Use a Domain Driven Design
- Versioning Applications
- Why we need Application Packages for CD
- Version Jumps and Tracking
- How are Microservices and Applications Related?
- Migrate to Microservices with a Domain Driven Design