Engineers are always experimenting with new technologies. We embarked on the frontier of new and exciting technologies earlier this year when we formed the "Tinman" team to build our Bare Metal offering on CenturyLink Cloud.

Bare Metal has a few moving parts, but the main piece is the "Tinman" web application that manages our pool of physical servers. Faced with the overwhelming decision about which technology should power this app, we ultimately decided to use Microsoft's new ASP.NET 5 + DNX runtime.

We have been using this bleeding-edge technology for over six months and want to share our experience so far. This post is the first in a series of posts which will include:

  • Why we chose ASP.NET 5 (this post)
  • Failing with ASP.NET 5 + Mono + Linux + Docker
  • Deploying ASP.NET 5 web applications on Windows with zero downtime
  • Where we're going next

In this first post, we will cover the burning question: "Why the heck did they pick ASP.NET 5?"

I'll answer that in two parts. I'll go over the factors we use when picking a project's technology, and how we utilized that data to ultimately choose ASP.NET 5.

How to decide on a technology

Teams have to weigh several factors when choosing a project's underlying technology. Some factors are technical and others are organizational.

The technical factors include:

  • Fitness for purpose: Which technologies fit the problem space? Which ones don't?
  • Tooling support: What tooling surrounds the technology? What are its most common editors/IDEs? Is there good refactoring support? Is it strongly typed or dynamically typed?
  • Online community: What community surrounds the technology? Are there clear places to go for help? Are there active open source projects using the technology? Is there a healthy package ecosystem?
  • Operational cost: CenturyLink engineering teams run the services they build. How does the technology impact operations? Does it help or hurt running/troubleshooting the service in production?
  • Track record: Is the technology proven in production systems? If it's bleeding edge, how "bleeding" is it?
  • Code reuse: Does your organization have libraries written in a technology that would be helpful to the project? Does the Open Source community have libraries in a technology that would be helpful to the project?

The organizational factors include:

  • Team improvement: What does the team want to learn? What tools does it want to add to its tool belt?
  • Learning overhead: Balanced with team improvement, what expertise does the team already have? Does the project timeline account for learning? What will cause too much learning overhead?
  • Team morale: Developers need to be engaged. Will using a familiar technology make people bored? Will using an unfamiliar technology frustrate people?
  • Transferability: If other people join the team, what's the onboarding cost? If another team takes over the project, what's their onboarding cost?
  • Hiring: Will this technology make it easier or harder to hire great talent?

So how did these factors influence our decision?

Our decision

Our intuition about many of these factors made ASP.NET 5 an attractive option to try versus other potential options like Node.JS or GO, which some of our other teams actively use and like.

If I retro-fit our intuition into the rubric above, it would go something like this:

Technical factors:

  • Fitness for purpose: There are dozens, if not hundreds, of options for writing a web application. Top contenders for us were ones that are currently used at CenturyLink: .NET, ASP.NET 5 + DNX, Node.JS, and Go None of our developers had any experience in Go, so we didn't consider it very strongly. So it was really a contest between .NET, ASP.NET 5 + DNX, and Node.JS.
  • Tooling support: As much as we sometimes curse at Visual Studio, it's a phenomenal tool. Especially when you put things like ReSharper tool on top. We also generally prefer strongly typed languages because compilers catch a lot of problems make refactoring way easier. So +1 for .NET or ASP.NET 5.
  • Online community: Plain ol' .NET and Node have a lot of online support and open source projects. Node likely has an edge. .NET has NuGet, and Node has npm. What surprised us was how much ASP.NET 5 + DNX improved in the online community space. Their code was all available open source, they had dedicated chat channels for support, and their package management was much more streamlined like Node.
  • Operational cost: Plain ol' .NET will always lose in an operations debate. It runs on Windows (we heart Linux for ops) and can be clunky to package, run, and deploy something. Node clearly wins compared to Plain ol' .NET. But what about ASP.NET 5? We were ecstatic to learn they would be targeting all platforms with the DNX runtime, and that they'd allow deployments from source with just in time compilation. So we'd get all of the benefits of .NET and none of the baggage of Windows and .NET deployments? Sign us up!
  • Track record: .NET and Node have great track records. ASP.NET 5 has none. But we were willing to take the risk given the full weight and support of Microsoft behind it.
  • Code reuse: CenturyLink Cloud's legacy projects are mostly plain ol' .NET, which means several years of development have produced helpful libraries that multiple projects use. We wanted to use these libraries, so that gave an edge to .NET and ASP.NET 5.


Organizational factors:

  • Team improvement: The engineers on Tinman love to learn new things, so we were eager to try something new for this project. Being able to learn something new and use technology we liked made ASP.NET 5 really attractive, especially when we could do .NET on Linux!
  • Learning overhead: The team already had .NET expertise with a little bit of Node experience. ASP.NET 5 seemed like a good balance of learning something new and taking advantage of existing expertise.
  • Team morale: We wanted to try something new, so sticking with Plain ol' .NET would have hurt our morale.
  • Transferability: Node would have been the least transferable of the options, but Node is so simple it wouldn't have been that bad. Given the strong .NET background of most of the engineers in our building, plain ol' .NET and ASP.NET 5 held an edge here.
  • Hiring: This one is tricky. Our building is in Microsoft's shadow, so .NET is attractive to people in the Microsoft community. At the same time, .NET can also be a hindrance to hiring developers more versed in the open source/Linux world. ASP.NET 5 seemed to provide a good middle ground because although it is .NET, is is open source and runs on Linux.

ASP.NET 5 + DNX: A healthy balance

Given all of those factors, ASP.NET 5 provided an attractive, balanced option. We could use the team's expertise, code on tools we love, learn something new, AND run on Linux! What's not to love?

Stay tuned for our next post on how our wildest Linux dreams didn't come true.