Introducing Optima

Today we introduce Optima, the cloud industry’s first polydimensional scheduler.

I call Optima the scheduler for the complex world, which is to say, the enterprise world of heterogeneous apps running on dynamic and/or heterogeneous infrastructure. That’s a world I know well, including the pain it creates for both dev and ops.

We are making Optima available as a free, 30-day trial so that dev and ops folks frustrated with traditional schedulers can exercise it and give us feedback. As it happens, Optima is the tip of the iceberg of what we’ve built at MosaixSoft. So we are quite interested in engaging in dialog with early adopters. You can get access from the main Optima page.

Now, let us make some architectural observations about Optima. Please also check-out today’s companion post about Optima that goes into detail about its design.

First, Optima is architected the right way: users explicitly state objectives and Optima figures out how to achieve those objectives. We are already overrun by terminology and concepts. Why be burdened with more, e.g., pod, project or artifacts? Correctly designed systems should be non-opinionated.

The next observation is that cloud is an N-dimensional system from functionality and classes-of-resources points of view. It is not just a cluster of computes. Representing cloud using a compute-centric model is incorrect and incomplete, and can generate flawed and inefficient decisions. Cloud scheduling can seem overwhelming, for instance when dealing with containers, VMs, bare-metal hosts, network, storage, databases, various policy objectives, and constraints that are motivated from seemingly competing goals, such as efficiency versus security. However, these can be rendered homogeneous with the correct abstractions. Optima has an important property: it can represent and express all cloud elements in a homogeneous manner.

Another observation is that Optima schedules a multitude of cloud resources and objects, not just clusters of computes as Kubernetes and Swarm do. This approach enables better scheduling decisions. Stay tuned for future posts on this important topic.

A final architectural observation is that scheduling is a generic function which should be agnostic to the setting or application area. It even transcends cloud. The kernel of Optima can be used in any scheduling context. Optima considers scheduling a generic function, not a component.

Lastly, Optima has several pragmatic advantages over traditional schedulers, including the simplicity of its syntax and the ability to deftly react to dynamic infrastructure changes. You can read more about these on the main Optima page and the documentation on GitHub.

Let me close by reflecting on this exciting moment in the history of our young company. The main goal of every engineer at a startup like MosaixSoft is to contribute to the evolution of the industry with a product that is widely liked and used. We’ve spent years designing and implementing the ideas behind Optima, with the hope that it will make a difference and that customers will find it cool and useful.

Cool software is built by great professionals. Dr. Mahesh Tripunitara is the main architect of Optima. He and I have just published a companion post that goes into detail on the design philosophy behind Optima. Mahesh is a university professor who takes a problem-driven approach to research, not a technique-driven approach. As such, he finds the scheduling problem for enterprise clouds to be a compelling problem and Optima to be an appropriate and timely solution. Several exceptional engineers worked with him to make Optima happen.

We look forward to your meaningful feedback and hope you enjoy using it.