What is Otomi?

Otomi is a Kubernetes-native Developer Platform, created by Red Kubes to empower developers, lower the burden on Operations teams, and help DevOps teams and SREs to guarantee application security and availability from the earliest stages in the development lifecycle when using Kubernetes. Otomi is based on Configuration as Code, where the desired state is reflected as code and the cluster state is automatically updated. Otomi can be installed on any Kubernetes cluster in any cloud and now supports over 12 pre-configured tasks and over 30 integrated and pre-configured applications and add-ons out-of-the-box.

Focus

Otomi provides a full productivity suite for Kubernetes with pre-configured apps and self-service tasks. Development teams can be onboarded in minutes and use the self-service tasks to configure ingress, deploy serverless workloads, manage images, manage secrets, create jobs, and much more. The complete suite of integrated applications is combined with automation, and all applications are pre-configured based on sane defaults and best practices. Configuration is stored in Git, and the desired state is automatically updated. This makes Otomi ideal for developers, but also for operation teams and SRE.

Otomi can be installed in a single run on any Kubernetes cluster in any cloud or even on-premise, making it a multi- and hybrid cloud developer platform. To migrate, create a new Kubernetes cluster, install Otomi, create teams, adjust the business application pipelines to deploy to the new cluster, and make sure all Kubernetes services are of type ClusterIP. After the business application is deployed, use the UI to configure the required services for public exposure. The migration effort from a brownfield environment depends on the amount and complexity of the business applications.

Otomi is completely open. It is possible to run other applications next to Otomi (if namespaces are not conflicting). Most of the applications in Otomi are optional and can be turned on/off, allowing customization. The configuration of all the integrated apps can also be adjusted. In this case, clone the Git repo and use the CLI (with VSC integration) to change the configuration based on the Otomi values schema or hard value overrides, using all the values provided by the original Helm charts.

Background

Otomi has been created by the engineers from Red Kubes, with the goal to offer a productivity suite for Kubernetes that can be installed in just a couple of minutes on any Kubernetes cluster in any cloud and provides a complete set of pre-configured and integrated apps, developer self-service, full observability, Kubernetes best-practices, all required security features, and a Configuration as Code approach, where all configuration is managed as code. Otomi now supports over 12 self-service tasks for the most common use cases when using Kubernetes. Red Kubes is VC-backed.

Otomi main features

Multi-tenancy

The Teams functionality in Otomi enables development teams or new projects, to be onboarded in just a couple of minutes and share the same Kubernetes cluster including all integrated applications. Access to team namespaces is provided using OIDC, and each team will automatically get all the applications and dashboards they need in a comprehensive multi-tenant setup. Team workloads are separated through network policies, shared apps are user/team aware, and all required team configuration is automatically generated. With the delegation options, admins can decide which self-service options will be made available for a team.

Security

Otomi includes production-ready security best practices, like workload isolation, image vulnerability scanning, policy enforcement (in multiple modes), mTLS, secret management, a Web Application Firewall (WAF) based on OWASP, Single Sign-On, and pre-configured RBAC.

Self-service UI

Developers can use the UI to get access to all integrated applications like Harbor and Vault, and all the provided dashboards. Developers can also use the UI to quickly expose services (with DNS, certificates, and SSO), deploy serverless workloads using Knative, configure network policies and egress rules, and create Kubernetes Jobs and CronJobs without having to write any YAML Kubernetes manifest.

Configuration as Code

All integrated applications are configured with sane defaults based on best practices. The default configuration can be modified using the UI or CLI, based on a pre-defined values schema. Operations teams can change and optimize the default configuration using the extensive values schema or use overrides. All code is under version control and the cluster state is automatically updated after every commit.

Advanced Ingress Architecture

Kubernetes services can be publicly exposed using the web console with just a single click. Istio virtual services are automatically generated (if Istio is enabled) and ingress resources are automatically configured for SSO traffic and public exposure, tying a generic ingress architecture to service endpoints in a predictable way.

Full observability

Otomi contains a full observability stack for logging, metrics, tracing, and alerting. Teams can use the self-service UI to configure alerting endpoints and will get access to all required logs and metrics. When creating a service with the UI, Otomi will automatically configure service HTTP endpoint monitoring.

‍

Useful resources