Minimal Viable Refactoring: The 5 Best Ways to Improve Your App on the Way to the Cloud

by Barb Malik, Principal Tech Delivery Manager, AWS Managed Services
Introduction by Mark Schwartz

Lift and Shift? Or refactor as you shift? This question comes up often in our conversations with enterprise leaders. To make the most of the cloud, legacy applications would need to be updated to take advantage of the cloud’s unique capabilities—become “cloud-native,” as we often say. On the other hand, there is considerable value in just moving applications as-is to the cloud, and doing so is faster and less expensive. How should enterprises decide how much work to put into their legacy applications as they move them to the cloud?

In this piece, Barb Malik explains the lessons that we have learned through our AWS Managed Services program, working with customers to prepare their systems to be well-operated in the cloud. She proposes the idea of a Minimum Viable Refactoring (“refactoring” is the term used in IT for making internal improvements to an application without changing its external functions).

For another take on minimal refactoring, see Phil Potloff’s earlier post on this blog, The Two-Week Rule: Refactor Your Applications for the Cloud in 10 Days.

Mark

Minimal Viable Refactoring: The 5 Best Ways to Improve Your App on the Way to the Cloud

by Barb Malik, Principal Tech Delivery Manager, AWS Managed Services

There are many reasons to move an application to the cloud. In the early days, it was often about reducing infrastructure cost and complexity. The standard migration path was “lift and shift.” That meant spinning up virtual infrastructure, uploading code as-is, and hoping to fix it later. This is still a common approach, and in some cases a necessary one.

However, it isn’t typically the optimal path. There’s a reason that it’s often called “your mess for less.” Along with the legacy app come all the legacy challenges—but in a new operational environment. For one thing, the cloud doesn’t magically remove management complexity. The temptation with lift and shift is to keep working the old way. This quickly gets expensive and painful. Who wants “your mess for more?”

The Goldilocks Effect

Organizations also miss out on the opportunity to improve their apps. The right level of refactoring can save money, boost performance, and open the door to new options. It can ready the app for next-level performance, whether using managed cloud-scale database services or intelligent monitoring.

There’s a slight catch. Too much refactoring can be as risky as too little. Trying to perfect an app or app ecosystem before migration can delay the benefits—sometimes for years. Additionally, some improvements—such as moving to a microservices approach—are much easier when you’re already in the cloud.

At AWS Managed Services (AMS), we work with customers of all sizes and all levels of cloud ambition. In addition to customers trying to operate the cloud like a traditional datacenter, we see the opposite extreme: those stuck in endless cycles of refactoring, attempting to perfect an app for the cloud before migrating.

Balancing the breadth of application refactor with speed to market is key. This method speeds migration so you can take advantage of rapid innovation in toolsets and cloud services. At the same time, it takes advantage of the testing resources available during the migration window to achieve basic modernization.

Getting Refactoring “Just Right”

That’s why, in most cases, we recommend a middle path: minimum viable refactoring. Practically speaking, it means making high-value, low-cost, low-risk changes to an app before migrating. The goal is to speed migration while maximizing opportunity.

In many cases, you can use the cloud as a testbed to speed these improvements before migrating your production app. There, you can spin up Dev and Test environments in seconds and shut them down again just as easily. Afterward, more extensive work is also easier in the cloud. You can connect to powerful platform-as-a-service and software-as-a-service solutions with a few lines of code.

Here are the top 5 things we do at AMS as part of minimum viable refactoring. Every app is different, but these actions tend to deliver big rewards with minimal risk.

1. Update the operating system. Is your OS currently receiving security patches and updates? If not, you should upgrade as part of your migration.

In an on-premises environment, upgrading requires buying new licenses, provisioning capacity (often through complex IT procurement processes), testing the app, and performing the migration. It’s labor-intensive and can be costly. That’s why businesses often put off OS upgrades, especially for critical applications that must stay running all the time. Unfortunately, running on a legacy OS can reduce performance and create security problems.

Cloud migration is a perfect opportunity to upgrade. You can quickly and cheaply spin up a small instance to test your application. In many cases, there’s an Amazon Machine Image (AMI) option with the target OS already on it, whether it’s Windows Server or any of dozens of Linux variants. Hook up Amazon CloudWatch managed monitoring services, upload your code, and see what works. Often, moving to a supported version only requires minimal changes to the app. You can keep it running and pressure-test it at low cost before migrating.

