Lukáš Linhart

Choosing technologies

written by Almad

Every other week, some of my technology problems are magically solved by some new service, language or database. Except when aren't.

While there definitely is a progress in technology, theoretical breakthroughs are more rare than everyone would like to. Instead, we do have a list of constraints and trade-offs that are changing over time, and they enable different set of technologies.

As an example:

  • L-cache is the only way to cache data, everything else is too slow! Except it got faster, so use that, but store everything on disk because RAM is super small. But now it got large enough to store useful datasets, so don't even dare to think about touching disk! Oh wait, SSD
  • Disk may be slow comparably to RAM, but with reasonably stable I/O latency. Dang, have you seen those spikes on our virtualisation platform? Let's rewrite everything! Oh, containers
  • Our database must be always consistent and don't store any duplicate data, 3NF is the king. Oh wait, count performance. Distributed datacenters and availability, OK
  • Nodes are cold, stable hardware and we can rely on it. Oh wait, cloud. Elastic scaling, neat

Most of those are environment changes, caused by:

  • Uneven hardware improvements (SSD changing speed/size ratio; multi-core changing single process speed vs. parallelism; GPU offering whole new field for some types of computations)
  • Price changes (cloud vs. on-premise, on-demand pricing)
  • Technology usability causing mass adoption(jail and LXC vs. Docker)

However, those technologies rely on the new changed environment, which usually presents some change in available trade-offs.

The same is true for growing your technology and company. When describing technologies or processes, most people still fail to talk about the scale they are talking at (I still surprise a lot of people with how small 37signals/Basecamp is; a lot of people assume enterprise with hundreds of people, and ReWork being battle-tested at that scale).

This is a major failure, because (current and expected) scale is one of the most defining characteristics. Premature scaling can kill you as much as scaling too late:

  • Initially, you prefer moving fast over externalising things. Later, you need to externalise in order to move forward
  • At the beginning, everything-as-a-service is definitely cheaper; over time, you hit breaking points
  • Structure of your traffic is crucial for your infrastructure, and changes over time. Read or Write heavy? Cache hit ratio? Both matter

Only thing you can rely on is speed of light. Latency is not going to be any better in the future: beware of being chatty on critical path.

When choosing technologies, always be aware of the shift you are making. If you are unaware of any, downside will hit you hard.

Published on 2016-02-08