Migration from Monolithic Application to Microservices — Part 1: Introduction

The following blog is based on thesis of the writer.

In this blog, we’re going to explore microservices and the migration process from monolithic application to microservices.

Part 1: Introduction, theoretical framework of microservices

Part 2: Docker and Kubernetes

Part 3: Implementation Framework — Service Domain and Strangler Pattern

Part 4: Hands-on—Implementation of Stranger Pattern

Problem

Microservices has been an advanced architecture pattern for years and been proven to be a preferable choice for enterprise to develop software.

• 84% of organizations have embraced microservices architecture to accelerate innovation efforts and stay competitive (Kong 2020).
• Many companies such as Amazon, Google, Zalando or Spotify (Kwiecień 2019) are adapting microservices in their system to stay competitive and innovative.

Although the benefits of microservices over monolithic application are clear, organizations still struggle to migrate into microservice from their legacy monolithic architecture due to the complexity of the process. 32% of organizations admit that difficulty integrating with monolithic legacy apps remains a challenge for their microservices adoption (Kong 2020).

The following work is to approach this problem to make the transition simpler, along with maintaining system performance and avoiding unexpected downtime and risks during the migration process.

Microservices Architecture

Microservices is a system architecture for an application as a collection of services. Newman (2018, Chapter 1) defines microservices as small, autonomous services that work together.

Microservices — small, autonomous services that work together.

Different from monolithic architecture where one single application handles all business purposes and is responsible for all requests, microservices separate it into smaller applications that modeled around a given domain. Each application works independently for their domain and runs on separate environment.

However, if the requests need multiple services from different domains to finish the job, microservices can communicate with each other. Therefore, microservices can be referred to as “… a microservice architecture is based on multiple collaborating microservices” (Newman, Sam 2019).

Figure 1. Monolithic Architecture and Microservices Architecture (adapted from Arsov 2017)

Factors of Microservices

Interdependence

Codebases grow every day as developers add new features. Over time, it is difficult to know where changes should be made to keep the code clean and not repeat itself. Therefore, developers find it hard to fix bugs or implement them. In monolithic world, companies overcome this challenge by ensuring cohesiveness within the code by abstractions and modules (Newman 2018).

Microservices take a similar approach for each service: gathering codes under the umbrella of a domain where code lives for an “end-to-end slices of business functionality” (Newman 2019). However, microservices take a step further from modules as these services lay on top of an isolated machine, i.e. container (will explain later in the document), and model around a domain. As such, each service acts as a separate entity, having independent deployability.

For services in microservices, it is important to consider domain boundaries that service covers to maintain its interdependence. A rule of thumb is that service domain should not be too big or too small. If it is small, it will not cover enough functionality needed. Hence, one has to make changes across a process boundary for two separate services, which is against independent deployability of microservices. On the other hand, microservices should not be too big as it can return to monolithic architecture. The downside of this approach is that one finds it hard to make changes as it might affect other features in the service. In general, domain is considered to keep microservices size in good balance, so it has to be well-discussed to create services that are well covered and maintainable.

While each service has to separate into its environment, each service can communicate using an application programming interface (API). Each service has its internal Internet Protocol (IP) address within the network, which exposes APIs for other services to communicate back and forth. (Bruce & Pereira 2019.)

Owning their own data

Owning to its interdependency, microservices should not share database. If one service needs to access data held by another service, it should go and ask that service for the data. (Newman 2019). Werner Vogels, Amazon CTO, also refers to database separation as service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and no data is sharing among the services. (AcmQueue 2020.)

By encapsulating databases within a service contributes, one can make changes without worrying about compatibility, adding velocity to development and deployment (Newman 2019). For example, if two services User and Order have a shared database and a developer wants to change schema of User table, he or she has to ensure that the change is compatible with Order service

By encapsulating databases within a service contributes, one can make changes without worrying about compatibility, adding velocity to development and deployment.

Managed by independent and dynamic team

Before discussing about the topic, it is important to recall Conway’s law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure

Therefore, in order to develop interdependent services, teams are required to become more agile — “more independent, autonomous teams, able to be responsible for more of the end-to-end delivery cycle than ever before” (Newman 2019). In fact, each team is independently working on one service while maintaining communication with other teams.

The shift is from “traditionally grouping people in terms of their core competency” to “poly-skilled teams, to reduce hand-offs and silos” (Newman 2019). Figure 2 illustrates an example of team shifting within an organization.

Figure 2. Reassign responsibilities in organizations (adapted from Newman 2019)

As each service and team is independent of others, each team can focus on building features without worrying about affecting codes of other teams, which helps teams to move fast. Werner Vogels, Amazon CTO, shares his experience in building Amazon as the giant, monolithic “bookstore” application and giant database that we used to power Amazon.com limited our speed and agility. Whenever we wanted to add a new feature or product for our customers, like video streaming, we had to edit and rewrite vast amounts of code on an application that we’d designed specifically for our first product — the bookstore. This was a long, unwieldy process requiring complicated coordination, and it limited our ability to innovate fast and at scale. (Vogels 2018.)

Implementation

To wrap up this long blog, we can try on creating microservices in GKE — a managed, production-ready environment for running containerized applications, which is a platform where we can deploy our microservices on. Theses steps follow tutorial from Google Cloud

1. Login to GCP Console with Google credentials and create a project.
2. Enable Kubernetes API

• Visit the Kubernetes Engine page in the Google Cloud Console.
• Create or select a project.
• Wait for the API and related services to be enabled. This can take several minutes.
• Make sure that billing is enabled for your Google Cloud project. Learn how to confirm billing is enabled for your project.

3. Use Cloud shell to create a cluster for your application

• Set your project ID and Compute Engine zone options for the gcloud tool:

gcloud config set project $PROJECT_ID
gcloud config set compute/zone compute-zone

• Create a two-node cluster named migration-microservices:

gcloud container clusters create migration-microservices --num-nodes=2

• After the command completes, run the following command to see the cluster’s two worker VM instances:

gcloud compute instances list

Remember to turn off your cluster when not in used!

gcloud container clusters resize migration-microservices --num-nodes=0

Congratulations, you have successfully created environment to run for your microservices! Stay tuned for the next part to explore further on the journey of microservices and its migration process. :)

References

AcmQueue 2020. A Conversation with Werner Vogels. URL:https://queue.acm.org/detail.cfm?id=1142065. Accessed: 20 March 2019.

Arsov, K. 2017. What Are Microservices, Actually?. URL: https://dzone.com/articles/what-are-microservices-actually. Accessed: 3 February 2020.

Kong, 2020. 2020 Digital Innovation Benchmark. URL: https://konghq.com/resources/digital-innovation-benchmark2020/?utm_source=pressrelease&utm_medium=referral&utm_campaign=2020innovation-report. Accessed: 15 May 2020.

Kwiecień, A. 2019. 10 companies that implemented the microservice architecture and paved the way for others. URL: https://divante.com/blog/10-companies-that-implemented-the-microservice-architecture-and-paved-the-way-for-others/. Accessed: 15 May 2020.

Newman, S. 2018. Building microservices. Sebastopol: O’Reilly Media, INC, USA.

Newman, S. 2019. Monolith to Microservices. 1 edn. Sebastopol: O’Reilly Media.

Vogels, W. 2018. Modern applications at AWS. URL: https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html. Accessed: 20 March 2019.