Like ivy on a house, monolithic applications don’t just appear. They slowly sprawl out over time. The release of .NET 5/6+ marks a new era in .NET development and presents an excellent opportunity to trim down those huge applications to take full advantage of the new .NET.

Optimize the process of rewriting your old applications to target .NET 5/6+ by modularizing different components as microservices.

In this article, we explain what it means to modularize your .NET applications and provide the important questions you should answer as you update your systems.

Jump to the How-tos

Microservices and Microapps: The Basics

“Microservices” is a tech buzzword that means something a little different to every person you ask. So, let’s start by defining some terms.

Monoliths

Monoliths or monolithic applications refer to a “traditional” method of software release where an application is released as a unified, single, usually humungous entity.

There are benefits to this method, like development and deployment simplicity. But maintenance and update are slow and difficult.

Monoliths also just happen over time. Code becomes increasingly intertwined, and one day you realize that what were once separate pieces are now a monolithic mess. Monolithic applications defeat all the Agile benefits you get from CI/CD.

Microservices/Microapps

The opposite of monolithic development is microservices and micro-applications (microapps).

Everyone knows this term but they are unlikely to define it the same way. Often, though, people mean “modularized development.”

Modularized development, as the name suggests, is developing separate “modules” for discreet parts of your application or code. Just as your cell phone has totally separate applications for messaging and the camera, your IT systems can remain an integrated application while being modularized inside.

Transitioning to modularized development is not trivial; it will take time, effort, and resources. But with automation tools in place, these are just as easy to develop and deploy as monoliths but are also much easier to maintain and update at speed.

Why Modularize?

.NET 5/6+ represents an unprecedented release cadence for Microsoft:

• each new .NET will come just one year after the previous major version
• only even-numbered releases will be a long-term support
• the long-term support period will be only three years

It’s common sense: Keeping up with this pace will be much easier if you’re working with modularized applications, rather than a single, giant application.

While “traditional” .NET functionality like WCF and Web Forms will remain available as long as.NET Framework is supported, it would be unwise to (re)write new applications to target this aging technology. Modularizing your applications to target .NET 5/6+ means you have smaller system pieces, which are simpler to update. Modularizing is the best way to get the benefits .NET 5/6+ offers.

How to Modularize Your Monoliths for .NET 5/6+

There is no single right way to migrate a monolith system to a modularized one. The migration process to microservices and microapps will be unique to each organization, just as the software itself is unique to the organization. But there are some questions every team should ask when considering this move.

How will teams be structured to support, communicate, and maintain these microservices and microapps?

This is perhaps the single most important question to answer.

At its heart, DevOps isn’t about CI/CD tools; it’s about a different culture among the humans in your organization. Attempting to run microservices and microapps in the same team structures that supported monoliths is a bad idea and sets everyone up for failure.

For example, WebMD wanted to make the transition from a monolithic legacy application to microservices, but the dev team managers failed to consult automation experts when making decisions. The results were as successful as herding cats and required a complete “reset” with a new DevOps team.

The WebMD case is instructive: The choices they made after that initial failure consulted both external and internal experts to decide how best their teams would modularize their applications and support them to maintain their HITRUST certification.

What functionality within the monolith should be split into its own microservice/microapp?

This question must be answered not just by each organization but for each application you have. You can find lots (and lots and lots) of advice on the Internet, but your most trusted experts should be your developers.

Answer questions that will avoid the situation of multiple microservices always being developed and deployed in tandem and maintained by the same team (which will quickly lead to a new monolith), such as:

• Which team will maintain X microservice/microapp?
• How will changes be specified?
• What other microservices/microapps will X depend on?

What functionality should become a library to be shared across microservices/microapps?

The answer to this question is also individualized to each organization and each application you have.

As a starting point for the unsure, copy the code over from your monolith into the microservice/microapp. It will be easy to convert it to a library later, and you’ll get a better picture of what libraries need which code.

But this is not a long-term solution; you don’t want hundreds of little packages floating around that every microservice/microapp requires. Convert these packages to libraries as soon as possible or get rid of them once you’ve determined they don’t need to be a library.

What technologies should be used for which microservices/microapps?

For large web applications written for Web Forms, the .NET 5/6-recommended alternatives are MVC (Razor) or Blazor. Modularizing Web Forms applications for .NET 5/6+ will be complex but very worth the effort. Unlike Web Forms, whose code is entangled in the .NET Framework itself, MVC and Blazor work with .NET 5/6+, rather than as a core part of it.

Middleware in the .NET Framework traditionally used Windows Communication Framework (WCF). The Microsoft-recommended alternative for .NET 5/6+ is gRPC. The rewrite from WCF to gRPC is significantly simpler than from Web Forms to Blazor.

And surprise: You can still use desktop applications! Windows Presentation Foundation (WPF) will still work in .NET 5/6+, except for a few, minor breaking changes. This is likely also true for ClickOnce.

What technology should host my microservices/microapps?

There are three main ways to host .NET 5/6+ modularized applications: IIS, Kestrel, and Docker Containers.

To be responsible with resources, you should use whatever your organization is already familiar with using. In most cases, your teams will be most familiar with IIS, which is often also the best option for microservices/microapps.

IIS has logging, Windows Authentication, and can handle multiple applications/porting. It’s also quite easy to manage and is more familiar, especially to Ops personnel. Multiple apps/porting are especially important because they simplify configuration. Without this, IT will constantly have to create new IP addresses or assign ports.

What technologies should be used for distributing microservices?

Generally, there are three choices for distributing modularized applications: artifacts, packages, and Docker containers.

Containers introduce many, many other decisions that should be considered separately (but alongside) this conversation about microservices.

We also suggest that packages are superior to artifacts for all but the smallest teams because the metadata for each package is a part of the package (whereas artifacts are just decontextualized files).

Regardless of which you choose, integrating a private repository/registry like ProGet into your CI/CD toolset will reduce the possible negatives of “sprawling” microservices by centralizing all packages and containers. And it may surprise you, but desktop applications will still be supported in .NET 5/6+. For these microservices/microapps, you may still use ClickOnce or an installer.

Conclusion: Both .NET 5/6+ and Microservices Mean Agility

No matter what you choose, CI/CD with consistent versioning and visibility is essential—so essential, in fact, that it doesn’t really matter what technology you use.

Well, it matters. But it matters a lot less than these choices would for monoliths because you should consider regular updates to modularized applications as new technology becomes available.

We’ve built a guide to help you successfully navigate the migration to .NET 5/6 and beyond. Get your free copy today!