Warum große Technologiekonzerne davon besessen sind, proprietäre Lösungen zu entwickeln

Hallo! Ich möchte darüber sprechen, warum große Technologiekonzerne davon besessen sind, proprietäre Lösungen für ihre Infrastruktur zu entwickeln. Die Antwort liegt auf der Hand: Es handelt sich um nichts anderes als das NIH-Syndrom. Aber diese Antwort ist alles andere als vollständig, geschweige denn objektiv.

Ich bin der CTO des Yandex Platform Engineering-Teams und unser Ziel ist es, Ingenieure beim Aufbau des gesamten Entwicklungszyklus zu unterstützen, vom Code-Schreiben bis zum Betrieb von Diensten, um ihn effizienter zu gestalten. Dazu gehört auch die Prozessoptimierung: Wir entwickeln nicht nur As-a-Service-Angebote, sondern unterstützen auch bei deren Umsetzung im Unternehmen. Dies funktioniert auf dem Niveau von Yandex: Unsere Dienste werden von Tausenden von Entwicklern im gesamten Unternehmen genutzt.

Beispiele für Tools zur Organisation des Entwicklungszyklus

Um ein Problem zu lösen, entwickeln wir häufig proprietäre Tools, anstatt vorgefertigte zu implementieren. Als ich beispielsweise noch Programmierer im Team war, habe ich an einem quantitativen Überwachungssystem in C++ und Python gearbeitet und dabei geholfen, es auf Dutzende Milliarden verarbeiteter Metriken zu skalieren. Aus eigener Erfahrung weiß ich also, welche Beweggründe und Entwicklungspfade zur Entstehung eigener Tools führen. Im Folgenden werde ich versuchen, anhand unserer Lösungen die wesentlichen Gründe für deren Entstehung herauszuarbeiten.

Geschichte Nr. 1: Interne Yandex-Cloud

Stellen Sie die Aufgabe. Das Ziel unserer internen Runtime Cloud (RTC) besteht darin, internen Benutzern einfache Bereitstellungs- und Traffic-Management-Tools zur Verfügung zu stellen. RTC-Benutzer sind dieselben Ingenieure, die Yandex-Dienste entwickeln. Und sie müssen unter anderem Zehntausende von ihnen erstellte Anwendungen starten, Benutzeranfragen dorthin senden, die Last ausgleichen und Vorfälle bewältigen.

Der Bedarf an einer internen Cloud entstand Anfang der 2010er Jahre, als die Anzahl der Dienste bereits Hunderte betrug und die Gesamtzahl der zugewiesenen Kerne um mehrere zehn Prozent pro Jahr wuchs. Die Bereitstellung dedizierter Server für jeden Dienst wurde unerschwinglich teuer und wir benötigten Tools, mit denen wir Anwendungen von mehreren Diensten auf einem einzigen Server ausführen konnten. Wir hatten zu Beginn mehrere Anforderungen an diese Tools:

• Um Betriebsressourcen zu schonen und die Anzahl der Vorfälle bei Freigaben zu reduzieren, ist die Automatisierung von Routineabläufen erforderlich.
• Eine weitere wichtige Aufgabe bestand darin, die Cloud-Auslastung zu erhöhen, insbesondere da die Auslastung der meisten Dienste einem täglichen Muster folgte und die Cloud nachts im Leerlauf war. Erschwerend kam hinzu, dass in diesen Jahren nicht alle Yandex-Dienste in der Cloud gehostet wurden und die ständige Zunahme der Serverzahl das Problem verschärfte.
• Es war von entscheidender Bedeutung, den Benutzern Funktionen oder Fehlerbehebungen schnell zur Verfügung zu stellen, da sich dies direkt auf die Geschwindigkeit der Yandex-Entwicklung auswirkte.
• Es ist ausschließlich IPv6-Unterstützung erforderlich: Um eine End-to-End-Konnektivität zwischen Pods bereitzustellen, wurden unsere Rechenzentren nur für IPv6 gebaut, da der Bereich der IPv4-Adressen in unserem Maßstab für uns nicht ausreichen würde.

Im Wesentlichen brauchten wir Kubernetes (und im Laufe der Zeit kam RTC dem sehr nahe). Aber hier ist der Haken: k8s wurde erst 2014 angekündigt. Apache Mesos gab es damals, aber es steckte noch in den Kinderschuhen.

