Chapter 2. What You Have Running Right Now
In Chapter 1, we established that there are business benefits, technical benefits, and human benefits to running adaptable, maintainable software. Sounds like a place you want to be! But if your company is like most, you’re not starting with a blank slate. No, you have years’ worth (decades’ worth, even) of .NET software that runs your company. That’s your starting point. Before we shift to the new-and-exciting aspects of modern .NET, it’s important to catalog our current state. Why? It’s difficult to clearly see the value of new paradigms unless you recognize the pain of where you are today. And to get a sense for what “better” looks like, you must have a baseline.
In this chapter, we look at a few areas that reflect your (likely) current state. For each, I outline the implications and your motivation to change.
You Have Many Different .NET Project Types
There isn’t a one-size-fits-all approach to .NET projects. From the beginning, Microsoft offered different types of projects for each scenario. Need a component? Create a class library. Building a website or web service? Choose from a few options. Building a smart client for the desktop or a background service for the server? Yup, we have those handled, too.
Anyone using .NET for a decade or longer has these types of applications running somewhere:
- Windows Forms application
-
Run thick-client applications on the desktop. These are user-driven applications built with rich UI controls provided out of the box, bought from a third party, or custom built. These applications were everywhere in the enterprise until high-speed internet became ubiquitous.
- Windows Services
-
Define long-running background jobs for Windows environments. Many server-side software products installed their components as Windows Services. It was also easy for developers to build these to perform tasks like monitoring file shares for new documents.
- Windows Presentation Foundation (WPF) applications
-
The successor to Windows Forms. These apps offered a UI framework driven by declarative models written with Extensible Application Markup Language (XAML) and .NET code.
- Console applications
-
Terminal applications that are often invoked via command lines (with parameters) or other simple tasks that require only text input and output.
- ASP.NET Web Forms application/site
-
Quickly develop web applications using the original .NET web framework. Based on HTML, server-side controls, and server code, these applications replicated the Windows Forms developer experience. Even though building SOAP web services was easy with this model, it was also quite basic and limiting.
- Windows Communication Foundation (WCF) services
-
WCF is a hyper-extensible framework for building SOAP and RESTful web services. WCF implemented a variety of WS* standards in an attempt to be a cross-platform framework. Although powerful, WCF led teams down a configuration-heavy, complex path.
- ASP.NET MVC applications
-
Build web applications and APIs based on the popular model-view-controller design pattern. This open source framework remains a popular choice and has likely become the default option within your organization.
I didn’t even include unsupported Windows Workflow or Silverlight applications in this list, but I’d be willing to bet that you have a handful of those applications stashed somewhere!
What That Means
It’s good to have choices. But as a result of evolving choices in the .NET ecosystem, you now have a mishmash of programming models and skill sets throughout your organization. Even though all of the aforementioned are technically supported by Microsoft, you’ll struggle to find Windows Forms experience, whereas ASP.NET MVC skills are plentiful in the market.
Why You Want to Change
You could lift and shift some of your classic .NET application types to a new Infrastrucutre as a Service (IaaS) or container environment. However, that doesn’t change much for the better. If the app is poorly performing, with a lousy interface and a 10-year-old codebase, clouds or containers won’t fix that! Ideally, you consolidate your desired skill set by retiring old programming models and modernize applications so that the transition to cheaper runtimes is easier.
You Have Lots of Windows-Specific Hooks in Your .NET Software
Given that .NET applications ran only on Windows for the past two decades, you’d be forgiven for coupling to that operating system.
Without thinking about it, we used capabilities like Integrated Windows Authentication to verify Active Directory users. We added strong-named assemblies to the Global Assembly Cache (GAC) so that everyone on the server could share them. For years, it’s been standard to use the ubiquitous Windows Registry for software settings, installation location, and more. And Windows-based software often required drivers or MSI-installed Windows Services to run successfully.
What That Means
Individually, those Windows-specific hooks aren’t bad, per se. But using them does mean that you have some nontrivial refactoring to do if you want to use .NET Core on Linux or are starting to experiment with containers.
Applications with the previous Windows-centric characteristics also tend to be difficult to scale or instantiate on the fly. All that preparation of the operating system means that adding a new server to a cluster isn’t simple. And if someone wants a quick development or testing environment built from scratch, there’s a lot of friction to making that happen quickly.
Why You Want to Change
Portability and interoperability matter more than ever. When our software is more portable, it’s easier to move quickly through development and testing environments into production. Portable apps care less about their host infrastructure, giving you the freedom to use cheaper hosts or alternate operating systems.
Most of the hooks mentioned earlier don’t directly affect interoperability. They’re local to the software itself, so from the outside looking in, they’re implementation details. The exception? Integrated Windows Authentication. In a world in which software runs across Linux and Windows hosts, on mobile devices or full-featured computers, and in public and private infrastructure, cross-platform identity strategies rule. If you’re pinned to a Windows-only authentication model, this limits your flexibilty and forces you to add awkward shim solutions.
You Have Stale Environments That Aren’t Regularly Updated
Quick—think of a place running your software that hasn’t been updated in months or years. It’s probably not difficult. I know there are “Hello world” apps of mine running in dozens of locations. Windows Server environments haven’t historically been easy to automate, so the whole “treat servers like cattle versus pets” movement passed over many companies. And I’m not just talking about production environments running dusty apps and unpatched operating systems. I’m also referring to the hidden sprawl of sandboxes, performance testing environments, and proof-of-concept clusters. Rarely are your current .NET software or the Windows hosts that run it updated at the rate it should.
What That Means
A stale environment is an insecure one. I’d be willing to bet that something in your software stack becomes vulnerable every two weeks. Unpatched Windows servers are catnip to hackers. Yes, even servers that aren’t sitting in your internet-facing DMZ. If someone finds a home for malicious software on a never-changing, lonely server, it might be months or years before you notice.
Let’s also not forget about vulnerabilities in your software itself. If you use a lot of external dependencies in your web or smart client apps—admittedly, many classic .NET apps were light on non-Framework dependencies—it’s your responsibility to plug those holes regularly. Finally, if you have rarely touched infrastructure and apps, it’s likely that you’re using long-lived credentials. This also increases your risk exposure.
Why You Want to Change
You have this seemingly impossible task of moving faster while becoming safer. But nobody is satisfied with the status quo. There’s that nagging feeling about those old, unpatched servers and instances of software. As we all build more software, we need a different approach. Instead of hoping that you aren’t hacked, you want to switch to a proactive stance; one in which you create and destroy servers quickly, patch software constantly, and rotate credentials regularly.
You Have Monolithic Architectures and Complex Deployments
The easiest applications to build are those that have tight coupling. It’s work to pull out C# from a codebehind page and put it into a remote web service. Adding a message broker introduces complexity. Logging to the local machine’s Event Log is simple. A lot (most?) of the software I’ve written in my career has been a monolith. By that, I mean software that is part of one codebase, with collapsed application tiers (e.g., data access code embedded in user experience tier); that is, compiled, deployed, and scaled as a single unit.
Monoliths aren’t inherently awful. Architects like Simon Brown advocate for “modular monoliths,” and Martin Fowler makes good arguments for a “monolith first” approach. There are legitimate reasons to avoid the premature optimization of microservices. That said, I suspect that your current monoliths require a delicate series of steps for deployment, which limits how often you do it.
What That Means
If you have a monolithic .NET application, you probably aren’t reusing many of its custom components in other applications. It’s also likely that you coarsely scale the application. When handling more demand, you’re scaling the host for many of the components, even if all the components aren’t consuming more resources. It also can be challenging for you to make targeted updates to the software without redeploying the entire thing.
When you have complex monolithic apps, you typically deploy them less often. At least that’s my experience. That’s because integration testing is more costly, and the installation routines are more intricate.
Why You Want to Change
Who cares if deploying your monolithic .NET app is complicated? You need to do it only once or twice a year! That doesn’t reflect the rising demand for regular updates, however. As we established earlier, stale apps and environments are the enemy. They’re indicative of increasingly irrelevant software and vulnerable servers. We want to move faster.
By rethinking our architecture, we stand to deploy in smaller batches, run different components on differently sized hosts, scale only the components that need it, and cater to more parallel software development team.
You Have Apps Without Deployment Pipelines
Are you envious of these software-driven companies that can ship software any time they want? What’s their secret?
You probably look at the web-scale giants who update their software every 10 minutes and think “That’s crazy, we don’t need anything like that.” It’s likely true that your enterprise software or APIs won’t have features added daily. But you’ve seen so far that continually updating .NET apps and infrastructure is about more than just features. You want to close security holes, patch software bugs, and more. How do companies ship so often? Deployment pipelines are a big piece of that puzzle.
What That Means
If your apps aren’t on a pipeline, they typically consist of pockets of automation (such as continuous integration) intermixed with endless handoffs and manual processes. The problem is that you’re only as fast as your limiting factor. If your quality assurance (QA) team has a manual review stage, it barely matters if you automate the steps before and after. If you automate the steps before QA, you’ll just pile up work for them. Automating the steps after? Those stages will be starved for work because they can handle much more than upstream processes can hand them.
Even if speed isn’t your biggest concern, quality should be something you care about. When your apps are delivered manually, they tend to be more error prone and subject to ad hoc adjustments. This results in inconsistencies that bite you later.
Why You Want to Change
I would contend that “.NET apps on pipeline” is one of the most important metrics you can track. Such an investment in automation is worth it. Consider what happens when you automate your integration testing: developers get faster feedback and have smaller batches of changed code to check when problems arise.
Another benefit? When deployments are automated, it reduces the perceived cost of deployment to zero. This means that teams feel empowered to quickly fix bugs, patch vulnerabilities, perform A/B testing on new feature ideas, and respond to the needs of related teams. Small batches, constantly delivered. That’s one of the secrets of the cloud-natives!
You Have Apps That Aren’t Ready for Higher-Order Cloud Runtimes
If you have .NET apps created in 2006 or earlier, you probably weren’t thinking of cloud computing when designing them! Many first-generation cloud platforms were fairly prescriptive on what could run there, and none of them were Windows-friendly. That might have stunted the introduction of cloud-native patterns to many organizations. A lot of custom-built enterprise .NET apps use design patterns suitable for an on-premises environment that doesn’t change quickly or handle unpredictable load.
What That Means
If you have a lot of “traditional” .NET applications in your portfolio, it limits which cloud runtimes make sense. Specifically, apps that don’t have cloud-native characteristics aren’t a great fit for anything besides virtual machines—basic lift-and-shift exercises. In Chapter 1, we discussed the fact that there’s limited value in that effort. Some value, but limited. Ideally, your apps can take advantage of more on-demand services with elastic scale. And if your software has complex deployment routines, a cloud platform won’t magically make that easier.
Why You Want to Change
Why do people like you embrace the cloud-computing model? Because agility matters. You gain competitive advantage when you can ship useful technology more often and make it easier to use. Cloud computing ushered in this era of on-demand access to seemingly limitless resources, along with a host of novel services for databases, machine learning, and more. If your app isn’t cloud-ready—whether that app is going to a public or private cloud environment—you’ll never get more than superficial value.
Summary
Depressed? You shouldn’t be! We all start from somewhere, and your existing app portfolio got you to where you are today. Next up, let’s examine what you’re being asked to create today and what you need to pay attention to as you make your software decisions.