Software design, or "Making it cheap on long run"

Some people write new software on a daily basis. When you build software, you may have to work with 4 main constraints:

• Customer needs
• End user hardware requirements
• Maintenability requirements
• Server hardware constraints

I will here focus on the last 2 constraints.

Optimization freak

Make it work, Make it clean, Make it fast, in that order

This motto of software programming bears 2 meanings:

• First is, focus on making your software work first no matter what, then clean stuff up, then if it is too slow, squeeze for performance.
• Second is, anything that works can be made clean then be optimized.

Now let's make it a case:

Some software developer wants to make a small website for managing photographies sales for a wedding photographer.
The developers wants to focus on making it simple and readable while creating it and chooses Ruby on Rails to make the application.
After 4 days of intense coding, the application is done.

Pretty quick to get the job done, the developer then hosts it on some cheap dedicated server, doing some automatic backups and some simple stuff, then presents his $1200 invoice for the development and the deployment and a $200 yearly invoice for the hosting management.

For 6 month, the developer no longer hears from the customer. On the meanwhile, the wedding photographer uploaded 12600 photographies in high resolution on the application for some 42 couples. Those photographies viewed by some 200 guests of each wedding through a few month, making nearly 3'780'000 queries to the Ruby on Rails app.
This makes 135'000 queries per daily peak hour of the app. The queries are generally 4MB to 16MB and make the latency of the application peak at 1.2s of latency per request.

This simple application for a small customer is starting to get outdated in 6 months: the customer complains the website is very slow despite him using a fiber internet connection.

To help with that, the developer offers to use a Redis cache to make all the reading requests faster. after a short day of work, a VPS is added to host the Redis cache and a reverse proxy, total: $240+$250 for the workload and VPS.

• Money increased.
• Customer satisfaction decreased.
• Workload increased.
• Complexity increased
• Hosting costs increased.

This process get worse and worse when scaling occurs.

The application was originally cheap, yet it yields in te end to low customer satisfaction and more expensive maintenance.

Thinking of tomorrows

Now what about the very same application developed in Crystal or in Node.JS?

First of all, caching becomes less useful. Performance is generally pretty good in those languages thanks to LLVM for one side, and the JIT compiler on the other. Serving the files can come at some 3k to 6k request per second. For the photographer case, it shift the bottleneck to the network.

But it also makes it possible to host multiple websites from customers on the same machine. And possibly to not do that if the load increases. And since programmatic level is not a bottleneck, scaling is easier to achieve.

It is admissible to have a raise in development price of 10% to 20%, yet on the long run it is possible for the customer to get that back.

It is also unlikely that any caching infrastructure is needed and adds more complexity to the application.