Implementierung grundlegender Funktionen. Wir begannen, das Problem mit einer Art MVP zu lösen – einem einfachen Satz von Tools, der eher einem Satz von Bausteinen ähnelte, die Routineaktionen automatisieren, zum Beispiel:

• Zuweisung von Clusterressourcen;
• Bereitstellung der erforderlichen Version der Anwendung und verschiedener Artefakte an den Cluster;
• Starten der erforderlichen Version der Anwendung auf dem Cluster.

Im Laufe der Zeit wurde es möglich, mithilfe dieser Bausteine (ähnlich wie bei Continuous Delivery) ein vollwertiges Service-Layoutdiagramm zusammenzustellen. Nach einer bestimmten Anzahl von Iterationen erschien 2013 Nanny, ein System zur Verwaltung der bei RTC laufenden Dienste.

Ein weiterer grundlegender Aspekt von Nanny war die Implementierung der Anwendungsisolation basierend auf dem Ressourcenverbrauch. Wir haben zunächst Anwendungen von verschiedenen Diensten ohne Ressourcenisolation gestartet, was zu einer großen Anzahl betrieblicher Probleme und Vorfälle führte.

Zu diesem Zeitpunkt waren die einzigen vorgefertigten Lösungen LXC, dessen Entwicklung zu diesem Zeitpunkt eingestellt worden war, und Docker, das nicht nur IPv6 verwenden konnte und beim Aktualisieren von Docker alle Container neu startete, was es unmöglich machte, Docker ohne Auswirkungen auf den Benutzer zu aktualisieren. Infolgedessen begannen wir mit der Entwicklung unseres Porto Containerisierungssystem auf der Linux-Kernel-Cgroup etwa Mitte 2014. Die meisten Anwendungen und einige Systemagenten auf Servern wurden bereits 2015 in Porto-Container verschoben.

Nutzungsprobleme lösen. Damals erfolgte die Ressourcenverwaltung in der internen Cloud über Commits an das Repository. Dies verlangsamte jedoch die Entwicklung von Yandex und stand im Widerspruch zu der Aufgabe, die Auslastung zu erhöhen: Um das Problem zu lösen, mussten wir unser Kartenreduzierungssystem in den Clouds platzieren YTsaurus - unser proprietäres internes System zur Speicherung großer Datenmengen und verteilter Datenverarbeitung, das wir damals etwa sieben Jahre lang entwickelt hatten. Es musste in die interne Cloud gebracht werden, aber auch neben Benutzeranwendungen laufen.

Um YTsaurus zu RTC zu bringen, war die Fähigkeit erforderlich, Pods dynamisch statt über Repository-Commits zu verwalten. Deshalb haben wir 2018 erstellt Yandex-Planer , ein System zur Verwaltung von Cluster-Computing-Ressourcen. Yandex Planner wurde in das bestehende Nanny-Bereitstellungssystem integriert, wodurch die YTsaurus-Migration entsperrt und RTC in eine vollwertige Cloud umgewandelt wurde. RTC verfügte damals über mehrere Zehntausend Server, und mit der Einführung von Map Reduce stieg diese Zahl deutlich an.

Neue Wachstumsschmerzen. Im gleichen Zeitraum entwickelte sich k8s zu einer viel ausgereifteren Lösung und wurde 2017 zu einem der AWS-Dienste. Aber es erfüllte immer noch nicht alle unsere Anforderungen:

• Größenordnung von Zehntausenden von Servern – eine k8s-Installation kann unsere Größenordnung immer noch nicht bewältigen.
• Die Unterstützung für Dual-Stack-IPv6 und IPv4 erschien in k8s erst im Jahr 2020, und IPv6 war für uns von Anfang an entscheidend.
• Unterstützung für verschachtelte Container, die wir benötigten, weil wir uns entschieden hatten, separate Batch- und Compute-Scheduler zu erstellen. Wir haben die Wirksamkeit dieser Option einmal mit der eines allgemeinen Planers verglichen und festgestellt, dass es bequemer und profitabler war, nicht zu versuchen, einen allgemeinen Planer für alles zu erstellen.

YTsaurus nutzte aktiv die Möglichkeit, verschachtelte Porto-Container zu erstellen, anstatt einen einzelnen Scheduler zu erstellen. Natürlich könnten wir selbst Unterstützung für denselben Dual-Stack in k8s hinzufügen. Die Erfahrung mit der Entwicklung des Linux-Kernels hat jedoch gezeigt, dass nicht alles an Open Source gesendet werden kann, und wir sind bestrebt, das Delta zum Upstream-Kernel auf ein Minimum zu beschränken, um die Aktualisierung auf neue Versionen zu vereinfachen.

