Zsolt erklärt: Der Onshape Architektur unter die Haube geschaut

Mit einem Leiterwagen kommt man nicht auf den Mond – in diesem provokativen Satz ist folgende Botschaft verborgen: Um ein bestimmtes Ziel zu erreichen, benötigt man die geeigneten Werkzeuge. Um auf den Mond zu gelangen, benötigt man offensichtlich etwas anderes als konventionelle Fortbewegungsmittel. Die Cloud ist auf dem Weg zum Mond und Onshape das richtige Fahrzeug dafür.

In diesem Artikel erläutere und kommentiere ich einen Vortrag von Ilya Baran, verantwortlich für die Architektur von Onshape, den er auf der OnshapeLive21 Konferenz im März 2021 gehalten hat. Er hat ihn „Under the Hood“ (Unter die Haube geschaut) genannt und erläutert die Onshape zugrundeliegenden Technologien. Er beschreibt sozusagen die Software-Maschine, die Onshape zum Mond bringen soll, um bei diesem Bild zu bleiben.

Mit Bildern und Gleichnissen kann man gut Sachverhalte veranschaulichen: Das Fundament eines Gebäudes bestimmt, was Du darauf bauen kannst, ein Hochhaus, ein einstöckiges Gebäude oder eine Hundehütte. Das ist bei Software und der Architektur von Software genauso.

Viele besondere Merkmale und das Potential von Onshape haben ihre Wurzeln in frühen Entscheidungen, etwas total Neues auf Basis von Internet- und Datenbanktechnologie zu entwickeln. Dies führt zu Fähigkeiten wie dem einfachen und sicheren Teilen von Konstruktionen, simultanem Arbeiten an einer Konstruktion, einfachem Verzweigen und Vereinigen alternativer Konstruktionswege oder der Vermeidung von Datenverlusten durch Abstürze.

Die Architektur basiert ohne Kompromisse auf „Multi Tenancy“ (EIN System mit Mandantenfähigkeit) und der Cloud. Das hat zur Folge, dass alle Onshape-Anwender mit nur einem einzigen System kommunizieren und nur eine Ressourcenquelle teilen. Das ist nicht dasselbe wie das Zurverfügungstellen einer Instanz einer Software in der Cloud für einen Client. Letzteres ist „cloud-gewaschen“, eine wirkliche Cloud Anwendung muss dagegen integrierte gemeinsame Ressourcen für Teilen, Kollaboration und anderes haben und ist damit auch einfacher in der Wartung und kostengünstiger. Es gibt eben nur ein System, das gewartet, gepflegt werden muss und entsprechend dem Anwenderaufkommen hoch und herunter skaliert wird.

Konsequenterweise wurden bei der Entwicklung von Onshape zunächst einmal Grundlagen geschaffen, spezielle Features kamen später. Allerdings konnten bereits frühe Versionen wie die aus dem Jahr 2014 Fähigkeiten wie Verzweigen/Vereinigen oder simultane Konstruktion vorweisen.

Ein System muss von Anfang an mit der beabsichtigten Architektur aufgebaut sein. Der Versuch, einiges Neues mit alter Technologie zu kombinieren, führt zu halben, „Ccloudgewaschenen“ Lösungen.

Die Angebote am Markt können im klassischen Quadrantenmodell klassifiziert werden.

Unten links

• alle klassischen Desktop-CAD-Lösungen

Dann gibt es die auf dem halben Weg stehengebliebenen Lösungen:

• Auf einer virtuellen Maschine bereitgestellte CAD-Angebote. Der Anwender hat von überall Zugriff und muss nicht in teure Hardware investieren. Aber er nutzt dasselbe CAD-System wie bisher mit den gegebenen Kollaborationsmöglichkeiten, denselben Versions- und Datenmanagement-Problemen.
• „Thick clients“ werden lokal installiert und beziehen Dienste aus der Cloud, beispielsweise die Datenbereitstellung. Die Unterstützung beim Teilen von Daten und die Zusammenarbeit ist besser. Die lokalen Hardware- und Upgrade-Herausforderungen bleiben allerdings bestehen. Es gibt keinen Vorteil durch eine gemeinsame Datenbank, kein Verzweigen und Vereinigen, kein simultanes Editieren usw.

Im oberen rechten Quadranten ist ganz offensichtlich Onshape angesiedelt.

• Es ist von Anfang an kompromisslos für die Nutzung in der Cloud entwickelt, es gibt keine „Thick Clients“, alle Daten sind in einer Datenbank und nicht in Dateien abgelegt.

Die Onshape Architektur ist einzigartig in der CAD-Welt. Der lokale Client ist für die User-Interface-Aktivitäten und die Grafik zuständig. Auf der Gegenseite, in der Cloud, stehen verschiedene Server, die verschiedene Aufgaben und die Kommunikation mit dem Client übernehmen. Jeder Server läuft jederzeit auf einer Reihe von Maschinen, die auf Ausfallsicherheit ausgelegt sind. Stürzt ein Server ab, wird er sofort durch eine andere Maschine ersetzt.

