Modernizing .NET Applications

Chapter 1. Why App Modernization Matters

The top two most-watched cable television networks are Fox News and MSNBC, respectively. In third place is the popular children-oriented network, Nickelodeon. What’s the fourth most-watched cable network? Maybe ESPN for sports fans? How about one of those classic television or movie channels? Nope. It’s Home and Garden TV (HGTV), a quirky how-to channel focused on home improvement. I’d like to believe its popularity comes from the fact that we humans inherently like to fix things. We often prefer to upgrade something instead of starting over. I think most developers feel the same way about our software. There’s value in improving what we have versus walking away.

Okay, but how much does your approach to software really resemble those shows on HGTV? I see at least three relevant parallels.

Stating your goals out loud

One thing I like about these home-improvement shows is that the hosts don’t hide their intentions. On Fixer Upper, the point is to help couples buy an affordable house and then make the repairs needed for them to truly enjoy it. In Love It or List It, one host wants the family to leave their old place behind, whereas the other does the necessary upgrades to try to convince the family to stay put. The host of Rehab Addict believes that old homes have a beauty that is brought out with (sometimes major) repairs, and she wants to prove it.

When assessing your software portfolio, it’s so important to know what you’re after. Say it out loud. Are you purely trying to save on infrastructure costs? If so, you’re likely to choose a different path than if you’re looking to make it easier to add functionality. Got issues with performance and scale? I’d bet you’ll make architecture choices that wouldn’t be necessary if the application were handling the load just fine.

Recognizing that the extent of intrusiveness often correlates with value

A fresh coat of paint is a good thing. But no one’s delusional enough to think that painting the interior of a house will triple its value. It’s nice, but superficial. Remodeling a kitchen? That’s a different story. To achieve exponential leaps in value, you often have to make intrusive changes.

The same goes for your apps. Cleaning up the user interface is a terrific thing to do, but rarely does that solve issues of scale, security, or stability. Are you looking to add test coverage to your code, or swap out an enterprise service bus for a lightweight broker? This means getting elbow-deep into the code, but it tends to pay higher dividends.

This goes back to your goal. If cost savings are what you’re after, you don’t need to generate significant value. Containerize it, throw it in a cloud somewhere, and move on. Now, if you’re trying to continuously deliver your app as a way to establish deeper customer loyalty, you’ll pursue more extensive avenues that give you that higher order of value. This book focuses on scenarios for which you’re after significant value from your existing .NET apps.

Respecting the choices made before you got there, but don’t be handcuffed by them

I find it amusing when an HGTV host goes into an older house and chuckles at outdated carpet or a kitchen that looks like a 1950s sitcom set. But I’d be willing to bet that those decisions made total sense at the time. In that era, with that builder or homeowner, that kitchen was perfect. The new homeowner can recognize that reality, but doesn’t hesitate to make the changes needed to make the home more suitable today.

If you’re like me, you often look at your old code and sadly shake your head. What was I thinking? However, that code probably represented the best of our skills, our knowledge, and our project demands at the time. Don’t apologize for that. Many folks dislike the term legacy software because it’s used as an insult. But that legacy software is running your company. Respect the fact that whoever built the first (or second, or third!) version of an app created something that must have been valuable enough to warrant yet another look.

What Is Modernization?

As I said earlier, you need to respect what came before. But just as you would want to update a house to current standards and styles, this book is about modernizing your .NET applications. What do I mean by “modernizing”? Your options with existing applications fall onto a spectrum, as shown in Figure 1-1.

Figure 1-1. The spectrum of options for your existing apps

First, you might choose to stay put. That means keeping the application where it currently resides and avoiding changes. Some software might be at the end of its life, so any effort isn’t worth it. Or, it’s of low business value and your time and attention belong elsewhere.

When I say replatforming I mean taking an app, as is, and running it elsewhere. Maybe you’re taking your app from a virtual machine to a container. Or from a commercial web server to an open source one. There might be some light code changes, but only the basics required to get the software to run on the next platform.

The next part of the spectrum is refactoring. Here, you make light or heavy changes to the code as part of an effort to improve it. You might also swap out major components like database engines or message brokers. Here, you also reconsider previous architectural choices. All of this takes time, but it yields more lasting benefits by retiring technical debt or increasing the functional capability of the software.

