- What is Digital Transformation
- Containers
- Can we talk about data?
- Cloud Migration Process
- Step 1: Establish the migration-architect role
- Step 2: Choose your level of cloud integration
- Step 3: Choose to go Single or Multi-Cloud
- Step 4: Establish cloud KPIs
- Step 5: Establish performance baselines
- Step 6: Prioritize migration components
- Step 7: Perform any necessary refactoring
- Step 8: Create a data-migration plan
- Step 9: Switch over production
- Step 10: Review application resource allocation
Step 8: Create a data-migration plan
A thoughtful, incremental approach to adopting microservices can have a significant impact on the success of a microservices architecture. In this chapter, we’ll discuss one such incremental approach.
A Resilient Microservice
We’ll start with deploying a single, resilient microservice that is connected to the monolith. Why resilience?
-
A new microservice should not impact the availability of the overall service. For example, a monolith-based service that has 99.99% availability would have 99.98% availability (99.992%) when an additional microservice is added unless resilience is designed into the architecture.
-
Developers need to be able to iterate and deploy the microservice independently of the monolith. A resilient microservice insures that the impact of any microservice changes are isolated from the monolith.
The Microwizard
We’ve created a simple project, the Microwizard, which illustrates adding a single resilient microservice to an existing monolith. The Microwizard is set up as a Vagrant VM.
The Microwizard is a Getting Started tool for developers with no experience with microservice architectures who want to learn more about them. It lets you get your feet wet and see some of the benefits of microservices by starting with a common adoption pattern: adding a single microservice to an existing monolith (as the first step in migrating from a monolith to a microservices architecture). This enables more rapid feature development of the new service without any possibility of unintentionally inducing bugs into the existing code.
By default, Microwizard ships with and uses an existing Ruby on Rails application named Lobsters as the demonstration monolith. We will walk you through how to add new functionality to the main Lobsters application by creating a microservice in Python (you do not need to know Python to understand this example).
The Microwizard uses the following simplified technology stack:
The Microwizard uses both Ruby on Rails (for the monolith) and Python/Flask (for the microservice). Baker Street is used for the services layer. Baker Street provides a resilient service discovery and routing framework over HTTP, and connects the different services in the Microwizard. The monolith, popularity microservice, and database are all deployed in individual Docker containers.
The Microwizard simplifies a few components of the technology stack in the interest of simplicity, as noted above. It’s deployed on a single Vagrant virtual machine. It also does not deploy a resource management framework such as Kubernetes or Docker Swarm. Both of these issues would need to be addressed in a production architecture.