Whether to commit to a port to .Net core
I was reading an article here about creating a dotnet core application using query processors, Entity-framework and a database, a fairly standard pattern for a REST api and something that got me thinking about a higher-level question:
You see, our industry is fast-moving and there is often a business conflict between the needs for stability that increase value in a market that favours reliability compared to the sense of engineers to always be using the latest/best/fastest/well-supported framework.
There are certain facts that are certainly true about dotnet core, and these drove a large part of our decision to port a dotnet 45 application to dotnet core.
It is much more portable than the dotnet framework due to its better abstraction of a web server into the host and the server - a separation that has long been hard to understand when even the phrase "web server" can mean the hardware or the software. Now for the first time, dotnet core can run on Linux with a large part of the functionality that is available on IIS and Windows.
Secondly, it has much better performance. This has been a combination of optimisations that have been made in .net itself, removal of some legacy code that was part of system.web and made virtually every web application include a massive codebase, whether it needed it or not. The last part is a much simpler and cleaner abstraction of the parts of the web application from some older "global" style methods to a more OO syntax, which makes it easier to only include what you need.
These and other reasons are all great but the question to port an existing application is a serious and potentially expensive, time consuming and even catastrophic decision if made incorrectly. The time taken is always much higher than our ballparks because the 90/10 rule comes into play: we get 90% done in 10% of the time and expect the rest to finish soon only to find that the last 10% - the hard bits - can take 90% of the overall time. The team that need to work on this, possibly also need to work on the current system, how long can you avoid updates and improvements on the current system to free up developers for the new system? If the system is a product, rather than an enabler, you probably don't have the luxury of sitting still for too long.
I also want to consider another pitfall for the porting and that is the question of whether I will actually benefit as a business from the porting process. Running on Linux for us? Not really a big deal right now. The nicer code is...nice..but is it much more than a slight improvement for developers? One of the biggest reasons to port was the performance increase.
For small companies, hosting costs are not insignificant. We spend about £2K/month on cloud costs, which is a lot less than hiring support staff in-house but it is still money and throwing hardware at a performance problem is great when you have a couple of million in the bank, otherwise getting more for less is attractive.
So we set about running a performance test: Dotnet 45 vs dotnet core vs node.js, something that is very popular and although a very different technology, I wanted to put some real figures behind the opinions people have about how "slow" .Net is compared to 'proper languages'.
The methodology was to remove as many variables as possible and to make a test app that performed the main operations of our real app: request - database operations - encryption - response. We built 3 versions of this, each including dependency injection and each designed to run on a linux VM being hit from another linux VM on the same server.
After fiddling with nginx settings to ensure we didn't hit thread limits, it turned out that although the node.js had a much smoother ramp-up with the number of requests, it also fell over at a lower level of requests per second. .Net 45, which we had to run on IIS because it's Windows, still only managed half as much as node whereas dotnet core managed a higher ultimate number of requests/per second than node, albeit with a much more erratic response time.
So we got to prove that the performance claims were not only true on paper but also in our case, on our kind of hardware doing our kind of work, it was also much faster than .net 45 (the previous system) and close enough to node.js so that we didn't need to take the much bigger step of rewriting everything in node (phew).
These are just some of the reasons that we need to consider and consider carefully when we decide to port from anything to anything else. It needs to be planned and executed well but on the other hand, plan to upgrade we must - there are probably no systems that we use that can be relied on for 5 or 10 years before they are very out-of-date so why not plan now how you will port in the future?
Is this something I should be doing now?
You see, our industry is fast-moving and there is often a business conflict between the needs for stability that increase value in a market that favours reliability compared to the sense of engineers to always be using the latest/best/fastest/well-supported framework.
There are certain facts that are certainly true about dotnet core, and these drove a large part of our decision to port a dotnet 45 application to dotnet core.
It is much more portable than the dotnet framework due to its better abstraction of a web server into the host and the server - a separation that has long been hard to understand when even the phrase "web server" can mean the hardware or the software. Now for the first time, dotnet core can run on Linux with a large part of the functionality that is available on IIS and Windows.
Secondly, it has much better performance. This has been a combination of optimisations that have been made in .net itself, removal of some legacy code that was part of system.web and made virtually every web application include a massive codebase, whether it needed it or not. The last part is a much simpler and cleaner abstraction of the parts of the web application from some older "global" style methods to a more OO syntax, which makes it easier to only include what you need.
These and other reasons are all great but the question to port an existing application is a serious and potentially expensive, time consuming and even catastrophic decision if made incorrectly. The time taken is always much higher than our ballparks because the 90/10 rule comes into play: we get 90% done in 10% of the time and expect the rest to finish soon only to find that the last 10% - the hard bits - can take 90% of the overall time. The team that need to work on this, possibly also need to work on the current system, how long can you avoid updates and improvements on the current system to free up developers for the new system? If the system is a product, rather than an enabler, you probably don't have the luxury of sitting still for too long.
I also want to consider another pitfall for the porting and that is the question of whether I will actually benefit as a business from the porting process. Running on Linux for us? Not really a big deal right now. The nicer code is...nice..but is it much more than a slight improvement for developers? One of the biggest reasons to port was the performance increase.
For small companies, hosting costs are not insignificant. We spend about £2K/month on cloud costs, which is a lot less than hiring support staff in-house but it is still money and throwing hardware at a performance problem is great when you have a couple of million in the bank, otherwise getting more for less is attractive.
So we set about running a performance test: Dotnet 45 vs dotnet core vs node.js, something that is very popular and although a very different technology, I wanted to put some real figures behind the opinions people have about how "slow" .Net is compared to 'proper languages'.
The methodology was to remove as many variables as possible and to make a test app that performed the main operations of our real app: request - database operations - encryption - response. We built 3 versions of this, each including dependency injection and each designed to run on a linux VM being hit from another linux VM on the same server.
After fiddling with nginx settings to ensure we didn't hit thread limits, it turned out that although the node.js had a much smoother ramp-up with the number of requests, it also fell over at a lower level of requests per second. .Net 45, which we had to run on IIS because it's Windows, still only managed half as much as node whereas dotnet core managed a higher ultimate number of requests/per second than node, albeit with a much more erratic response time.
So we got to prove that the performance claims were not only true on paper but also in our case, on our kind of hardware doing our kind of work, it was also much faster than .net 45 (the previous system) and close enough to node.js so that we didn't need to take the much bigger step of rewriting everything in node (phew).
These are just some of the reasons that we need to consider and consider carefully when we decide to port from anything to anything else. It needs to be planned and executed well but on the other hand, plan to upgrade we must - there are probably no systems that we use that can be relied on for 5 or 10 years before they are very out-of-date so why not plan now how you will port in the future?