You may be familiar with Moore's law, which states that the number of transistors in a dense integrated circuit doubles every two years. In effect, that performance doubles every 24 months. For many years, that has been true. But that has not been the case in the last 10 years or so. Even when Moore's law was true, there was an obstacle. Wirth's law is also in force (aside, read his article "A Plea for Lean Software", 23 years, and still in force today) and Wirth's law states that software is slowing down faster than hardware It is getting faster. It is good to be a software developer, because even when the speed of the CPU clock does not jump all the time, we still have more CPU to play. A common approach to managing performance problems today is simply to throw more parallelism to the problem until it closes.
Up to a point, this makes perfect economic sense. In calculating between developer salaries and the cost of hardware, you will generally find that buying a couple of additional servers is drastically cheaper than spending another 6 months to improve system performance. Jeff Atwood wrote about it a decade ago and I think it's still very correct, to a certain extent. There are other factors to consider, which are overhead over time and in particular in the cloud. One of the main factors to keep in mind here is that when you run in the cloud, it does not run on your servers and you are charged for the use. That can change the maths a lot.
For example, if I bought a pair of servers, the amount of I / O operations that I carry out has no meaning for me. If I hit the record ten times per second or ten thousand times per second, I am paying the same cost. Oh, sure, I might need to buy a better hard drive to get 10,000 IOPS, but that's a one-time cost, and it's generally not that significant in the grand scheme of things. But when it's in the cloud, getting higher IOPS costs more and costs more over time. In the same sense, in my data center, the cost of consulting a database is zero. In the cloud, you will normally be charged a (lowercase) amount per query. There's nothing to worry about, except that your software still works according to Wirth's law, so you're doing more consultations than you should, which means you'll be charged for each of them.
I used to earn a living as a database performance consultant. I would go to a client, observe how they use their database and optimize the access pattern. It was common to see savings of more than 90% in the number of consultations for common operations. I was doing it because that translated directly into a better response capacity of the application. Applications that respond faster are more pleasant to use and there are numerous studies on faster applications that generate higher revenues. I remember talking to clients and explaining to them why they should invest in the overall performance of the application before they reach the total exhaustion of resources that would lead them to the downside.
Today, in the cloud, I would have a much simpler task. Let's assume a simple application using CosmosDB, as an example. With 200 page views / sec on the site, and each page view generates 80 requests to the database, which gives us a total of 16,000 requests per second, which translates into an end-of-month bill of approximately 10,000 $. I'm using the 80 queries / page views as a reasonable estimate of the baseball, seriously. Drupal, for example, performs 300 to 400 queries per page, and it is easy to reach these numbers without paying attention. Decreasing the number of queries per page to 10 (which is usually pretty easy to do with the right queries, attention to detail and a little bit of caching) gives you a database invoice of around $ 1,000.
Over the course of a year, that's enough to pay a full-time developer who can go and look for other places where they can improve their software. And unlike the previous, it is not necessary to justify with studies or any indirect cause. You can point directly to the bottom line on an invoice and show how much money is saved.
0 Comments