Most application owners can do this with a small team—even a team of one—and without the pain of formal procurement. This compresses the feedback loop and reduces the time and money it takes to upgrade.

In some cases, it’s not so simple. Most big organizations have at least one application running on an older platform. Documentation gaps can make these long-running apps opaque and fragile. The experimentation enabled by the cloud is even more valuable here. For example, you can try running it in a container to get it to the cloud faster, and then use the sandbox environment to make further improvements.

2. Upgrade your framework. As with OS versions, framework versions such as .NET or Node.js typically have an expiration date past which they’re no longer patched or officially supported. Companies have logical reasons for keeping frameworks on life support. Upgrading on premises can be costly and require app surgery.

The cloud makes it much easier to experiment with framework updates. Just as in the OS situation, you don’t have to find capacity in your datacenter and then license and deploy the whole stack. In fact, with the speed of cloud provisioning, you can run two or more versions of a framework side-by-side and use metrics to identify what works best. Using security groups, you can ensure the application isn’t affecting your production network. With this isolation, you can pressure-test the application and find the most cost-effective way to upgrade your framework.

In some cases, you might find that it’s easy to upgrade to an older but still-supported version. Regardless, this approach gives you fast, inexpensive feedback to identify what needs fixing.

3. Improve security. There’s a false sense of security that comes from having your apps behind a firewall in your own datacenter. Once you move to the cloud, the hard-coded DNS or IP address that in 2004 seemed harmless running locally can become an entry point for a hacker in 2020.

During migrations, we regularly discover significant security holes—often “one-time” exceptions that never got reverted. This is your opportunity to get security right before your app moves to the public cloud. Is your data encrypted in motion and at rest? Are your APIs using modern security approaches? Is security testing built into your DevOps processes? Do you know which elements of security your vendor handles, which ones you share, and which ones are your responsibility? Most importantly, is your culture ready to manage security in a cloud environment? You might not be able to address everything before you migrate, but an in-depth dialogue about minimum viable security is urgent.

4. Clean up access rights. Identity and access are closely tied to security. It’s also an area where technical debt can creep up on you. Most applications start off in a pristine state, with only a small set of privileged users having access. However, those temporary admins added during 2:00 a.m. emergencies end up having privileged access to your application years later—sometimes even after they don’t work at your company anymore.

When you’re getting ready to migrate, you’ll see who has access and can choose who really needs it. A bonus when using AMS is that nobody gets direct access. Because of our change management process, every access request is made through the command line or automation. There are no standing privileges. Access is granted or denied using role-based policies. Additionally, IP masking provides another layer of control between the admin and the instance itself.

5. Explore your database options. Like most things on this list, moving to a new database can range in difficulty from trivial to superhuman. Also similar is the fact that the cloud can be an ideal testbed for experimentation and incremental improvement.

Many organizations can move to the fully managed Amazon Relational Database Service (Amazon RDS) with few changes. Amazon RDS gives you cost-efficient and resizable capacity while automating time-consuming administration tasks such as hardware provisioning, database setup, patching, and backups. With PostgreSQL, MySQL, MariaDB, Oracle Database, SQL Server, and Amazon Aurora versions available, it’s likely you can try it with your application. With the AWS Database Migration Service, migration or replication can be surprisingly fast and easy.

For commercial off-the-shelf applications, the limiting factor may be vendor support. For example, they might list Amazon RDS as an option, but not yet support Amazon Aurora. Once your application is in the cloud, upgrading to a new database option when the vendor allows it is much simpler than it would be on premises.

Consider Your Options

In all these cases, the goal is to look at what’s possible, choose what you can do within present constraints, get to the cloud, and improve over time. It’s important to remember that the tradeoffs are not only technical. They can be related to operations, licensing, compatibility, and even cultural factors. There’s always a sweet spot between doing nothing and trying to do too much.

At AWS Managed Services, we’ve done this for hundreds of customers large and small. Our goal is always to help you maximize your cloud investment in the least amount of time. Interested? Get in touch.