Single-Tenant Monolith

Deploying, Exploring, and Exercising the Single-Tenant Monolith

Our transformation process must begin with our baseline monolithic application. We need a reference starting that employs the common monolithic patterns that will represent our starting point for migrating to microservices and multi-tenant SaaS. For our solution, we’ve picked a fairly common Java-based technology stack that should be similar to many of the monolithic solutions that have been commonly employed by different organizations. While we’ve selected Java here, there’s little about this stack that is unique to Java. A .NET monolith, for example, would likely have a footprint very similar to what we have created here.

The architecture employed for our monolith will rely on a traditional EC2-based model where the web and application tiers of our architecture are hosted on a collection of load-balanced, scalable instances. While these are logically separated within the code, they are deployed collectively as one unit. Any change to the web experience or the business logic would require a complete redeployment of this code. This is a classic monolithic challenge (in some cases the web tier may be separate out to allow separate scale and deployment of these two tiers. The data for each customer is stored in a monolithic database that houses all of a customer’s data. The conceptual footprint of this environment is shown in the image below:

Figure 1

You’ll notice here that we’ve shown two copies of this environment. The idea here is to convey the idea that every customer of this monolithic system will be deployed with a completely standalone infrastructure. This is a common strategy for most single-tenant independent software vendors (ISVs) who essentially treat each customer as have their own unique installation. This usually means separate support, potentially different versions for each customer, different management and operations teams, and so on.

We’ll start the lab with all the moving parts of this monolith provisioned. We’ll look briefly at some of the key elements of the deployed environment just to give you a glimpse of the architecture and elements of the underlying application components. We’ll then exercise the application just to demonstrate the working application and establish a foundation for the experience we’ll be moving to serverless microservices.

What You’ll Be Building

This lab is a bit of a mix of familiarizing yourself with the monolith and its underlying architecture as well as the simplified application that we’ll be migrating from the monolith to a serverless, multi-tenant model. The following is a high-level breakdown of the steps that you will be performing in this lab:

  • Provision and explore monolithic environment – at the outset of the lab, you’ll have a fully provisioned single-tenant monolith that represent our starting point. The lab will take you through some basic steps in the console to examine what has been provisioned. It will also get the moving parts of your IDE and development environment created.
  • Exercise the monolithic application – it’s important to at least have some exposure to the moving parts of the application that his being transformed. So, we’ll bring up the application and exercise a few aspects of it and look at the logs and data that are generated from this experience.
  • Examine the code of our monolith to see the moving parts of our solution. The goal here is to expose you to enough of the underlying bits of the monolith that you’ll have a good foundation of knowledge that will be useful as we begin to carve this up.

At the end of this lab, you’ll still have a single-tenant, monolith experience. However, this first element of our transformation—migration of the application of a modern framework—will be complete.