Re: Differentiating TOSCA from HEAT

[Tal Liron <tliron@redhat.com>]

On Thu, Jan 6, 2022 at 1:44 AM Bruun, Peter Michael (CMS RnD Orchestration) <peter-michael.bruun@hpe.com> wrote:

Agree. In fact our orchestrator has a language, âDSDâ, that was originally derived from HOT, so you will recognize some of the syntax, but I fixed all the issues with the HOT language that I mentioned below, and quite a few more.

Could you provide us with a comparison of DSD and TOSCA? How about the whole DSD specification?

Â

As for âhackabilityâ, that is nice for small scale DevOps type orchestration, but when you look at thousands of transactions per minute on behalf of end-customers, you donât want users to hack each playbook individually. The paradigms you want for orchestration depends heavily on that kind of concern.

Â

There is always a tradeoff between flexibility and constraint. Too many constraints on what users can do will definitely lead to frustration â I get that a lot with systems like maven, where they are really helpful if what you want to do is within their paradigm, and really frustrating if it is not. But too much flexibility, also leads to frustration because that leaves the user without guidance as to what combinations of functions and features are meaningful for some intent, and what combinations are not. So âflexibilityâ is not always the same as âgoodâ.

Â

Basically, your domain for orchestration is DevOps, as you say. Our orchestration domain is quite different from DevOps, and that makes a huge difference in the requirements. So nothing is right or wrong â just two different worlds.

So, let me unpack this a bit, because I'm not "on the side of devops". I'm on the side of "it depends". In my work I have two kinds of customers:

1) There are companies that are not in the business of developing software. They would prefer to offload this work, and even more preferably to off-the-shelf solutions (cheaper in the short- and the long-term). Their main struggle is in integrating these solutions. For that, sometimes they go to yet another vendor.

2) There are companies that prefer some ownership over solutions. They invest in building up a devops team. The main struggle here is in balancing the trade offs between existing solutions and their own special needs.

The thing is, for both kinds of companies hackability is useful, if in different ways. For the first, it allows for choice in vendors and avoidance of lock in. For the second, it allows for customization of off-the-shelf solutions without having to fork them.

I think it's absolutely possible to make something hackable without much cost to its built-in, opinionated automation. The keyword is "extensibility". A good example is Cloudify's plugins: the Cloudify platform generates a default DAG with a set of built-in tasks, but via plugins you can modify that DAG and inject your own tasks. There is a cost to this, and the platform has to give you the tools to develop such customizations, but I think we both agree that we would want those tools to exist even without customizations so that we don't end up with something like Heat. (Sorry, Heat, you've become the punching bag in this conversation.)

From the perspective of a from-the-trenches engineer: there's nothing more frustrating then a big automatic system that does a zillion things for you, but then can't do the simplest thing that you can do in a command terminal in one minute. And of course it's baffling and infuriating for managers to hear about this disparity. We have to stop building systems that end up shooting ourselves in the foot.

Â

ÂWelcome to the cloud-native world. :) It's best for your components to be designed to run in clouds

Â

Cloud native is for compute nodes running applications with connectivity. We are not in that domain. There are lots of nodes that do not represent components in clouds.

Well, the "C" in "TOSCA" stands for cloud. Clouds always have peripheral systems that are not so cloud-like, which we want to support, but TOSCA absolutely has to nail clouds.