Reply to post: Re: Who needs to worry about efficiency in the cloud?

Re: Who needs to worry about efficiency in the cloud?

I'd say it's actually a bit more about cloud programming and architecture models encouraging less efficient programming. I'd point out first - it's not necessarily bad programming, but more focused on redundancy.

In our main cloud system we took a process that was previously a long running DB task, mostly synchronous single thread. We put it into a clustered environment (Service Fabric, though K8s would have been no different) and moved the processing into C#. We then had to cope with the new programming issue that services may stop at any point, and nodes can go down (and definitely do), so we needed to introduce persistent storage points throughout processing. Now that it's not running in the DB then there's an overhead to processing data that was previously done through table joins, so to counter this cost we split the processing out and allowed it to parallelise, but in doing so (as well as running multiple instances of the service) we needed to reproduce what would previously have been single in-process caches with a distributed cache, which then required that cached data to be further held in each process memory locally to reduce load on the distributed cache. Then we find the instability of the environment means we need to scale this to multi-region, which at the completely redundant level means running 2 versions of the system one in each Azure region we use. This meant 2 express routes, double the infrastructure costs generally, and for the system itself x2 every component.

So we went from 1 process in a DB to a 5 node cluster with multiple persistent storage points and complete redundant processing, we had to put (and pay for) load balancers in front of the new clustered services and tie into app insights for logging. We then had to double that cost to go multi-region. This is a better system, it never goes down and it is highly redundant and scalable. We haven't written inefficient code, but there are implicit cost overheads (both in code efficiency and in infrastructure) to performance and stability scale outs that mean this system is getting noticed as being significantly more expensive that the previous DB process.