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:
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.
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:
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.