Nov 20, 2017 | 5 min read

3 Cosmetic Upgrades to Move Closer to a Microservices Architecture

By: David Henry

Cosmetic Upgrades to Move Closer to a Microservices Architecture

When renovating your home, you may choose cosmetic or structural changes depending on your needs and priorities. Similarly, those looking to take advantage of the Cloud for their monolithic architecture must decide if they need surface level changes or a deeper overhaul to accomplish their goals. On the one hand, a structural renovation might start with the demolition of your application and operations practices to fully take advantage of DevOps and Microservices. On the other hand, cosmetic changes can take the form of refactoring your operations and applications to utilize Cloud services while maintaining a monolithic architecture.

If you tear down your house, you will have nowhere to live until you rebuild, and you may not have the time or budget to go that route. If you want some of the benefits of the cloud, but time and budget will not allow an immediate overhaul, here are 3 cosmetic upgrades you can make to your server so that you can chip away at renovation while maintaining a livable environment.

1. Decluttering: Refactoring the FileSystem

With any renovation, making sure you reassess your storage options is key to maximize space. Relying on your current storage option, the FileSystem, may keep you chained to a monolithic server. Network shares, temp files, locally cached files such as images, or logs are all clutter that can keep your renovation efforts in limbo. Your first step is to make sure the application is not directly utilizing the System.IO namespace and instead has a layer of abstraction in place for file access and moving logs to a remote event stream.

One strategy for a web application to help decouple the FileSystem is to utilize Virtual Folders in IIS. Think of this as starting with one room in your house and getting decluttered and organized. Virtual Folders can apply a level of abstraction without introducing too much of a shotgun effect on your code base. Once the Virtual Folders are in place, an IIS Redirect can plug in a different storage option than the FileSystem. In the following diagram, a Virtual Folder is configured with an IIS Redirect pointing to S3. If a user downloads a file in that Virtual Folder, instead of the FileSystem coming into play, a highly scalable cloud-native storage option with S3 is utilized.

Diagram: A Virtual Folder is configured with an IIS Redirect pointing to S3

2. Opening the Walls: Sessions

If your application heavily utilizes ASP.Net user sessions, it’s possible they are not ready to work in a distributed manner, which is critical for a cloud-native architecture. With the session, you may not know how bad it is until you get in there. Like in your house, you need to open the walls and see what is lurking behind.

Moving database state client side or to a cacheEven if you are utilizing a load balancer, sticky sessions can create a false sense that they are ready to move. The first step is to make sure the session provider in use works in a server farm - so no State Service or In Process sessions. Second, you may be using a database provider, but moving to an in-memory provider such as Redis can help decouple your session information from your monolithic database.

Sessions can also be an indicator of how much state you are carrying while running your web application. The more state tied to your user’s session, the less likely you are going to be able to scale up the requests. Pushing that state client side or to a distributed cache provider could be a quick-win to help reduce that state server side.

3. Routine Inspection: Version Upgrades

In a home renovation project, you might bring in an electrician to do a thorough inspection to make sure everything is up to code and up to date. Routine inspection of your house is a preventative measure to avoid a costly issue down the road. Similarly, keeping your server and .Net version on a supported platform can go a long way to easing your path to the cloud.

The Cloud is inherently always up to date with the newest version, so a lot of routine work is performed for you. However, if you’re on Windows Server 2008 R2, a .Net version earlier than 4.5.2, and/or SQL Server 2000, planning for an in-place upgrade can be instrumental in avoiding migration issues. In most cases, these upgrades are seamless and won’t affect your overall architecture. Additionally, with Windows Server 2016, Microsoft has enabled Windows to be a Container host. By upgrading to Server 2016, you can put your architecture on a roadmap to the cloud by refactoring towards Containers.

Docker Running on Windows Server
Image Source:

The Path to Cloud-Native

Once you have started on the cosmetic renovations, more choices will be available to refactor your application architecture. The next step will be to decide if you should utilize Containers to migrate your application to the Cloud, break up the architecture further into Cloud functions, or a combination of both to put your application in a cloud-native, distributed architecture.

Contact DragonSpears for guidance in making these decisions for your migration  efforts.