Why .NET isn’t available to deploy on PaaS (Platform as a Service)
By: Matthew Mcguff
Tags: Coding, Dotnet, Heroku, DevOps, Software Development

Was wondering why I couldn’t deploy .NET applications on Heroku. What gives?

By day, I work in .NET (cSharp) applications for a major university.

By night I freelance in JavaScript (Node, Angular, React, etc.).

PaaS offerings like Heroku are an essential part of my freelancing business. They make it possible for me to spend less time worrying about the complexity of deployment and more time actually writing business logic and code. To understand why application developers like myself choose PaaS, consider the following abstraction based in 🍕:

Homemade pizza (On-Premise deployments) involve a huge amount of complex and tedious decision making. Replace dining table, soda, oven and fire with server hardware, RAM allocation, OS (Operating System) and last but not least, your app(and its data).

So without giving up complete control of everything like you do in a SaaS (Software as a Service), PaaS provides:

🚀 Rapid deployment with the use of containers (Heroku marketing calls them Dynos but we know what they really are 📦).

🙂 Simplification- as mentioned previously, less decisions to be made about tiny details that have nothing to do with your app and its data.

However, despite being a big fan boy of PaaS, it isn’t without its weaknesses. When you allow Heroku to make a bunch of decisions for you, you ultimately are giving up…

CONTROL!

Now in newer applications you build for startups where the most important consideration is to get you app out there, the giving up of control is a highly desirable trade off. Anything you can do to reduce the friction of getting started is a big win.

However more mature applications have been battle tested. Their successful deployment to solve old problems has uncovered new problems to solve. These new problems often center around performance or integration.

Consider an admissions application. The system successfully accepts tens of thousands of new applications a semester, stores them in a SQL database and makes it possible for an admissions team to decide what semester they will track accepted applicants. The admission team and others at the university have been using the application for a long time. They know what it can do, what it can’t and what they would like it do in the future. They want to spend less time in front of loading spinners and more time getting their work done. They also want the data from your application more easily shared with the other consuming applications that would benefit from getting your application data.

Could a PaaS deployment help solve these problems?

Perhaps but if you application was written in .NET, you will have a hard time finding PaaS offering that will support .NET. Why?

.NET was written by Microsoft a long time ago, in a world were PaaS didn’t exist. It was written to provide its developers above anything else…

CONTROL!

With ultimate control, you may take on more complexity but with that control you get the ability to really and truly control all the parts impacting the execution and performance of you application. Giving up this control to a predefined list of default decisions goes against the problems .NET was originally created to solve.

For this reason you will not commonly see .NET offered in PaaS offerings. If you are coding in .NET, you generally are rebuilding something that already exist and not rapidly developing something new. (I personally have never seen a startup chose .NET for their application stack from the start if they don’t have something already built).

When building something where decisions outside of your code and data really matter, default decisions made by PaaS will not be sufficient as little or no control of these details is possible. Small wonder the IaaS (Infrastructure as a Service) of Azure Compute Services, with all of it fine tuned control has emerged as the de facto choice for .NET developers.