C# ASP.NET with SQLServer on Docker and Linux is now “A Thing™”

by simbo1905

Those of you who have been following along will know that Scala on Linux is my preferred ecosystem. This past few weeks in the office I have been tinkering with the opensource C# ASP.NET ecosystem. What I came across shocked me to the dotnet core. I have posted some evidence of my findings up on GitHub

This past year I have been involved with a big digital delivery with a half dozen scrum teams building a platform with C# ASP.NET on Azure. Out of curiosity in mid-2016 I fired up the latest FOSS DotNet tools on my Mac Book Pro and tried to open one of the smallest microservice projects. Neither the open source “Visual Studio Code” IDE, nor the open source DotNet command-line build tool, could read the project metadata. You needed full-fat Visual Studio 2015 on Windows to compile and debug the code. The drop in productivity in switching IDEs and tooling would be a deal breaker to the in-flight agile teams. I shook my head, deleted the code base from my Mac, and had a cynical thought that the lack of interoperability was deliberate. I was wrong. 

April 2017 it is a whole other bag of ferrets. Microsoft surpassed Google for the number of opensource contributors on GitHub. Microsoft open-sourced their full-fat build tool engine used by Visual Studio called MSBuild. You can now build main line Visual Studio authored projects on the command line within Mac OS or with Jenkins on Linux. The FOSS IDE “Visual Studio Code” can now mature fast by embedding the same build library as the commercial IDE. 

The community edition of “Visual Studio 2017 CE” is still stuck on Windows but is free of charge. Visual Studio CE has templates for building and running opensource DotNet core apps into Docker containers. This means that running CE under parallels on my Mac is low cost. 

Microsoft SQLServer is coming to Linux and you can run an official docker image to run a SQLServer database on your Mac OS or Linux machine. I literally turned to a colleague at the office and told them my mind was blown when I watched this short video talking about the roadmap of SQLServer on Linux.

All of which meant that I was able to port the official DotNet core demo app which uses SQLServer into OpenShift Origin PaaS and put it up on GitHub. The main challenge was that things have moved so fast that google serves up out of date blogs and documentation that imply it is still all a bit too difficult. I went down many rabbit holes before I found out that it really wasn’t that hard as Microsoft have gone all-in on Docker.

This following snippet finally opened my eyes as to the fact that Microsoft had made the big leap. In case you are not familiar with ASP.NET or Entity Framework they are the C# web MVC and ORM frameworks:

Just prior to press time, Microsoft announced name changes to ASP.NET 5 and related stacks. ASP.NET 5 is now ASP.NET Core 1.0. Entity Framework (EF) 7 is now Entity Framework (EF) Core 1.0. The ASP.NET 5 and EF7 packages and namespaces will change, but otherwise the new nomenclature has no impact on the lessons of this article.

Essential .NET – Configuration in .NET Core

Which is to say that ASP.NET Core 1.0 or Entity Framework Core 1.0 are not some “port to Linux” a side team is doing after new features have shipped on Windows. They are actually the main line products upgraded to run across platforms. They are now being developed in the open on GitHub. Swapping out the current windows only versions to the new “core” versions isn’t a swap at all: it is simply upgrading to the next major release of the same codebase.

CORRECTION: The EF Core 1.1 docs say

EF Core 1.1 is the latest version of EF but does not yet have all the features of EF 6.x. https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/intro

It cannot be an upgrade if there are missing features! The docs clearly indicate that you have to port to EF Core from the propriety EF6. 

I can almost feel some wry looks from my Scala and FOSS buddies out there. Most definitely if you have made the leap to Scala you won’t be looking to downgrade to Microsoft’s evolution of J++. Yet I would argue as a new entrant into the FOSS world the C# ecosystem has a massive advantage: if has one mature way of doing web MVC, one mature way to do ORM, one mature way for dependency injection, and configuration, and build, and the list goes on, and on, and on. It simply isn’t going to have the massive fragmentation that Java suffers from.

A case in point is that the Java community wanted a standard JSON parser in Java 9 but are not going to get it:

On a survey we conducted with 350 developers, the JSON API was just as hyped as Jigsaw but looks like it didn’t make the cut due to funding issues. Mark Reinhold, chief architect of the Java platform, on the JDK 9 mailing list:

“This JEP would be a useful addition to the platform but, in the grand scheme of things, it’s not as important as the other features that Oracle is funding, or considering funding, for JDK 9. We may reconsider this JEP for JDK 10 or a later release. ”

http://blog.takipi.com/5-features-in-java-9-that-will-change-how-you-develop-software-and-2-that-wont/

All the choice of 3rd party FOSS JSON parsers in the Java world when there isn’t a reasonable default settings in the platform isn’t a strength it is a productivity drain. Larger systems used to end up with three different XML parsers with version conflicts. Now we have the same mess with JSON parsers. In contrast ASP.NET is setup todo do RESTful things well and already has a standard mechanism for deserialization of JSON config into value objects. That takes away the reason for a typical large-scale microservices platform to end up using many 3rd party JSON parser across the estate. Whilst this trivial example isn’t by any means a “killer feature” its the sum total of many such little things which have a big effect on the performance of a large platform team over a long period of time.

Another trivial example is that there is a well document environment variable to specify the whether the app is deployed within a development or production environment. On large Java systems I have never seen any such obvious conventions be uniformly applied across every processes. Purists would say that in the new ear of “vagrant up” that is actually an anti-pattern; but on a large platform of 30 devs good luck stopping it from creeping into the codebase. It least its a choice between doing it consistently everywhere or not doing it at all. A better example would be that overriding application configuration and managing secrets is clearly document such that there is no reason to not have all microservices projects be consistent.

I know from talking to senior developers that Java folks find it easy to walk in and be a senior dev on a C# project but the opposite isn’t true. Senior C# developers fell like junior developers when they try to work on a real-world Java system as every large codebase has its own unique set of choices.

I know from talking to senior developers that Java folks find it easy to walk in and be a senior dev on a C# project but the opposite isn’t true. Senior C# developers fell like junior developers when they try to work on a real-world Java systems. This is because every large Java codebase has its own unique set of choices. With any C# team with more than three developers will collectively know and apply the majority fo the well-documented conventions. I suspect that a good FOSS Java developer can literally cram the DotNet demo apps over a weekend and on the Monday blag a jobs as a lead developer on a C# microservices gig and get away with it.

So I think that the coherence and completeness of the FOSS C# ecosystem gives it a big productivity edge over FOSS Java for larger long-term platform builds. Of course the UK Government microservices platform is Scala and I have worked on a 100+ developer Scala platform at an investment bank. So if it is a choice from three I can say that having seen all three ecosystem used at scale and I can highly recommend Scala as it is the most scalable language. My second choice used to be Java mainly because it was a FOSS ecosystem not because it gives high developer productivity.

The big question now is will Java up it’s game in response? Or is innovation in Java going to continue to slow down just when it is really starting to show it’s age compared to all the new kids on the block?