Platforms come in different levels of abstraction ranging from general to very specialized. The combination of an operating system and a CPU is a classic example of a general platform. In this environment developers can make use of the system calls provided by the operating system and the hardware instructions provided by the CPU. ^[1]

React Native, on the other hand, is much more specialized. It enables cross-device mobile development, but at the same time forces you to use a specific programming language and framework.

The remainder of this article presents a case study where the software platform caused more ill than good. It is always easy to criticize decisions in retrospect, so please take it with a grain of salt.

Case study

One of my clients made a platform decision roughly two years before I joined the project. They chose between different existing software solutions and selected the most customizable one. The solution consists of a service providing an API and a user-facing service, which can be extended via a plugin mechanism. Both of them should be run on a Kubernetes cluster.

Two years after the initial platform choice, the situation was grim: The result was high-maintenance software that failed to reliably fulfill two relatively simple business processes. Consequently, the team was frustrated and pressure from the business increased.

I am confident that I identified the main pain-points: Neither software is suited for operations in a Kubernetes cluster. Each product comes with it's own technology stack. Each stack has to be packaged individually for Kubernetes, which leads to high operational cost, especially for software upgrades. All this leads to high operational complexity.

Even though the software can be extended via custom plugins, there exists no proper development environment for that. The software cannot be started locally due to the way it is packaged. Developers therefore work inside a virtual machine. Setting up set virtual machine requires a different set of tools than the productive environment of the application. This increases the number of tools a developer has to learn and slows down the development process. Call it a high complexity of development, if you will. Additionally, the development and production environments are very far apart from each other. This means that software bugs are generally discovered late in the process. The later a bug is discovered in the release process, the more expensive it is.

My team an I tackled this problem by moving existing functionality to new software services. It turned out that these services were extremely reliable and had low maintenance cost compared to the previous system. This means that all new code will have a much lower complexity of development. The services had little to no dependencies on the existing platform which paved the way for reductions of operational complexity as well.

Lessons learned

If I were to give advice on platform choices, it would boil down to the following points:

• Given the impact of the platform decision, it pays off to have an extensive evaluation period
• Platform decisions are easier to change early on. As soon as you discover that a platform is unsuited for your purposes, ditch it. You will likely have an easier time explaining why a platform decision needs to be reverted than having to work around its quirks and limitations for months or years to come.
• When you decide to buy a software product, be wary of vendor lock-in. Their software support is quick to respond with "this configuration is not supported", which forces you to work around it. Note that once their software product is part of your platform, it is usually very expensive to get rid of it.
• Prefer battle-tested technology over current hypes. Maybe a monolithic architecture will suffice and you don't need microservices or a Kubernetes cluster.

---

1. Generally, I have the impression that platform decisions are made more consciously in the hardware-focused space as compared to the software space. ↩︎