Tausende von Startups drängen auf den Markt. Universitäten haben Startup-Maschinen entwickelt, die jährlich tausende technologisch orientierte Unternehmen auf den Markt werfen. In jeder größeren Universitätsstadt gibt es Kollaborationen zwischen Startup Zentren und den Lehrstühlen für die entsprechenden Thematiken.
Dazu kommt, dass fast alle Fördertöpfe der Länder und des Bundes sich auf technologische Entwicklungen konzentrieren. Die Entwicklungslandschaft hat noch nie so viele Initiativen gesehen. Die Gründungen schießen durch die Decke und immer mehr neue Plattformen entwickeln sich zu Inkubatoren, Brutstätten IT-technologischer Co Working Boostern.
Täglich entstehen dadurch neue Angebote, auch wenn zwei von drei die ersten drei Jahre nicht überleben, alleine die gewaltige Anzahl an Startups bringt einen Wettbewerb in den Markt, wie er noch nicht dagewesen ist. Ausgerechnet der Mittelstand aber scheint die Entwicklung zu verschlafen, hier wird nach bewährtem Muster die IT weiter gefahren.
Never touch a running system
Was funktioniert, soll man laufen lassen, das ist nichts neues, doch diese Einstellung hat einen riesigen Haken. Der Disruption ist es egal, ob und wie ein System funktioniert. Eine fundamentale Disruption macht eine alte Funktion einfach überflüssig. Die letzte Generation der Reprokameras hat absolut topp funktioniert, am Ende konnte sie im Tausendstel Millimeter Bereich klare Aufnahmen machen. Heute sind diese Maschinen längst verschrottet oder im Museum. Warum, weil sie nicht gut waren? Nein, sie waren exzellent, doch die Disruption der Computertechnologie machte sie innerhalb zwei Jahren überflüssig.
Keine Technologie und kein Unternehmen, Größe und Branche spielen dabei keine Rolle, ist sicher vor radikalen Disruptionen. Sind Sie darauf vorbereitet, haben Sie eventuell die Chance sich schnell anzupassen. Für die IT Landschaft gilt es, die Risiken für eine disruptive Entwicklung frühzeitig einzuschätzen und entsprechende Anpassungen so schnell wie möglich umzusetzen. Experten sehen in der Software-Architektur der Microservices-Methoden die größte Chance, um Innovationen schnell umsetzen zu können. Wurden in den Konzepten der Software Entwicklungen bereits Microservices-Architekturen eingeführt, ist die Anpassung an disruptive Entwicklung weitaus sanfter möglich.
Viele Organisationen, die eine Strategie für aufkommende Innovationen entwickelt haben, machen dies mit Microservices-Architekturen, doch es gibt sie noch, die tradierten Unternehmen, die bei eintreffender Welle einer Disruption von ihr weggespült werden.
Warum Microservices so bedeutend sind?
Die Design-Grundlagen für Microservice-Architektur zeigen sich an der Struktur der Aufteilung von Diensten. Die kleinste Einheit einer Software ist der unabhängige Dienst, der seine Funktion über eine standardisierte Schnittstelle dem Ganzen zur Verfügung stellt. Wenn Sie weitere Details zu Microservice kennen lernen möchten, lesen Sie unseren Newsletter zu diesem Thema. An dieser Stelle sei nur darauf hingewiesen wie die Microservice-Architektur helfen kann, eine Disruption als Welle zu benutzen und nicht davon weg gespült zu werden. Diese kleinen Einheiten haben alle eine einzelne Aufgabe zugewiesen bekommen und fügen sich so in ein modulares Konzept ein.
Die Implementierung von Microservices innerhalb einer Softwarelandschaft eines Unternehmens macht es leicht, einen einzelnen Dienst hinzuzufügen oder auszutauschen. Jede Neuerung kann über Schnittstellen Protokolle wie HTTP (REST) oder auch asynchron (z.B. über AMQP) geregelt werden.
Microservices werden auch als Container bezeichnet, da sie wie eine Blackbox funktionieren können, die nicht voneinander abhängig sind. Ein Entwicklungsteam kann somit einen bestimmten Microservice unabhängig von Auswirkungen auf andere Subsysteme entwickeln oder verändern.
Ein hilfreiches weitergehendes Whitepaper finden Sie bei Microsoft.
Das Konzept für Microservice Architekturen
Sollten Sie sich auf diese Technologien konzentrieren wollen, müssen die Entwickler einige Vorgaben erfüllen. Eine dezidierte Planung der Struktur der Microservice -Architektur ist unabdingbar. Da bei den einzelnen Diensten das Zusammenspiel mit anderen Containern im nach hinein über den Erfolg des Ganzen entscheidet, sind standardisierte Schnittstellen und ein genauer Plan der Datenbanken und deren Services nötig. Dabei soll der Entwickler aber darauf achten, dass sein Container ein unabhängiger Container mit einem einzelnen Microservice bleibt. Im Zweifelsfall funktioniert das Ganze ohne den einzelnen Container, nur eben nicht so erfolgreich wie gedacht.
Das nachfolgende grobe Beispiel von einer Anwendung für einen Online-TAXI Service macht es deutlich.
