Decision about .NET

My first introduction to .NET was in the early alpha days, back in the early 2000s. In nearly the two decades that have passed since, it has matured into a very powerful platform.
.NET as a platform has always had a great deal of polish that I haven't been able to find anywhere else. The ease of use and general technical excellence of the platform meant that I was delivering value at a consistent rate and with relatively little trouble.

That didn't make anything perfect, of course. The closed nature and the single platform that .NET was traditionally limited to took their toll. In particular, a bug fix that you found and reported might be fixed in the next release (18 months away) or not, with very little input or ability to understand what was going on.

And then the CoreCLR came along. In 2015, we made the decision to move the all of our applications and code into the CoreCLR.

That has been an amazing experience. The fact that I can dive into the source directly has made things so much simpler, and the fact that you can submit patches and interact directly with the core team has been an absolute joy.
Our company has contributed several times (some code and mostly some interesting bug reproductions and perf issues) and has been continuously at awe at the level of commitment and (I have no other word) grace that we get from the team.

The fact that we can now run .NET code (and our product) on Windows, Linux, Raspberry PI(!) and Mac has been a great boon to us. We recently deployed our software to a whole lot of industrial robots running custom ARM boards.
That is something that would have just been unimaginable every as much as five years ago.

In pretty much respects, the overall community, the core team, the engineering quality and the fact that it brings the polish that I've gotten so used to in environments where you are generally left cobbling things all by yourself means that it is my platform of choice for projects big and small.

The core Web application of Raygun is still a Microsoft ASP.NET MVC application. Not too much has changed from a fundamental technology standpoint. We originally built using Mono, which just bled memory and would need to be constantly recycled. So we looked around at the options and what would be well suited to the highly transactional nature of our API. We settled on Node.js, feeling that the event loop model worked well given the lightweight workload of each message being processed. This served us well for several years.

When we started to look at .NET Core in early 2016, it became quite obvious that being able to asynchronously hand off to our queuing service greatly improved throughput. Unfortunately, at the time, Node.js didn’t provide an easy mechanism to do this, while .NET Core had great concurrency capabilities from day one. This meant that our servers spent less time blocking on the hand off, and could start processing the next inbound message. This was the core component of the performance improvement.

We chose .NET because it was a platform that our team was familiar with. Also we were skilled enough with it to know many performance tips and tricks to get the most from it. Due to this experience, it helped us get to market faster and deliver great performance.

There’s no doubt WordPress is a great CMS, which is very user friendly. When we started the company, our blog wasn’t really our top priority, and it ended up being hosted on a fairly obscure server within our setup, which didn’t really change much until recently when things become harder to manage and make significant updates.

As our marketing team increased, the amount of traffic that found us through our content marketing increased. We found ourselves struggling to maintain our Wordpress install given the amount of theme updates, plugins and security patches needing to be applied. Our biggest driver to find an alternative solution however was just how slow Wordpress is at serving content to the end user. I know there will be die hard fans out there with ways to set things up that mean WordPress sites can load quickly, but we needed something a lot more streamlined.

We could see in our own Real User Monitoring tool that many users were experiencing page load speeds of over five seconds, even longer in worst case scenarios.
Hugo is an open source static site generator that has enabled us to reduce load times by over 500% and make our blog far more maintainable across the whole team.

The Raygun marketing site runs on a .NET CMS called N2 but we plan to swap that out with Hugo as well in future.

