Upgrading from a monolithic architecture to microservices is essentially to continually replace parts of the old application with new microservices. While this section talks about upgrading a monolith, it can also be taken as a planning step for an entirely new application. You will see how to conceptually upgrade a monolith to microservices; there is no code mentioned at this point because you will see this in much more depth later in this book. You should, however, see the concept underneath after reading this section.

They may not fit your specific application but are generally widespread among monolithic applications. This approach is referred to as Model-View-Controller (MVC). The components of this approach are defined as follows:

• A Model represents an instance of a data type, for example, User, Product, and Order.
• A Controller represents a logic executor that typically takes input in and returns the output in the form of serialized models, for example, UserController, OrderController, and ProductController.
• A View represents an output from the controllers, often either HTML, XML, or JSON.

Many current web technologies are built on top of the MVC concept, such as the following:

• PHP (Laravel, Symfony, and Zend Framework)
• Ruby (Ruby on Rails)
• Java (Spring MVC and Vaadin)
• Go (Revel and Iris)
• Python (Django)
• Swift (Vapor, Kitura, and Perfect)

The goal is now to convert an MVC application into a microservice application.

Let's go through the following sections:

• Decoupling business logic
• Reorganizing your monolith
• Integrating microservices

We start by decoupling business logic.

We start by separating business logic. What is your application doing? Answer this question in terms of which aspects are involved. For an online shop application, the answer would look like the following.

The application does the following things:

• Takes orders
• Processes orders
• Returns products
• Creates products
• Updates products
• Deletes products
• Accepts credit card for an order
• Accepts PayPal for an order

You can be as detailed as you like with this list; it is not a final list of microservices. You will then use this list to identify common components.

By looking at the preceding list, we can easily tell that we are dealing with the following components:

• Orders
• Products
• Payments

This list is now a lot closer to what we want the microservices to define for us. You may still decide to combine one or two entries in this list but you can now see which microservices make the most sense for you.

You want to reorganize your monolith in a way that makes it easy to remove parts of its functionality to be replaced with microservices.

Chances are you will not be able (or want to) update the entire application in one big swap. Depending on the size of the project, it can take weeks, months, and even years for this process to be completed. If you plan on swapping your entire monolith with microservices in one go, you can skip this step. Companies such as Facebook have done this over many years while keeping parts of their old stack. However, even when you intend to keep some of your old monoliths, it still needs to be adjusted to work with microservices. The two main areas to adjust are authentication and business logic.

Microservices typically do not use a shared session model for authentication, which is a prevalent model for monoliths. Whichever model you are currently using, your microservices, as well as your monolith, need to interact with it. A very common and often used standard is called JSON Web Token (JWT); it allows microservices to authenticate requests.

You will need to modify your monolith to be able to communicate with microservices. There are more ways than just JWTs but because of their benefits and their popularity, I would recommend you use them. In essence, the following are the characteristics of JWTs:

• Self-contained (no central verification)
• Broadly adopted (every framework has a library for them)
• Easy to debug and troubleshoot
• A concept that allows easy security

You could also use a "shared session" token instead of JWTs; the principle remains the same: your monolith, as well as your microservices, need to be able to verify the requests.

Once your monolith can communicate with microservices, you can start to separate the business logic. A well-organized monolith application may have done this already. For example, if you are using controllers, you want to end up with the following for our previous example:

OrdersController
ProductsController
PaymentsController

The reason you want to end up with a structure that separates the business logic is that you can then replace each individual component piece by piece.

So, adjust your monolith to communicate with your microservices and split it up to be easily replaced by them.

Now you are at a place where you can introduce your microservices. Each microservice should represent a piece of the business logic and should remain as independent as possible. Given that you have organized your controllers in a way outlined in the previous step, you will now be able to create the following microservices:

Orders Manager 
Products Manager
Payment Manager

You can replace the services as you see fit and as your speed allows. Having your monolith optimized in a way that allows you to replace controllers by services will make this a painless process.

In this section, we learned how to approach integrating a monolith into microservices by decoupling the business logic, reorganizing the monolith, and then lastly, integrating microservices. Let's summarize this chapter!