Der Vorteil der Nutzung der zentralen Server der Amazon Web Services (AWS) ist, dass die Rechenkapazität entsprechend den gerade aktuellen Anforderungen skaliert werden kann. Einige Hundert mehr Anwender benötigen nur wenige extra Maschinen. Hohe Leistung kann zu einem vernünftigen Preis geliefert werden. Das zugrunde liegende Multi-Tenancy Konzept nutzt die Hardware effizient. Ein Skalieren ist dagegen mit einem Desktop nicht möglich, die Hardware muss mit auf die höchsten Anwendungsanforderungen ausgelegt werden. Die meiste Zeit läuft Desktophardware deswegen im Leerlauf – Welche Verschwendung!

Wenn übrigens der Geometrieserver abstürzt, stürzt nicht die gesamte Applikation ab, wie bei den üblichen, monolithisch in C++ programmierten Anwendungen. Der C++ Code ist isoliert, damit sicherer integriert und die Absturztoleranz ist höher.

Die Vorteile der beschriebenen Architektur sind offensichtlich und darin begründet, dass keine Segmentierung der Daten wegen der Hardwarestruktur gibt. Alles ist an einem Ort. Es gibt nur eine Quelle der Wahrheit, auf die alle Berechtigten zugreifen. Es gibt keine Kopien irgendwelcher Erzeugerdaten, von geistigem Eigentum. Das geistige Eigentum verlässt das „Fort Knox“, die Multi Tenancy Mongo Datenbank nie. Es werden lediglich Transaktionen mit der Datenbank ausgetauscht.

Da alle Daten in einer einzigen Datenbasis gespeichert sind, gibt es keine gebrochenen Referenzen mehr. Der Anwender profitiert von höchster Sicherheit und besseren Desaster-Szenarien, als traditionelle Strukturen je liefern können.

Nur inkrementale Änderungen der Konstruktion werden über das Internet initiiert und in der Datenbank gespeichert. Damit ist ein Datendiebstahl über den Internetverkehr ausgeschlossen, denn die übermittelten Transaktionen sind allein nutzlos. Die inkrementellen Datenbankänderungen werden beim Speichern nicht mit den vorherigen vereinigt, sondern immer wieder neu aufgebaut. Das macht die Konstruktion flexibler und senkt die Speicheranforderungen signifikant. Damit können 100 % aller Konstruktionsschritte wieder verwendet werden, beispielsweise beim eleganten Verzweigen und Vereinigen von Konstruktionsalternativen.

Entwickler von Applikationen oder Anpassungen nutzen dieselben Werkzeuge wie die Onshape-Entwickler, um eigene Features zu erzeugen. Am Anfang entwickelte Onshape die Programmiersprache Feature Script, mit der im Anschluss alle Onshape-Features programmiert wurden. Dieses Werkzeug steht inzwischen der Entwicklergemeinschaft zur Verfügung.

Ein kleines Beispiel aus meiner „alten“ Welt: Viele SolidWorks Partner sind recht erfolgreich mit Möbelapplikationen. Die Verwendung von Feature Script macht es sicherlich einfacher, solche Anpassungen zu entwickeln, als wenn eine API genutzt werden muss, die on top über dem System liegt und zudem noch Versions-Herausforderungen ausgeliefert ist.

Die Serviceorganisation von Onshape hat mächtige Werkzeuge, um hohe Verfügbarkeit, Sicherheit und Performance zu gewährleisten. Die Anwender benötigen kein Offline-Tool, um ihre Probleme und Abstürze zu melden. Sie sind bereits Online, direkt im System, eine einzige Quelle der Erzeugung der Daten und Wahrheit ist auch hier ein Vorteil. Die Onshape-Anwender können produktiver sein, weil der Onshape-Support mit Vorsorgewerkzeugen arbeitet – Vorsorge ist besser als Nachsorge.

Das Entwicklungsteam kann sich so stärker auf neue Funktionalitäten konzentrieren und wird nicht abgelenkt durch das Jagen nach Regressionsfehlern, Rückportieren von Fehlerbehebungen auf ältere Versionen, Hotfixes und ähnliches. Der dreiwöchige Versionszyklus von Onshape beweist, dass die Architektur das Liefern von Innovationen und Änderungen leicht macht. Upgradekosten und -aufwände sind geringer als bei den Desktop-Systemen.

Onshape ist für PTC eine strategische Investition, nicht eine mit dem Ziel, eine Kundenbasis zu übernehmen. Durch die Kaufentscheidung hat sich PTC entschieden, mit Onshape eine SaaS Plattform für die Produktentwicklung zu bauen. Das ist gut für alle Kunden: Wettbewerb belebt das Geschäft und die Fantasie. Mit Onshape ist in jedem Fall mindestens eine sehr gute SaaS-Produktentwicklungsplattform auf dem Markt.

PTC Kunden können sicher sein, dass ihnen in der Zukunft, wenn die Zeit für sie reif ist, eine Option zur Verfügung steht, Schritt für Schritt den Mond zu erreichen – und zwar nicht mit dem Handkarren.

Ich meine, dass der kompromisslose Weg in eine 100% auf Cloud und SaaS ausgerichtete Plattform viel Potential hat. Voraussetzung ist, dass PTC das Onshape/SolidWorks Erbe weise nutzt. Und es sieht ganz danach aus.