17-11-2020

Otomi OSS countdown part 1: The vision

The open source version of Otomi Container Platform will be officially released in the beginning of January next year. In a series of 3 blog posts we will count down towards the official launch and provide more insights into the vision behind Otomi, our development journey and what you can expect from Otomi in the near future. In this first post we’ll shortly explain the vision behind Otomi and de 2 key principles.

Kubernetes becoming the new foundation

The container space is slowly evolving from the wild west into a landscape of governance, security reliability and thus trust. After many years of working with Kubernetes it is not hard to imagine it is becoming the foundation for (cloud native) software. This movement already started years ago. We can see that this new DIY architecture paradigm breeds a plethora of containerized solutions and suites offered. And this has become the new reality; too many (possibly good) things to choose from. But this also presents opportunities, to be able to quickly deploy and test solutions to see if they meet our needs.

What you should expect from a container platform

First we have to look at containerization and the microservices way of working, as it has brought focus on the following areas:

  • Observability: State of the (parts of the) system now and over time. Metrics and logs, preferably correlated. Hopefully AI to help us monitor and make sense of it
  • Stateful storage: Where to keep your crown jewels, and how to automate backups and failover
  • Application configuration: Kubernetes configuration and package management like Helm, Kustomize and others exist. We need to abstract configuration away from the solution for easier retrofitting and repeatability. Should be idempotently deployable as code (gitops)
  • Policy enforcement: Are the pieces and the players operating within governable constraints?
  • Security: What are the new security concerns when containerizing workloads?
  • Continuous Deployment: New platforms demand a new way of continuously deploying. And so does kubernetes. Think Helm charts, Knative services, GitOps push/pull
  • Single Sign On: One Identity Provider could be used by a group of applications to authenticate its users and know their roles and permissions
  • Networking/service configuration: Ingress flowing into the cluster’s network, SSL termination, Routing logic and rules and Service governance

When looking out for a platform solution it makes sense to evaluate the solutions offered based on the problem spaces above. Anything not handled out of the box can lead to a lot of hidden cost. And the solutions should be straightforward to use and not lock you in too much. Hot swapping solutions should be made easy.

Key principles

Otomi Container Platform is build upon two key principles:

1. Honour open source projects

Don’t try to reinvent the wheel. Coming from developers working with the 12-factor app methodology, Otomi was designed to be open and flexible, embracing open source projects and inevitable change. The best way to do this is to avoid technical debt and contribute effort where it makes most sense; in these projects we’ve come to love and use. Many companies try to wrap open source building blocks into their own abstraction/experience, offering an unified interface to all these wonderful functionalities. 

This looks great, but this custom wiring/glueing creates huge technical debt. You are on your own when it comes to patching and updating all these parts.

Embracing this new era of turn key (point) solutions we decided to use those apps as is and make them aware of the bigger context they serve in: a company of teams and users that have roles and permissions to work with them. Otomi ultimately is an integration platform that strives to make these open source apps work together.

2. Serve developers

When dealing with this multitude of applications and configuration, it is of utmost importance to ease the developers workflow. They have to adopt this way of working, and so this is why we aim for the following:

  • No local installs: we eat our own dog-food and build tooling images to run our code in containers, so it behaves the same locally as in the cloud
  • Automate everything: input/output validation, testing, deployment, issue management. Limit errors and let developers focus on features
  • Less integration points: Easily add core apps or wire them together, abstracting configuration away to a single repository
  • Coding support: deliver json schema for validation in your favorite editor (VScode out of the box).
  • API oriented: easily create open api clients for tasks to do rest operations on the apps and giving autocompletion while developing

In the second post of this series we will tell you more about our development journey and provide some more insight into the architecture of Otomi.

Let's get in touch!

Contact us