Das Ende der Standardsoftware

Große Common-of-the-Shelf Software (kurz: COTS) Pakete sind schwer zu implementieren und zu integrieren. Es ist keine gute Idee, ein großes Softwarepaket zu kaufen. Im Folgenden werde ich Ihnen erklären, wie Sie mit agilen Methoden und Services auf leichtgewichtigen Containern minimale, zielgerichtete Lösungen implementieren können. Bevor ich jedoch beginne, muss ich Ihre Aufmerksamkeit auf diese neue Website lenken, die ich gefunden habe: Spamzilla. Wenn Sie eine Website entwickeln wollen, sollten Sie sich diese Website unbedingt ansehen. Ausgehend von dem Standard-Softwarepaket [Hardware | Betriebssystem | App-Server | Geschäftslogik | Benutzeroberfläche] enthalten COTS-Pakete einen Teil des App-Servers, die gesamte Geschäftslogik und die vollständige Benutzeroberfläche. Beispiele hierfür sind Pakete für die Vertriebsunterstützung, das Finanzmanagement oder das Marketing. Große und unhandliche Biester, die sich in Ihrer IT-Infrastruktur tummeln und Heerscharen von Spezialisten benötigen, um sie am Laufen zu halten, und die darauf bestehen, dass Sie Java 1.6 und Oracle 10 auf Redhat 4.2, IE 8.0 und dem größten, fiesesten Server installieren, den man für Geld kaufen kann.Wahrscheinlich begann alles mit ehrenwerten Absichten: Kaufen statt wiederverwenden statt bauen scheint absolut sinnvoll zu sein, wenn man nicht zu genau hinsieht. Ich stimme Ihnen sogar zu, auch wenn wir in einem wichtigen Punkt anderer Meinung sind, und das ist der Umfang. In den alten Wasserfalltagen waren wir es gewohnt, eine Architektur zu schreiben und eine Bestandsaufnahme der Geschäftsanforderungen zu machen. Da die Leute schnell lernten, dass sie selten mehr als eine Gelegenheit bekamen, nach dem zu fragen, was sie brauchten, neigten sie dazu, sehr viel zu fragen und so viele Funktionen einzubauen, wie sie sich vorstellen konnten. Irgendwann im Entscheidungsprozess wurde allen klar, dass sie genauso gut etwas wirklich Vielseitiges kaufen könnten; ein großes Softwarepaket, das alle Anforderungen jetzt und in der Zukunft erfüllt.Alles ist gut.Bis der nächste Geschäftsbedarf auftaucht und die gleiche Argumentation (alle Spezifikationen im Voraus festlegen, eine Chance, es richtig zu machen, ein bisschen mehr verlangen, kann nicht schaden) zu einem anderen Paket führt, das einige Überschneidungen mit dem ersten hat, aber nicht zu viel, also ist es OK. Dann entsteht die Notwendigkeit, Daten zu synchronisieren (wegen der leichten Überschneidungen zwischen den Paketen), und ein ESB wird implementiert (weil man genauso gut ein Softwarepaket kaufen kann, oder?). Jetzt gibt es zwei Ofenrohre in Ihrer Landschaft, die mit einem SPOF zusammengeklebt sind, und die Dinge sind nicht mehr in Ordnung. Wenn Sie etwas ändern wollen, müssen Sie die Arbeit mehrerer Teams koordinieren. Das Testen und Integrieren wird zur Aufgabe eines großen Teams. Kein Team hat die Definition von "funktioniert in der Produktion". Das Beste, was Sie sich erhoffen können, ist, dass es auf meinem Rechner funktioniert und dass jemand anderes alle Integrationsprobleme beheben wird. Oh, und die Leute, die diese Software benutzen, wechseln zwischen schlecht gestalteten Bildschirmen, die in einem Haufen von Browsern von gestern laufen. Wie können moderne Softwareentwicklungsweisheiten und -architekturen helfen? Zwei Trends ermöglichen es uns, Stovepipes zu vermeiden, die durch Superkleber verbunden sind: Microservices, die auf leichtgewichtigen Containern gehostet werden, und agile Methoden. Microservices auf leichtgewichtigen Containern wie Docker oder vielleicht Dropwizard oder Spring Boot sind das Ende des Anwendungsservers, der uns im letzten Jahrzehnt so gut gedient hat. Wenn Sie Ihre Anwendung skalieren können, indem Sie einen neuen Prozess auf einer neuen VM starten, brauchen Sie keine komplexe Software zur gemeinsamen Nutzung von Ressourcen. Das bedeutet, dass Sie nicht wirklich viel Infrastruktur benötigen. Sie können kleine Komponenten mit vernachlässigbarem Overhead einsetzen. Mit Key-Value-Datenspeichern können Sie die Beschränkungen für Daten lockern, die bei relationalen Datenbanken gelten. Ein Dienst kann zwei Versionen einer Schnittstelle gleichzeitig unterstützen. In Kombination mit REST, einem DNS und einem Load Balancer ist dies das Ende der ESBs. Agile fördert stabile Teams und Budgets, die einem Team und nicht einem Projekt zugewiesen werden. Das bedeutet, dass wir eigentlich keine Budgetberechnungen mehr durchführen müssen. Da wir in jedem Sprint die Richtung ändern können, brauchen wir nicht mehr nach der Welt zu fragen, wie wir es in der Wasserfallzeit getan haben. Das bedeutet, dass wir das kleinste Ding entwickeln sollten, das das Problem lösen könnte, anstatt das größte Biest zu kaufen, das alle unsere Probleme und einige andere, die wir gar nicht haben, lösen wird. Das bedeutet nicht, dass wir keine Software mehr kaufen sollten. Was ich gerne sehen würde, ist, dass sich Anbieter auf kleine, spezialisierte Komponenten konzentrieren: einen hochspezialisierten Dienst, der hochmoderne Algorithmen zur Bewertung des Kreditrisikos verwendet, oder eine Komponente, die alles über die Registrierung und Überwachung von Kundendienstanrufen weiß. Das wäre großartig. Aber keine Benutzeroberfläche, danke, die erstellen wir gerne selbst, indem wir die Daten mit einem HTTP-Aufruf abrufen und sie genau so darstellen, wie sie benötigt werden.