akeno tech radar
Discover the tools and technologies that shape how we build at akeno.
Docker Compose instead of being cloud-native
While our tech stack in many aspects is fairly standard and matches what many other web-based applications use (e.g. React, Nest.js, Tailwind CSS, PostgreSQL), the sensitive nature of our customers’ data mandates that our product runs within each customer’s intranet … and therefore in whatever environment the customer already has. Instead of being just one more tenant within a shared cloud-based solution, each customer site has their own isolated instance of our product. So by necessity, our product has to be agnostic to AWS, Azure, Google Cloud, and their likes.
So far, we’re able to use what is likely the simplest solution possible: docker compose. Our customers provide us with one or more VMs and can choose if they want the databases to be managed by us or simply use pre-existing database servers they have in their infrastructure. We use Terraform to facilitate the deployment and perform the customer specific configurations, but all customers use the same docker images.
While this means that we can’t utilize provider-based services such as AWS RDS, CloudWatch, or SQS, this setup has many positive aspects. Everything by design runs locally on developer machines, no advanced infrastructure skills are needed for most of the engineers, and in general the complexity of the system is greatly simplified. While
we might consider the usage of Kubernetes at some point in the future, we are happy our setup works nicely even without it and we were able to avoid the added complexity.
The result is a setup that is easy for developers to work with and straight forward to deploy to customers.
Scalability in data vs scalability in users
While we handle large amounts of data and perform complex calculations on them, the number of users per customer site is relatively small compared to for example a publicly accessible e-commerce site. And since we have dedicated systems per site, we can avoid many of the scaling headaches and orchestration problems other companies constantly deal with. As a result, scaling is only relevant for us in the number of customer sites (i.e. how easy is the product to set up and maintain) and amounts of data (i.e. how reactive is our application while showing complex data, how long do calculations take), not in number of users.
We therefore simply don’t have the typical scaling challenges cloud-based SaaS products have. We do not need to optimize render performance for SEO, we’re not exposed to denial-of-service attacks, system loads do not suddenly spike, database run out of cache or storage space, and so on. However, we always need to be able to visualize and process large amounts of complex data without slowing our users down. Being able to make quick, informed decisions is key for our users as the consequences of those decisions can quickly sum up to millions of Euros generated or saved.
Reliability & trust
One of the key concerns for us is preserving the high level of trust we have earned with our customers. Automatic testing of course plays a key role for this and we follow a strategy of end-2-end and API level integration tests to ensure correct behavior rather than excessive component and unit testing (which tend to focus on irrelevant implementation details).
We also found that reliability is often a question of avoiding unnecessary complexity in the first place. If you don’t need a Kafka cluster, you don’t need a Kafka cluster … even if it is fun to have one. We usually opt for tried-and-tested frameworks rather than going for the bleeding edge. This is combined with a healthy level of pragmatism that keeps us focused on continuously improving our product for our users rather than spending time over-optimizing pipeline speeds, build systems, or page load times that are already satisfactory.