I’ve been seeing an acceleration of refactor scenarios that I’m seeing as companies are adopting cloud capabilities. In terms of scenarios with high value, I’ve often doubted refactor as a serious investment area. The reason is that it takes time, effort, and the monetary pay-off can be minimal. There are however scenarios that has immense functional, cost, or scale return. Let’s take a look at some of the scenarios that are happening more often in the industry.

Use Case #1 – Application Identity Layer / Management

A consultant friend of mine said, “application identity work is the type of work where they stick you in a room and feed you through a slot in the door because it is so critical you need to be focused”. In contrast, most applications have a fragile identity layer, full of holes and easy to exploit. Very few developers are actually identity experts but instead of using a platform like Azure AD, they have used lowest common denominators identity providers from their pasts. Many fail to build even modest protections for their users and multi-factor auth may as well be a dream.

The refactor scenario is to replace the identity platform with Azure Active Directory, for internal, business-to-business, or business-to-consumer identity scenarios. The advantages are many… first, the security difference of running a platform of enterprise capability. Second, the global scale and SLA of the most important infrastructure for the application. Third, the features available, such as verifiable credentials, MFA, password reset, etc. Just the simple act of NOT having to build these is worthwhile.

Use Case #2 – Processing Scale

Another frequent refactor need is when a company simply cannot scale their current monolith or manual process to the needs of the business. A recent company had a business operation that required billions of transactions, but only occurred once a month. This process wasn’t running, even in their high-scale on-premise HPC environment. In this case the refactor was about building a scalable architecture that could fit not only the current use case, but the future use cases as well.

In this customer’s environment we moved the application into a container based model with a scalable data layer that could handle the number of transactions over a short period. We then reduced the size when the transactions had completed.

Use Case #3 – SQL

A huge licensing and cost savings area of refactor is SQL server. In on-premise environments the SQL servers ran wild. The licensing costs equally ran wild. Now, you COULD choose to centralize your SQL investments into less instances. I’m not necessarily recommending that. Instead, the major cost savings I’m seeing is just through simple optimization of resources tied to SQL servers and movement into Azure SQL, especially since an architectural goal is to maintain vertical segmentation between applications. In a sense, I’m trying to minimize places where applications share SQL instances, but also reduce the size of those SQL instances. This area also accelerates after an on-premise to cloud migration where SQL migration is a target of cost optimization for licensing purposes.

Use Case #4 – DevOps

Is this truly a refactor? I’d say so. We’re getting to a point where many companies have migrated legacy virtual machines into the cloud. Few, however, have created infrastructure-as-code and release pipelines for the virtual machines. Instead, many companies have left the migrated VMs in a similar state that they were in at the beginning. This results in a huge missed opportunity and two operational states. The first is the “junk we moved from on-premise” and the other is “modern operations”. A critical step in migrating workloads from on-premise is the adoption of DevOps practices as part of the migration process… a step which takes only moderate effort and brings immense payoff. I’m not saying adopt application code deployment… since many of the apps are box platforms. Instead, at least deploy the VM infrastructure configuration as code.

Use Case #5 – App Platform Modernization

You can only continue to invest in the legacy monolith application so long until it becomes critical and the tech debt catches up to you. There are a variety of ways to execute on the modernization. In some cases I’ve seen companies shim a modern platform in front of legacy environments, such as a way to modernize and unite many iSeries legacy ERPs. In others the modernization started with a micro-services architecture and a long-haul scaling approach. The critical consideration is “what is the business value driving this and how do we deliver value?” How can the modernization be closely coupled to a business value delivery conversation, vs. just addressing tech debt?

There you go. You’ve seen my ideas. What is on your list this year?

Nathan Lasnoski