Our recent article, Cloud migration: The advantages of the public cloud, described the concepts and advantages of public cloud migration. This post goes into further depth and discusses the functionality of an existing application that captures, tracks and reports issues as the basis for migrating the application into the public cloud. The post continues by migrating the Issue Tracker application to the cloud using local Docker containers. The journey takes it from running locally on a web server to running on a desktop implementation of Docker containers to running on public cloud containers. The story concludes by discussing future strategies to fully decompose the application into the public cloud.
The Issue Tracker application
The Issue Tracker application is the sample application we will use to demonstrate moving from a monolithic, on-premise application (see Figure 4 – Issue Tracker Architecture) to the public cloud. Issue Tracker allows anonymous users to enter issues, requests and testimonials for applications. It is designed to be a separate application called from other applications to capture and manage issues. This allows someone to create or edit an issue, and when saved, it emails the requestor and the issue owner to let them know the issue has changed. Furthermore, it uses authentication and authorization built into the MVC templates provided by Visual Studio. Only authenticated users can edit issues, and those users authorized as developers or administrators can view and update specific fields on the forms. It provides reports and charts showing issue counts and issue types.
Issue Tracker is a web-based, responsive, monolithic application that runs on Microsoft’s Internet Information Services (IIS) Server with a single SQL Server database instance. This application represents today’s legacy applications and will provide the starting point to discuss strategies to migrate from a monolithic application to a full-blown, public cloud-enabled solution. This blog explains different approaches, various steps and some alternatives that allow the application to take advantage of scalability, performance, reliability, high availability and fault tolerance simplified by leveraging features available in the public cloud.
The Issue Tracker application is developed in C# using the Model, View Controller (MVC) pattern. C# running on IIS is one of the most prevalent development platforms. Although some of the discussion will focus on full-stack Microsoft development concepts, these ideas can be immediately applied to solutions built with other frameworks such as Java running on Apache and Linux.
The initial development instance uses the single SQL Server Express database built into Visual Studio. This allows individuals to quickly build and test the initial code. I opted to use LINQ embedded in the code but could have built solutions using stored procedures. While once the best practice, stored procedures have become a migration bottleneck and are no longer recommended for solutions that may ultimately require large-scale deployment. Issue Tracker uses a relational database that is ideal to store structured data in discrete fields. SQL Server is not ideally suited for storing unstructured data such as PDF files, screen images and other data containing information in unpredictable formats. The solution stores screenshots as files on the local file system. Future considerations include deploying a NoSQL database to store and query these files.
Issue Tracker uses JQuery and Bootstrap to layout forms on the browser. These enable columns and provide a consistent visual appeal. The application can be accessed at http://JenTech.Biz/jts/IssueTracker?project=blog
The Issue Tracker application provides the following functionality:
Authentication
New users must register to update the issues they have submitted. The register extends the identity classes to capture additional user information that is used by developers troubleshooting. The form then uses built-in validation to ensure all fields are entered before saving the user data.
Log in
Once a user is registered, they must log in to activate the features. This form also validates data based on the data type. Once the user is authenticated, their email address (User ID) will appear in the menu.
Home page
The home page shows the current list of issues that can be filtered by issue type. Future functionality that could be added includes using paging on the list and/or restrict the list issues created by an authenticated user.
Create issue
Users can create new issues by filling out the form. Authenticated users will auto-fill the requestor fields. Clicking “Create” returns to the home page showing the new issue. Click “Open” to show only open issues.
Reports
Reports use the built-in ASP.NET charting controls generate sample reports. This is a very simple example intended to show the built-in capabilities and provide a basis for discussing cloud-based strategies.
This is the high-level overview of the Issue Tracker application we will migrate to the public cloud using several different approaches.
Migrating Issue Tracker
We have several methods available to get Issue Tracker into the cloud.
Lift & shift
To lift and shift Issue Tracker, we will need two servers and one storage location. The Microsoft IIS server will host and execute the website logic, and the SQL Server will run the database. We would provision resources as follows:
- IIS Server
- Four cores
- 16 GB RAM
- Local block storage
- SQL Server
- Four cores
- 16 GB RAM
- Storage
- On-demand storage
Lift & shift is done in the following steps:
- Configure and launch the servers
- Install and configure our licensed copies of Microsoft Windows Server operating system
- Install the SQL Server database server on the database instance
- Backup the on-premise SQL database
- Restore the SQL database from the backup to the cloud instance
- Copy the application to its directory in the IIS server and configure the connection strings to work with the cloud-based SQL database
- Test the application to confirm everything is working
The IT team is updating, monitoring and paying for the server operating systems and the SQL database software. The simplest option is to scale up the servers by expanding the computing power based on this demand if demand increases. Scaling up is a feasible alternative but gets expensive as the equipment grows and quickly reaches physical limitations.
Refactor / Rebuild
Rearchitecting the legacy application for the cloud is essentially rewriting the application as a greenfield application. This approach is feasible as Issue Tracker is a small application and could be readily architected to take advantage of all the cloud services. If this is the right business decision, it is recommended to look at serverless services, a message queue-based architecture and designing elasticity into every component.
Re-platform
First, we will migrate Issue Tracker to desktop containers, then migrate the containers to the public cloud.
Migrate to containers
Earlier it was discussed that containers are a lightweight form of virtualization. Public cloud services include “serverless” adaptations of containers. These containers can lift and shift the Issue Tracker application into the cloud and still take advantage of the elasticity, health checks and performance optimization offered by serverless containers (see Figure 7- Container Architecture). This architecture enables us to scale up the database container as well as the IIS container as needed. The database scale-up may hit physical limitations and cost constraints over time but remains a viable mid-term strategy. Longer-term approaches would be to decompose the application and database for the public cloud. It is also feasible to refactor the Issue Tracker application into a self-contained microservice.
Move your application to a local copy of Docker for Windows. This exercise assumes you have:
- Windows 10 or Windows Server 2016 on a workstation capable of running virtualization
- Docker for Windows installed and running
- Visual Studio 2017
Docker Hub is a website that offers hundreds of pre-configured base images. These range from single operating systems to production-ready ERP systems. Using these pre-built images allows you to take advantage of work done by other teams. These images are constantly updated as patches, and new versions of the base software are available.
Preparing and running the Issue Tracker application on Docker requires the following steps:
- Build the Docker SQL server database container
- Backup the development database to a local .bak file
- Build the Docker Image
- Pull the Microsoft/MsSQL-server-windows-developer base image
- Run the image
- Copy the backup to the image to the docker image
- Attach to the docker database server using SQL Enterprise Manager
- Restore the database from the backup file
- Build the IIS container
- Setup Visual Studio to save the solution as a container to publish the package. This instructs Visual Studio to save all the necessary files to rebuild the application inside a container.
- Generate the publish package. This saves the files in a location and format that is easily transferred to the Docker image.
- Build the Docker Image
- Download the Microsoft/aspnet base image
- Copy the IIS publish package to the image
- Start the Docker image
- Navigate to http://localhost to confirm the image is running (See Figure 8 – Home Page via Docker)
Figure 9 – Home Page via Docker
This process takes approximately 4-8 hours the first time. Once you understand the nuances and have downloaded the base images, the whole process can be repeated within an hour.
Deploying containers
Follow this process to deploy your Docker images on the public cloud.
- Create a Docker Repository in the cloud (i.e., Docker Hub)
- Authenticate Docker client to the repository
- Push each image into the repository
- Tag the image
- Push the image
- Pull the images into the container services
- Run the images
Advantages
Legacy applications running inside containers on the public cloud can take advantage of all the public cloud benefits, including elasticity, shared responsibility, and economies of scale. However, development is still done locally while hosting takes advantage of enterprise-ready hardware and systems.
Refactor / Rebuild
Now that we have our Issue Tracker application running on containers in the public cloud, we can start decomposing it into logical services that leverage services offered by the cloud.
The obvious starting points for decomposition are:
Authentication and Authorization. We can use an OAuth service offered by the public cloud to authenticate and authorize users. This way, we take advantage of the cloud’s identity services using loose coupling from our application. Once this is coded, it can be reused by all future applications we build. As OAuth capabilities are grown by the public cloud provider, these are available to be incorporated into our application.
Messaging. The Issue Tracker uses SMTP messaging to notify the issue requestor and issue owner when an issue has been created or updated. This is a perfect opportunity to rewrite the code to call the public cloud messaging services.
Queueing. The Issue Tracker does not have the volume needed to use queues. However, queueing would be a solution if we build an application that can accept data from tens of thousands of devices in real time. We will save this for a future blog.
Reporting. The Issue tracker provides rudimentary reporting and charting options. This could be extracted from the monolithic application and moved into public cloud reporting services. These provide charts, reports and dashboards that can be developed and configured by end users without changing the application code.
Content delivery. As a result of our highly transactional application, it is not a good candidate for a CDN. Content delivery is much better suited to delivering massive volumes of static content in specific geographic areas.
Microservices. The application could be based on serverless services and create and display issues. Designing these as stateless actions is entirely feasible based on the size of this application. Larger applications with more dependencies may or may not qualify for this type of granularity.
Summary
This blog covered key concepts for the public cloud and described, in simple steps, the process to lift and shift the application into the public cloud and a similar process to migrate the application to containers in the public cloud. Each step transferred more of the IT infrastructure management and security from the business to the cloud provider. Along with this, they all enabled more elasticity and higher availability. Furthermore, every move enabled the business to spend more time expanding its core competencies while delegating IT management to companies with far larger budgets and motivation to improve their infrastructure.
Interesting in taking the next steps on your journey to the cloud? Get started with a FREE one-hour assessment today!