Unsere Lösung heute. Die Architektur des RTC ist der von Kubernetes sehr ähnlich. Der Benutzer beschreibt seinen Dienst deklarativ in Form einer Spezifikation, die beschreibt, wie und in welchen Rechenzentren die angegebene Anwendung gestartet wird. Jedes Rechenzentrum verfügt über eine eigene Installation von Yandex Planner, der einerseits als Datenbank für alle Cluster-Objekte und andererseits als Pod-Scheduler dient. Auf jedem Server im Rechenzentrum wird ein Agent ausgeführt, der Pod-Spezifikationen von Yandex Planner empfängt und diese mithilfe unseres proprietären Porto-Containerisierungssystems startet.

Derzeit hat RTC Zehntausende Dienste eingeführt und über 5 Millionen Kerne auf über 100.000 Server verteilt. Täglich werden über 100.000 Leistungsbeschreibungen geändert.

Pläne. Was wäre, wenn k8s mit unserer Größenordnung zurechtkämen? Vor allem, da das k8s-Ökosystem uns irgendwann hinsichtlich der Funktionalität überflügelte. Wäre es nicht besser, auf k8s umzusteigen und zu hoffen, dass fertige Tools irgendwann das benötigte Volumen liefern? In der Praxis sind wir weiterhin ein Nischenkonsument für k8s, da nur ein kleiner Prozentsatz der Unternehmen in einem so großen Maßstab tätig ist und jedes Unternehmen über eigene interne Cloud-Lösungen verfügt.

Ein weiterer wichtiger Punkt, den es zu beachten gilt, ist das Migrationsproblem. Laut Juli 2018 Gartner erstellt ein Business Case für die Modernisierung von Multiplattform-Anwendungen Berichten zufolge werden bis 2025 noch 90 % der modernen Anwendungen im Einsatz sein und die technischen Schulden für die Entwicklung dieser Systeme werden mehr als 40 % des IT-Budgets ausmachen. Basierend auf unserer Erfahrung bei der Migration von Benutzerdiensten zu Yandex Planner entspricht dies nahezu der Realität: Im Jahr 2023 warteten noch etwa 100.000 Kerne darauf, dass sie an die Reihe kamen, um zu Yandex Planner zu wechseln.

Im Jahr 2021 haben wir bei der Auswahl unserer Entwicklungsstrategie geschätzt, wie viel es kosten würde, von einem Bereitstellungssystem auf ein anderes umzusteigen. Die Migration von Yandex zu Vanilla K8s wäre eine äußerst kostspielige Aufgabe, die Hunderte von Mannjahren kosten würde.

Auf diese einfache Weise sind wir bei unserer inneren Wolke gelandet, die wir in den nächsten 5 Jahren wahrscheinlich nicht aufgeben können, selbst wenn wir uns ein solches Ziel setzen.

Was ist gegen die fehlende interne Cloud-Funktionalität im Vergleich zu k8s zu tun? In der Praxis können unsere Kunden Managed Kubernetes in Yandex Cloud nutzen. Diese Option wird hauptsächlich für Projekte verwendet, bei denen strenge Compliance-Anforderungen erfüllt werden müssen – dies ist ein kleiner Anteil der Teams, weniger als 1 %. Aus den oben genannten Gründen sieht der Rest der Bevölkerung keinen großen Nutzen in einem Umzug.

Gleichzeitig beschäftigen wir uns aktiv mit k8s und überlegen, wie wir den allgemein anerkannten Standards näher kommen können. Bei einigen Aufgaben experimentieren wir bereits aktiv mit k8s, beispielsweise beim Cloud-Bootstrapping oder bei der Organisation von IaaC im Maßstab des gesamten Yandex. Idealerweise möchten wir die k8s-Schnittstelle wiederverwenden und gleichzeitig eine eigene Implementierung beibehalten, die möglichst auf unsere Bedürfnisse zugeschnitten ist. Jetzt muss nur noch herausgefunden werden, wie man es in der Praxis umsetzen kann.

• Was ist mit anderen? Da wir in diesem Artikel Big Tech im Allgemeinen diskutieren, ist es erwähnenswert, dass unser Fall nicht einzigartig ist. Besuche die Borg oder Schnur Fälle als Beispiele.

