Language is an Implementation Detail

Although everything about working at HPC is interesting, last week was quite peculiar on its own.

There was an interesting discussion about use of async pub-sub messaging for communications between micro-services. That's what Fred George does, for example, with event messages. However, command messages have their own value as well, due to the behaviour that we associate with them (only one message handler could deal with command messages, unlike event messages, where there could be 0 or more).

Yet, after a bit of discussions with Tomas, we discovered that introduction of command messaging breaks our nice decoupling with regards to ease of upgrades, experimenting or continuous delivery. Besides, if needed, you can always implement command messing within the boundaries of the service. This is possible, since we place a clear separation between high-level design decisions (the ones which talk about how mServices should behave and communicate) and implementation details (which govern how mServices should be actually implemented).

For example, here are some high-level design decisions:

  • Protocol for communications - JSON/HTML over HTTP in our case
  • Messaging semantics - async pub/sub in our case
  • Approaches for deployments, versioning them and experimenting with them - rapid iterations, A/B testing, using business metrics as the driver
  • Set of recommended languages and technologies - still evaluating (see below)
  • Design and development priorities - creating fun environment to work in, keeping things real, small and simple
  • Execution and hosting constraints - Linux, clustered in our own DC with geo-replication
  • Additional constraints - low latency and failure-tolerant

Curiously enough, we are still iterating through the suitable languages for implementing new version of HPC (while also addressing the design and domain questions). So for this week I'm going to spend more time learning Haskell (in addition to doing dives into Erlang and Golang during the previous weeks).

At the same point, our rewrite will probably start in .NET with micro-services design. Reason for that being - .NET, despite it's shortcomings and costs is the language where we all would be most productive and could release initial versions fast. This is crucial for gaining real-world feedback for evolving the system.

Then, as the need arises, micro-services will be rewritten in one of more Linux-friendly functional languages to:

  • Save on licensing costs.
  • Improve performance and reduce latency.
  • Make code more simple and concise.
  • Stand on the shoulders of giants, reusing ecosystem and communities of languages we choose.

In other words, languages are treated just like implementation details of the system. Even though there are some recommendations and guidelines, developers should be able to choose the tool they want in order to get the job done in the most efficient way.

- by .