Our first experience with .NET core was when we developed our OSS feature management platform - Tweek (https://github.com/soluto/tweek).
We wanted to create a solution that is able to run anywhere (super important for OSS), has excellent performance characteristics and can fit in a multi-container architecture.
We decided to implement our rule engine processor in F# , our main service was implemented in C# and other components were built using JavaScript / TypeScript and Go.

Visual Studio Code worked really well for us as well, it worked well with all our polyglot services and the .Net core integration had great cross-platform developer experience (to be fair, F# was a bit trickier) - actually, each of our team members used a different OS (Ubuntu, macos, windows).
Our production deployment ran for a time on Docker Swarm until we've decided to adopt Kubernetes with almost seamless migration process.

After our positive experience of running .Net core workloads in containers and developing Tweek's .Net services on non-windows machines, C# had gained back some of its popularity (originally lost to Node.js), and other teams have been using it for developing microservices, k8s sidecars (like https://github.com/Soluto/airbag), cli tools, serverless functions and other projects...

When designing the architecture for #Configcat , we were dreaming of a system that runs on a small scale on low-cost infrastructure at the beginning and scales well later on when the requirements change. Should be platform independent, high performing and robust at the same time. Since most of our team were born and raised using Microsoft's enterprise-grade technologies in the last decade, we wanted to build on that experience. Finding the best solution was quite challenging. Finally, we came up with the idea of a .NET Core backend because it runs on all platforms highly scalable and we could start up with 5$ Linode Linux server. As a #frontend framework, we have chosen Angular mostly because of TypeScript which felt familiar and was easy to get used to after strongly typed languages like C# and the community support behind Angular 2 is awesome. Visual Studio Code makes the coding sessions with Live Share great fun and very productive. MySQL as a database is again is very affordable in the beginning, performs great a scales well and integrates with .NET Core's Entity Framework super easy.

When starting a new company and building a new product w/ limited engineering we chose to optimize for expertise and rapid development, landing on Rails API, w/ AngularJS on the front.

The reality is that we're building a CRUD app, so we considered going w/ vanilla Rails MVC to optimize velocity early on (it may not be sexy, but it gets the job done). Instead, we opted to split the codebase to allow for a richer front-end experience, focus on skill specificity when hiring, and give us the flexibility to be consumed by multiple clients in the future.

We also considered .NET core or Node.js for the API layer, and React on the front-end, but our experiences dealing with mature Node APIs and the rapid-fire changes that comes with state management in React-land put us off, given our level of experience with those tools.

We're using GitHub and Trello to track issues and projects, and a plethora of other tools to help the operational team, like Zapier, MailChimp, Google Drive with some basic Vue.js & HTML5 apps for smaller internal-facing web projects.

Decision about PHP, .NET, JavaScript, Node.js

Node.js is my choice because it uses very few resources to run and it is capable to handle tons of connections simultaneously. Most developers already know JavaScript, the evolution of ECMAScript is immediately reflected to Node.js and all you have to do is update your Server's Node.js version without time and effort. Thousands of improvements that makes it very powerful especially in asynchronous programming. The web is full of courses, dev communities, free sample code, plunkers and many knowledge sources on Node.js that facilitates the learning curve. What else we can ask from a legendary language that is still evolving?
I am learning Node.js by developing a simple REST WebAPI and using it as a playground to test situations in which the main objective is to challenge Node.js and compare results and performance with .NET implementations and certain well known fast PHP implementations. Until now the results are astonishing.
Summarizing: Node.js for backend is so far (in my opinion) the most recommended solution to get positive achievements in size, speed, power, concurrency, scalability, deployment and running costs.

5 upvotes·2.6K views

Decision at GivePenny about Azure Kubernetes Service, .NET

Context: GivePenny is the charity sponsorship platform for the modern world. We are re-platforming onto .NET Core-based microservices and ReactJS-based micro-frontends in Docker containers hosted on Azure Kubernetes Service.

We use .NET Core because of the easily attainable high quality bar for our microservices. We love the succinct yet clear C# language making code easy to read. We rate the advantages of the strongly-typed aspect of C# and of compiled (so type-checked) unit tests in a "backend" service context. The test stack and tooling support in Visual Studio around service tests, contract management, unit tests, web APIs and publish/subscribe message handlers is easy to work with. The easy integration between Visual Studio and Azure Resource Manager based infrastructure, Azure DevOps, Nuget and Docker makes build, publishing, release and hosting very easy. The cross-platform nature of .NET Core allows Windows and Linux developers to co-exist and services to be hosted on multiple platforms.