Geschichte Nr. 2: Monorepository

Probleme und Lösungsanforderungen . Unser Monorepository Arcadia verfolgt dasselbe Hauptziel wie unsere interne Cloud: die Bereitstellung praktischer Entwicklungstools. Im Falle des Repositorys umfasst dies ein ganzes Entwicklungsökosystem:

• Versionskontrollsystem (Arc),
• Schnittstelle (Arkanum),
• Build-System (du machst),
• CI/CD (NeuCI).

Arcadia entstand etwa zur gleichen Zeit wie die interne Cloud von Yandex. Einer der Gründe für die Erstellung des Monorepositorys war die Notwendigkeit, Code innerhalb von Yandex wiederzuverwenden. Dies wurde damals durch das Vorhandensein mehrerer Build-Systeme behindert. Um im Maßstab von Yandex zu funktionieren, war ein einheitliches System mit Unterstützung für effiziente verteilte Builds erforderlich. Außerdem sollte es stabil und benutzbar sein.

Implementierung eines einheitlichen Build-Systems. Unser proprietäres Build-System ya make kam 2013 auf den Markt, damals war es nur für C++-Code gedacht. Vor ya make haben wir CMake verwendet, aber aufgrund seiner Geschwindigkeit konnte es nicht auf die Größe eines Monorepositorys skaliert werden. Die proprietäre Version, die Sie erstellt haben, funktionierte viel schneller mit Arcadia. Es gab keine anderen Open-Source-Optionen, die unser Problem lösen konnten: Bazel wurde beispielsweise viel später, im Jahr 2015, veröffentlicht.

Skalierung des Versionskontrollsystems. Yandex verwendete zuvor SVN als Versionskontrollsystem. Obwohl SVN über eine große Kapazität verfügte, war diese dennoch begrenzt und schwer zu warten. Darüber hinaus war uns bewusst, dass wir irgendwann an die Grenzen der Möglichkeiten und des Komforts von SVN stoßen würden. Beispielsweise wurden Heuristiken verwendet, um die Möglichkeit zu implementieren, nur den erforderlichen Teil des Repositorys herunterzuladen oder selektiv auszuchecken. Aus diesem Grund begannen wir 2016, neben SVN auch mit anderen Versionskontrollsystemen zu experimentieren.

Mercurial war die erste Wahl. Aber das Hauptproblem, das wir hatten, war die Geschwindigkeit. Wir haben anderthalb Jahre lang versucht, Mercurial in Produktion zu bringen, aber die Ergebnisse waren enttäuschend. Beispielsweise mussten wir irgendwann Teile von Mercurial neu schreiben, um FUSE zu unterstützen, oder wir hätten das gesamte Repository auf den Laptop jedes Entwicklers bringen müssen.

Schließlich stellte sich heraus, dass es günstiger war, eine eigene Lösung von Grund auf zu schreiben, und 2019 erschien Arc – ein neues Versionskontrollsystem für Arcadia-Benutzer mit einer Git-ähnlichen Benutzeroberfläche. Die Grundlage von Arc ist FUSE (Dateisystem im Benutzerbereich) und nicht selektives Auschecken. Darüber hinaus fungiert YDB als skalierbare Datenbank, was den Betrieb von Arc im Vergleich zu Mercurial erheblich vereinfacht.

Wir werden oft gefragt, warum wir Git nicht verwendet haben. Weil es auch Skalierungs- und Funktionseinschränkungen gibt: Wenn wir nur den Arcadia-Trunk in Git importieren, dauert der Git-Status bei diesem Maßstab Minuten. Gleichzeitig gab es keine stabile FUSE-Implementierung, die auf Git aufbaute: VFS für Git wird nicht mehr entwickelt und EdenFS wurde schließlich in Sapling umgewandelt, aber das geschah viel später.

Aktueller Stand der Lösung und Pläne für die Zukunft. Um mit der Entwicklung zu beginnen, muss ein interner Benutzer lediglich einen Ordner in unserem Monorepository erstellen, Code schreiben und Ihnen mitteilen, wie er seine Anwendung erstellen soll, indem er das Build-Manifest hinzufügt. Als Ergebnis erhält der Benutzer Pull-Requests, CI-Konfiguration und die Möglichkeit, beliebigen Code im Unternehmen wiederzuverwenden.

