Lessons learnt: don’t choose the wrong technology

One of the most important advancements in software development lately has been the shift to asynchronous design patterns within a variety of software languages.

Since we’ve named our fledgling company after this mechanism, it seems appropriate that we explain the importance of choosing the right technology for the job.

The right tools for the job. Library and Archives Canada

The right tools for the job.

Before we focus on the specifics when choosing the appropriate language its important to note that by tolerating poor technology choices early on in a project can cause massive technical debt. It’s an obvious point to make but something we feel very strong about. When that product needs scaling/maintenance/migrating the debt can sometimes feel like a total rewrite is needed (which is never a good idea) !

Put simply, the presence of asynchrony means the program doesn’t get held up (blocked) waiting for requests (to the outside network or disk) to complete. It is generally considered essential in user interfaces (as the whole program or app would appear to freeze), its presence in server side distributed architecture is as you might have guessed fundamental .

Using a language with async support built in is increasingly looking essential to allow processes and services to scale. Node.js is the clear leader in this field with JavaScript being totally event driven and async from the start. Other languages, such as recent versions of C# have (somewhat) successfully implemented async methodologies in the language after the fact. Golang has an interesting take on this mechanism via its channels and goroutines. One of the drawbacks of the Ruby on Rails (RoR) ecosphere is the absence of this language feature. A common work around is to use message queues (for everything!) but this in itself can be painful to maintain and cumbersome to troubleshoot and debug issues. It could be one of the reasons why there seems to be a move away from RoR to more modern Node.js frameworks like Express.

What about other languages such as Java and PHP? Effectively, it is much more difficult to implement this design pattern, which leads to slower performance and making the application much more difficult to scale.

This not only has to do with the language you choose, it also directly effects the choice of message queue, database and your choice hosting provider. While many developers might be happy with the easy option of using the message queue they are most used to, the question is will it scale appropriately if under massive load for the use-case at hand. That is why we are seeing a shift towards technologies such as Apache Kafka, database solutions such as Elasticsearch that auto shard and cloud PaaS providers who actually can scale when your product needs it to.

If your product will need to scale then consider your chosen technologies carefully at the beginning of a project. We are sure that you would agree that to incur a metric tonne of technical debt early on in the lifecycle a product is the last thing you need when it comes to maintaining it.