Next, you could choose to rebuild the .NET app. The work required to refactor it might be more than it would take to start fresh. There’s no shame in committing to a rebuild, but for some teams, it’s the first option they consider. It can be difficult to estimate the true level of effort to rebuild an application, and it can be challenging to incrementally deliver value if you’re replacing a heavily used system.

Besides the previous options, you can also choose to retire or replace your .NET application. I’d bet that you have some software that’s dutifully maintained but actually no longer relevant. It’s important to constantly retire applications that aren’t needed anymore. And sometimes, you replace a homegrown, custom-built system with a Software as a Service (SaaS) or commercial one.

For the purposes of this book, when I say “modernization,” I’m considering the far end of replatforming, through the refactoring and rebuild stages. That’s where core modernization happens.

Why Modernize?

Why go through the effort of changing the apps already in production? If it ain’t broke, don’t fix it, right? I never liked that saying. Sometimes, the current state seems functional on the surface but is hiding some underlying weakness.

I count at least five reasons that modernization is worth the effort:

Consolidating your environments

Server sprawl is a real thing. When I was a solution architect and needed hardware, I’d ask for the biggest box I could because I knew getting it resized later was painful. The result? That server sat at 2% utilization. What a waste. I’m sure your (on-premises or cloud) infrastructure is full of underutilized servers, forgotten testing environments, and insecure jump boxes for which everyone knows the password. By modernizing your software, you make it more amenable to high-density, on-demand hosts. That’s a cost savings, and it makes you more secure.

Adding new functionality

I’m not sure about where you work, but I’d think that software exists to, you know…do stuff. And nowadays, that often means new features for users, the ability to handle mobile clients, dynamic integration with other systems or companies, resilience in the face of bursty traffic, and a secure-by-default architecture. A major reason that organizations invest in modernization is to unlock new value from existing assets.

Upgrading and patching your dependencies

Sun Microsystem’s Scott McNealy once quipped that “technology has the shelf life of a banana.” I’d be willing to bet that some piece of your software stack requires an update every two weeks. Depending on your architecture and level of automation, it can be impossible to keep up. One goal of modernization is to make it easier to update your components.

Automating more pieces of delivery

The demands put on you by your company and customers are nearly unsustainable without a commitment to automation. Are you still manually testing the code, running security scans, or double-clicking an MSI to deploy software? That has to change, and modernization affords you the opportunity to inject strategic points of automation into your system.

Reigniting your passion for technology

We’re in the golden age of technology. I believe that. We’ve never been able to use so little effort to create more impactful experiences with technology. So if you’re not enjoying what you’re doing right now, one reason could be the slog of dealing with hard-to-maintain systems that everyone depends on. Modernizing your software so that it works for you, not the other way around, is an important reason to make this investment.

What We Cover in This Book

This book is about assessing your existing collection of .NET applications and improving them. We look at improving how you design, build, and run these apps.

In Chapter 2, we’ll explore what the current state looks like. It’s important to take an inventory of the current state so that we know what we’re working with. Only then can we zero in on the right tactics to employ.

Chapter 3 digs into the modern demands of a .NET software developer. What are you asked to create? When we understand what’s demanded of us, we can put our focus on the work that matters.

Chapter 4 explains what “cloud-native” means and why it’s an objective for many people embarking on modernization efforts. The cloud-native paradigm offers some crisp criteria that can guide your work.

The introduction of .NET Core represents a watershed moment for .NET developers. But is it suitable for every app? In Chapter 5, we look at where .NET Core came from and how to choose between it and the .NET Framework.

With new paradigms come new patterns and antipatterns. Many of the things that were acceptable on Windows or classic .NET apps are now holding you back. In Chapter 6, we look at what you need to unlearn.

Part of modernization might involve introducing or exchanging some core pieces. Chapter 7 outlines the components you should strongly consider if you’re after agility, scalability, and velocity.

You’ve never had more places to run .NET software. Chapter 8 catalogs all the major options and how you might decide what types of .NET apps run where.

Modernization is about much more than what’s in the code. In Chapter 9, we dig into proven modernization strategies that help you decompose monoliths, upgrade your architecture, and much more.

I hope you’ll be energized after finishing this book. We close in Chapter 10 with some actionable steps for getting control over your .NET portfolio and extracting new value from your existing assets.