In Bezug auf die Größe enthält der Trunk derzeit 10 Millionen Dateien, das gesamte Repository übersteigt 2 TiB und jede Woche werden mehr als 30.000 Commits durchgeführt.

Daher müssen wir in dem von uns geschaffenen Ökosystem viele Komponenten von Grund auf neu erstellen. Mittlerweile geht es jedoch um die Einhaltung globaler Standards. Arc unterstützt beispielsweise die Arbeit mit Git für eine vordefinierte Reihe von Projekten.

• Was ist mit anderen? Auch hier gilt: Wenn Sie Big Tech im Allgemeinen betrachten, sollten Sie als Beispiel darauf achten Setzling Und Pfeifer .

Was haben diese Geschichten gemeinsam?

Warum müssen große Technologieunternehmen ihre eigenen Lösungen erfinden und warum können sie nicht durch Lösungen ersetzt werden, die einem allgemein anerkannten Standard entsprechen?

1. Innovation. Große Unternehmen müssen häufig Lösungen für Probleme entwickeln, die erst in Zukunft alltäglich werden. So können innovative Lösungen entstehen, die das Potenzial haben, zum Marktstandard zu werden.

   
   

   Es ist nicht immer so, dass ein von einem Unternehmen gelöstes Problem jemand anderem als dem Unternehmen selbst gegenübersteht. Manchmal hilft die Erfahrung großer Technologieunternehmen mit einem bestimmten Problem der gesamten Branche, dieses Problem zu vermeiden, indem sie einen völlig anderen Entwicklungspfad einschlägt. Es ist nicht immer möglich, die Marktentwicklung vorherzusagen, und daher haben verschiedene Beispiele proprietärer Lösungen zu sehr unterschiedlichen Ergebnissen geführt.

   
   

   ClickHouse ist ein Beispiel für ein wirklich erfolgreiches innovatives Projekt, das den Bereich der Online-Analyseverarbeitung (OLAP) erheblich bereichert hat. Dies ist jedoch nicht bei allen Projekten der Fall. Das Porto, das als Open-Source-Projekt begann, konnte sich aus verschiedenen Gründen nicht durchsetzen. Obwohl einige seiner Funktionen, wie beispielsweise die Möglichkeit, verschachtelte Container zu erstellen, einzigartig bleiben.

   
   

2. Skala. Dieser Punkt ähnelt in mancher Hinsicht dem vorherigen, da nicht jedes Unternehmen mit dem Problem der Skalierbarkeit konfrontiert ist. Es gab eine Zeit, da waren 640 kByte mehr als genug für alle, nicht wahr?

   
   

   Tatsächlich war der exponentielle Anstieg der Systemlast einer der wichtigsten Gründe für die Entwicklung von Arcadia und der internen Cloud. Aus diesem Grund wurden Arc und Yandex Planner entwickelt. Arc wurde als Reaktion auf den Bedarf an einem benutzerfreundlichen VCS entwickelt, mit dem Benutzer problemlos mit einem Monorepository arbeiten können, das Dutzende Millionen Dateien in einem Stamm enthält. Yandex Planner wurde als Reaktion auf die Notwendigkeit entwickelt, effektiv mit Clustern aus Zehntausenden von Knoten und Millionen von Pods zu arbeiten.

   
   

   Öffentliche Tools weisen weiterhin Skalierungsprobleme auf (schließlich kommt dies relativ selten vor und eine Investition in sie ist häufig einfach unrentabel).

   
   

3. Trägheit. Stellen Sie sich ein internes Tool vor, das ein Problem innerhalb eines Unternehmens löst. Ein Unternehmen, das dieses Tool aktiv nutzt, würde Ressourcen aufwenden, um es besser an seine Bedürfnisse anzupassen und es schließlich in ein hochspezialisiertes Tool umzuwandeln. Dieser Prozess kann Jahre dauern.

   
   

   Bedenken Sie nun die Möglichkeit, dass irgendwann ein allgemein akzeptierter Standard zur Lösung dieses speziellen Problems entsteht. In diesem Fall kann die Spezialisierung dennoch ein wichtiger Faktor bei der Entscheidung für eine Inhouse-Lösung sein. Ziehen Sie Build-Systeme in Betracht. Wir verwenden Ihr Make bei Arcadia, es gibt jedoch auch Bazel von Google. Sie sind konzeptionell ähnlich, aber wenn man ins Detail geht, werden viele wichtige Szenarien unterschiedlich implementiert, da die Lastmuster für jede Arbeitslast drastisch unterschiedlich sein können. Infolgedessen müssen die bereits aufgewendeten Ressourcen mit ziemlicher Sicherheit erneut investiert werden, um einen neuen allgemein akzeptierten Standard anzupassen.

   
   

