Hello AriaTosca users, I'm happy to introduce a new project that I've been working on the past few months. I humbly offer it for consideration as an alternative to AriaTosca:
https://github.com/tliron/puccini There's a lot of documentation on the site, but I thought it useful to provide the following more specific comparison with AriaTosca: *GOALS: PARSER VS. ORCHESTRATOR* AriaTosca's goal is to be a complete TOSCA solution, meaning that it allows you to *both* parse *and* deploy TOSCA service templates. It's a goal that I found problematic from the very start. First, in that it would be quite impossible for AriaTosca to be more than a "toy" orchestrator. It could never compete with mature packages such as Cloudify, Ansible, Juju, etc. Second, in that it would make it that much harder to integrate AriaTosca into a real orchestrator. I worked hard to make sure that the parser would be as independent as possible, but it was an uphill battle against the requirements for orchestration. Because it has an orchestrator built in there's more "surface area" in general that you would have to deal with when integrating it into your product. Third, I believe that there cannot be a true "default" orchestrator for TOSCA. The language was designed to specifically avoid dictating orchestration behavior. This means that AriaTosca is necessarily opinionated, and as such limits the imagination as to what TOSCA can be used for. This is painfully obvious when targeting Kubernetes, where you never want to treat a "node instance" (a pod? a container? a deployment?) as anything other than an implementation detail. And yet AriaTosca requires you to think in terms of node instances. Puccini doesn't intend to be an orchestrator, but rather a TOSCA frontend for orchestrators. It is designed to provide your orchestrator with exactly what it needs to do its work. This allows it to be much more focused and less opinionated about TOSCA. Crucially, it comes with a TOSCA profile for Kubernetes and out of the box can deploy TOSCA directly to a Kubernetes cluster. I know that some AriaTosca users want orchestration. My advice is that you should seriously consider Kubernetes as an alternative. It elegantly solves so many tricky orchestration problems such as resource provisioning, discovery, networking (SDN), scaling, and redundancy. Service mesh add-ons such as Istio provide you instantaneously with powerful application robustness, control, and visibility. There exist several production-grade, commercially supported Kubernetes platforms, such as OpenShift <https://www.openshift.com/>, Rancher <https://rancher.com/kubernetes/>, and many more are coming. And if you are thinking that Kubernetes is only about Docker containers, think again: Intel's new Kata Containers <https://katacontainers.io/> allows you to use lightweight virtual machines in Kubernetes, and the roadmap for OpenShift includes support for full-blown virtual machines using libvirt, including Windows VMs (and containers) on Azure or otherwise. Generally, the "cloud native" approach to building software discourages classical ssh-and-execute orchestration. Instead, the application itself knows that it's running in a cloud and uses the cloud infrastructure directly. In Kubernetes this means calling the API server, storing state on etcd, and watching ConfigMaps <https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/>. More advanced features, such as lifecycle management, can be achieved by using custom operators <https://coreos.com/operators/>. Still, if you really, really insist on classical orchestration, I believe it would not be too hard to add it to Puccini. Especially if you are looking for something on par with AriaTosca's simplistic implementation. Alternatively, you can write a translator or adapter that could connect Puccini to an existing orchestrator, such as Cloudify, Ansible, etc. *STATELESS VS. STATEFUL* AriaTosca requires a database. Managing state is painful, and storing in a database is slow. AriaTosca is indeed painfully slow for basic parsing. This also adds enormous complexity to the codebase. Puccini is stateless. It does generate compiled results, but actually you don't even need to store them anywhere and can read them directly in your processor. The result is that Puccini is very, very fast. Also, Puccini requires no configuration files and doesn't even make use of environmental variables. You run it, it does its work, and then gets out of your way. This is the "Unix way". *GO/JAVASCRIPT VS. PYTHON* We worked hard to provide a well-documented Python API for AriaTosca. But is it really necessary? In my opinion, it would have been much easier to go the "Unix way" and just provide a CLI tool that parses TOSCA and returns a result. Having to maintain an API, again, adds considerable complexity and surface area. (Note that Puccini can still be used as a standalone library to be incorporated into a Go program if you need it, but it is expected that most users would find the CLI does the job.) One advantage to using Python is that it more easily extensible ("hackable") than Go because it doesn't require you to compile code. However, though Puccini is written in Go, it incorporates a JavaScript interpreter exactly to allow for such easy extensibility. More than that, these JavaScript scriptlets are integral to Puccini's architecture. A side effect is that it's very, very easy in Puccini to create your own custom TOSCA intrinsic functions and constraint <https://github.com/tliron/puccini/blob/master/examples/tosca-grammar/functions-custom.yaml> s. Does Python make AriaTosca more portable than Puccini? In my opinion: no. First, consider that Python's portability is overstated. Any non-trivial Python program likely has 3rd party libraries that require compiling C code. As you can see from AriaTosca's installation instructions, it even differs a lot among different Linuxes. Though Go is compiled, it can target any popular platform. Moreover, Go programs favor static linking, so that most Go programs are self-contained all-in-one executables. Puccini is thus just a collection of small files that need no special installation. To me this seems as portable or even more portable than Python, in terms of convenience. Another pain point with Python is support for Python 3. AriaTosca is stuck in Python 2.7, and upgrading would be non-trivial work. And it has its costs: Python 3 would break portability with some popular operating systems that do not yet support it. Python 2.7 is also quite miserable in its support for Unicode, which lead us to a lot of hard work in AriaTosca for Unicode support, and a lot of possible bugs. Go supports Unicode natively. There is no special handling of strings in Puccini in order to support it fully. *TOSCA 1.1* Puccini targets 1.1 from the start, which includes support for new features added since TOSCA 1.0, namely workflows and policy triggers. *ARCHITECTURE* AriaTosca's parser works "on-demand" to handle validation, inheritance, assignment, and all the other complex TOSCA work. I believe that in retrospect this was not the best approach. It has made it very hard to follow the many codepaths leading to final assignment of a valid value. (Yes, this architecture was my design, and I have come to regret it.) I'm sure the contributors to AriaTosca can attest to this, and I can only apologize for making your life (and mine) harder. Puccini has the benefit of being a fresh start based on the experience I gained in designing the original parser for AriaTosca. Its architecture is radically different: it has 6 phases <https://github.com/tliron/puccini/tree/master/tosca/parser> that must each complete entirely before moving on to the next phase. (Of course, designing these 6 phases required very acute knowledge of the challenges involved in implementing specific TOSCA features, so I'm willing to forgive myself for not doing a perfect job my first time around.) The result, I believe, is that Puccini more consistently complies with TOSCA, has fewer bugs (because there's less room for bugs), and actually is more fully featured. For example, namespaces (including the namespace_prefix for imports) are fully handled, and complex inheritance (types/definitions/templates) is much more robust. Indeed, Puccini caught a few inheritance bugs that AriaTosca currently does not. Furthermore, Puccini is less literal in its interpretation of TOSCA, and thus more allows for more efficient usage. For example, many fields that are marked "required" in TOSCA really don't have to be, because they can be derived via inheritance. With Puccini, you often can omit the "type" field if it can be found it. In AriaTosca I think we tried too hard to be loyal to the spec. Unfortunately, the spec is not very good (to say the least) and has many inconsistencies, errors, and gaps. With Puccini I preferred to be smarter than more correct. For example, the TOSCA spec says that a "range" type cannot have both bound equal (e.g. [1,1]), but that's plain silly and causes various pain points in AriaTosca. Puccini sidesteps that silliness. *INDEPENDENT VS. COMMERCIAL/FOUNDATION BACKING* AriaTosca started its life as an incubation project in the Apache Software Foundation and was mostly funded by Cloudfy. I am very grateful to Cloudify for their backing. In doing so they made an important contribution to TOSCA and its ecosystem. I am also very grateful to the ASF, as it allowed us to build trust and gave us resources to create a small international community of developers around AriaTosca. Puccini is an independent project. It was developed by yours truly during his own free time. (So many late nights and long weekends!) Currently it is not funded and has no foundation backing: It is just one more open source (Apache licensed) project on GitHub. This could make it seem much less desirable than AriaTosa, despite any technical and architectural advantages. But, the current state of AriaTosca must be taken into account. Unfortunately, Cloudify has stopped funding work on AriaTosca for about 6 months now. Also, the community around AriaTosca in ASF has not grown enough to allow it to graduate from incubation. As you know, there is a very good chance that AriaTosca will soon exit incubation and be sent to the ASF attic. AriaTosca is being used by the ONAP project (under the Linux Foundation), but that usage has not generated *development* interest. ONAP, now at version 2.0, continues to use AriaTosca, but that's in addition to 2 other TOSCA parsers in that project. In summary, all of AriaTosca's advantages over Puccini in this respect seem to me to be no longer relevant. (Emphasis: this is my personal opinion.) All I can do is humbly present Puccini to the community and hope that its merits will justify your interest. Thank you!
