Values

1. Must fit our Micro-services Strategy
2. Per #1, must run on Docker/Linux
3. The platform must have a future / healthy ecosystem
4. Must provide tangible benefits w.r.t. code quality, development lifecycle
5. Provide a pathway for the team to transition

Ask the question: "What do we gain by adopting this strategy? What do we lose if we uphold the status quo?"

Why Linux/Docker?

Microsoft's has their own implementation of docker containers, which comes in essentially two flavors worth discussing in this context: Server Core and Nano Server.

Nano Server not a "full" or "complete" edition of Windows. It is optimized specifically* for .NET Core applications (cannot run full .NET framework). Many perceived benefits of running on Windows do not apply.

https://docs.microsoft.com/en-us/windows-server/get-started/nano-in-semi-annual-channel

https://docs.microsoft.com/en-us/windows-server/get-started/getting-started-with-nano-server

Despite its smaller size, Nano Server's system requirements are not very competitive and software must be designed/rewritten (by Microsoft) to run on it.

http://www.techradar.com/news/software/operating-systems/why-nano-server-is-the-most-vital-change-to-windows-server-since-windows-nt-3-5-1295803

https://blogs.technet.microsoft.com/nanoserver/2016/06/24/nano-server-boot-performance/

Why Linux/Docker?

Contrast this against Alpine Linux for Node.js:

https://github.com/gliderlabs/docker-alpine/tree/d751bb2bcacd2a6536280cdc7d313bc6584aa40e

Nano Server

Alpine Linux + Node.js + Yarn + NPM

• 512-800MB RAM*
• 410MB on disk*
• 9 seconds to boot*

• 236KiB RAM on boot (OS only)
• 66MB on disk (the OS is 5-8MB)
• Nearly instant boot in Docker container

*These are Microsoft's recommendations/test results, I have not verified them

https://blogs.technet.microsoft.com/nanoserver/2016/06/24/nano-server-boot-performance/

Why Linux/Docker?

Why not Server Core?

Docker brings us lightweight abstractions so spinning up and deploying n services and breaking up monoliths isn't painful and makes running the entire infrastructure on one developer machine possible.

Server Core heads the opposite direction, bringing a full-fledged Windows operating system requiring 10GB of disk space just to start, with no features installed.

https://blog.docker.com/2016/09/dockerforws2016/

Options

• "Full" .NET does not run on Linux/Docker
• .NET Core / C#*
• Mono / C#, F#
• node / JavaScript
• node / compile-to-JS

Our team has experience with C# and JavaScript

If we explore outside of our comfort zone, there are many other compelling options with 1st class support on Docker.

.NET Core

• API still undergoing major changes, documentation/blog posts out of date, samples did not work OOB
• Took much more effort than expected to get things working (ie: HTTPS, OAUTH)
• .NET Core templates seem to have significant ceremony around docker deployment and configuration, which seems coupled to VS proper.
• Can't re-use existing .NET ecosystem unless it's been updated/recompiled for .NET Core
• Unaware of significant adoption of this platform (ie: ~8.6-17.3k occurrences of "dotnet new" command/month vs say, 17million downloads of express.js, just one library)

Second production project I've worked on where we tried and abandoned .NET Core.

https://blogs.msdn.microsoft.com/dotnet/2017/07/21/what-weve-learned-from-net-core-sdk-telemetry/

https://www.npmjs.com/package/express

Mono

Mono is a 3rd party re-implementation of the full .NET framework. It is missing some pieces (ie: some WCF, Windows Identity), but is mostly full-featured.

Past experience with Mono suggests it may have slight differences in the implementation which could lead to surprising/unpredictable issues in production (ie: GC implementation, encryption, ODBC/ADO.NET, XML Serializer).

Nonetheless, our impression is that Mono has wider and longer lasting adoption than .NET Core.

Now that Microsoft is committed to bringing .NET Core to open source, it may be time for adopters of Mono to reevaluate.

http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

https://stackoverflow.com/questions/37738106/net-core-vs-mono

node/JavaScript (JS)

Node comes from Joyent (and OSS contributors) and has existed for 8+ years (since May 2009).
Node.js builds on the V8 JS engine developed by Google.

Node allows the use of the de facto language of the web (JS) and leverages the largest package repository (npm).

//TODO: citations

The downside is that JS' dynamic, free-form nature is also a weakness. To improve code quality we leverage strategies and additional tooling, sometimes working against the grain:

• Linting
• Type checking/annotations
• Breaking up JS files into small, explicit modules
• Unit testing
• FP techniques (immutable data, pure functions, separating logic from side effects, etc.)

node/compile-to-JS

Most any general-purpose programming language can be compiled to JS, including C#. When selecting a language, we'd like some combination of these qualities...

• Familiar or easy to gain proficiency
• Good tooling (ie: IDE support, compiler)
• Good documentation/community support (StackOverflow, egghead.io, PluralSight, blogs, healthy momentum, etc.)
• Healthy ecosystem (what does it bring that we can leverage? what problems have been solved with it?)
• Modern, ie: first-class/facilitates composing functions, immutable data, algebraic type system
• Good fit for our problem set (cross-platform web applications)
• Interops well with existing JS libraries (ie: bindings, frameworks)

node/compile-to-JS

Some of the FP friendly or prominent languages that compile to JS include:

• TypeScript/Flow (included for completeness)
• PureScript
• F#/Fable
• Elm
• Reason
• ElixirScript
• Dart
• ClojureScript

I've omitted OCaml/BuckleScript in favor of Reason and Haskell/GHCjs in favor of PureScript.

node/compile-to-JS

//TODO: dive into the options available