4. Migrationen. Wenn es im vorherigen Abschnitt um die Anpassung des Projekts an Benutzer ging, wenden wir uns nun der Migration der Benutzer selbst zu. Meiner Meinung nach sollte Migration nach der Nennung als das nächstwichtigste Problem im Technologiebereich bezeichnet werden. Wenn wir davon ausgehen, dass wir bereits über ein unternehmensinternes Tool verfügen und dieses durch ein standardisiertes ersetzen möchten, sind zwangsläufig Migrationen erforderlich.

   
   

   Aus unserer Erfahrung bei der Entwicklung einer internen Cloud kennen wir viele Beispiele für Migrationen. Umfangreiche Migrationen nehmen Zeit in Anspruch, daher müssen beide Tools über längere Zeiträume gleichzeitig unterstützt werden. Wenn an diesem Prozess eine große Anzahl von Benutzern beteiligt ist, sind Verwaltungsprobleme unvermeidlich. Es lohnt sich auf jeden Fall, eine Migration ohne Beteiligung des Benutzers durchzuführen, dies ist jedoch nicht immer möglich.

   
   

5. Geschäftskontinuität. Ehrlich gesagt hat dieser Punkt in letzter Zeit ausreichend an Bedeutung gewonnen. Bisher nahmen es nur sehr wenige Unternehmen ernst, weil sie Bedenken hinsichtlich einer Lieferantenbindung hatten. Kritische Prozesse einem Anbieter anzuvertrauen, der die Zusammenarbeit jederzeit beenden kann, ist riskant. Ein Paradebeispiel dafür ist JetBrains, das die Nutzung seiner IDEs auf bestimmte Unternehmen beschränkt hat. Ein weiteres typisches Beispiel ist Github Enterprise, das damit begonnen hat, in Russland ansässige Benutzerkonten zu sperren.

   
   

   Interne Lösungen sind in der Regel gegen dieses Problem immun. Einerseits gibt es weiterhin Open-Source-Lösungen. Andererseits gibt es keine Garantie dafür, dass das Open-Source-Modell Sie dauerhaft begleiten wird: Beispielsweise erschien Corona, die von Facebook selbst entwickelte Verbesserung der Planungssoftware Hadoop MapReduce, aufgrund der fehlenden Commit-Möglichkeit überhaupt erst die Patches, die für die Upstream-Skalierung von Hadoop erforderlich sind.

   
   

   Gleichzeitig betrifft der rechtliche Aspekt des Problems Open Source: Beispielsweise erfordern Commits in Golang oder K8s die Unterzeichnung einer CLA. Wird dies weiterhin ein Problem sein?

   
   

6. NIH. Ja, neben sachlichen Gründen ist es möglich, dass die getroffenen Entscheidungen nicht pragmatisch sind. Das ist das NIH-Syndrom vom Feinsten.

   
   

   Um beispielsweise den Einfluss von Batch auf die Rechenleistung zu eliminieren, haben wir versucht, einen eigenen Scheduler im Linux-Kernel zu erstellen. In der Praxis kam dabei nichts Gutes heraus; man hätte mit den vorhandenen Fähigkeiten des Linux-Kernels auskommen können. Je höher jedoch die Arbeitskosten sind, desto mehr Aufwand wird in die Ausarbeitung und Lösung des Problems gesteckt und desto geringer ist die Wahrscheinlichkeit, am NIH-Syndrom zu erkranken.

   
   Zusammenfassend lässt sich sagen : Wie Sie sehen, werden häufig Inhouse-Lösungen für große Unternehmen benötigt. Die meisten davon werden in Zukunft mit noch nicht ausgereiften einheitlichen globalen Standardlösungen verschmelzen, während der Rest der Vergangenheit angehört. In jedem Fall bleibt die Entscheidung zwischen einer proprietären und einer vorgefertigten Lösung eine schwierige Frage, die nicht beantwortet werden kann, ohne zunächst den Kontext zu verstehen und die Kosten eines solchen Projekts abzuschätzen.