Java Magazin - 08.2014 - Microservices


Preis: 9,80 €

Erhältlich ab:  Juli 2014

Umfang:  100

Autoren / Autorinnen: Oliver B. Fischer, Sebastian Meyen, Stephan Klevenz, Arne Limburg, Lars Röwekamp, Moritz Rebbert, Hartmut Schlosser, Claudia Fröhling, Timmo Freudl-Gierke, Arno Haase, Eberhard Wolff, Philipp Bayer, Christian Laboranowitsch, Daniel Schneller, Lukas Pustina, Angelika Langer, Klaus Kreft, Denny Israel, Jan Mischlich, Sven Ewald, Jens Deters, Holger Kraus, Arne Landwehr, Peter Hruschka, Gernot Starke, Christian Robert, Željko Markovic, Mauro Talevi, Matthias Schaff, Dominik Helleberg

Und plötzlich war sie da, die neue Programmiersprache Swift. Obwohl Apples Geheimniskrämerei eine schallende Ohrfeige für alle ist, die an einen offenen Entwicklungsprozess glauben, fasziniert die neue Sprache, und zwar über alle technischen Lager hinweg.

Swift, das seit Jahren hinter verschlossenen Türen entwickelt wurde, vereint Elemente aus den meisten Sprachen, die heute den Ton angeben – dort ein wenig Java, hier ein paar Elemente aus Scala, nebst ein paar Zutaten von Groovy, dort noch etwas Ruby, C# und Go und schließlich noch je eine Prise Kotlin und Rust. So in etwa könnte das Kochrezept lauten, das Chris Lattner, Urheber der Sprache bei Apple, seit 2010 entwickelte.

Welchen Zweck also hat die neue Sprache mit dem Mauersegler („Swift“) im Wappen? Zunächst galt es für Apple, für das in die Jahre gekommene Objective-C eine moderne Alternative anzubieten.

Zweitens wäre Apple nicht (mehr) Apple, wenn es auf eine der existierenden Sprachen gesetzt und etwa Offenheit gegenüber der „Außenwelt“ demonstriert hätte. Das Gegenteil ist weiterhin der Fall: Die Sprache, der von vielen Experten ein ausgereiftes Design bescheinigt wird, ist rein für die Apple-Welt gemacht und wird für andere Communitys keine Relevanz haben.

Drittens macht Apple üblicherweise kein großes Federlesen, wenn es um das Abstellen „veralteter“ Technologien geht. Genau so, wie ab Herbst die softwareseitige Unterstützung für das iPhone 4 beendet wird, wird auch Objective-C in vermutlich zwei bis drei Jahren ganz lautlos von der Bildfläche verschwinden. Die langwierige Pflege von Altlasten ist Apples Sache noch nie gewesen.

Sprachen im Mittelpunkt

Welche Bedeutung hat Swift also für den Rest der Welt? Die Beschäftigung mit (alternativen) Programmiersprachen und allgemeiner Sprachinnovation ist keine akademische Spielerei, sondern essenziell in einer Industrie, in der die technische Beschreibung von Problemen praktisch im Mittelpunkt steht. Trotz immer reifer werdender Tools, Plattformen und Automatisierungsmechanismen ist die Sprache für den Entwickler zentral. Das hat immerhin auch Apple erkannt und einen Sprung in die Gegenwart vollführt.

Übrigens stand nur wenige Tage nach dem Swift-Release eine neue Betaversion von Groovy bereit – das erste Groovy, das sich auch für die Android-Entwicklung verwenden lässt! Somit hat auch Android demnächst seine neue Sprache, wenn es auch gewiss nicht um die Abschaffung der „alten“ Sprache Java geht.

Das Ende der Monolithen?

Microservices heißt ein neues Konzept, das seit geraumer Zeit von sich reden macht. Die Grundidee ist schnell erzählt: Wenn Applikationen nicht als Monolithen ausgeliefert, sondern als Bündel autonomer Services deployt werden, so kann das verschiedene Vorteile haben.

Aber Achtung: Niemand sagt, dass Sie jetzt Microservices verwenden müssen! Es handelt sich in erster Linie um einen Architekturstil, wie Martin Fowler schreibt, und ob dieser Stil die angemessenen Antworten auf eine gegebene Fragestellung hervorbringen kann, muss jeder für sich selbst entscheiden.

Während es in der Geschichte der Informatik schon viele Konzepte der Entkoppelung von Einheiten gegeben hat – denken Sie an die Objekttechnologie, die Komponenten, die Services im Sinne einer SOA – scheint die Pointe bei den Microservices darin zu liegen, dass einzelne Entwickler oder ganze Teams Verantwortung für „ihren“ Service nicht nur für die Dauer der Entwicklung, sondern für den gesamten Lebenszyklus tragen.

Vom Projekt zum Produkt

In klassischen Softwareprojekten besteht das Ziel darin, eine gegebene Aufgabe unter Einhaltung von Budget- und Zeitvorgaben „fertigzustellen“. Was danach passiert, obliegt dem Betrieb. Die Idee eines „Produkts“ legt nahe, dass, ganz im Sinne von DevOps, ein Team Verantwortung für seine Software trägt, ein ganzes Leben lang.

Dass wir damit elegant die Brücke zu DevOps geschlagen haben, liegt auf der Hand. Aber lassen Sie mich noch einen weiteren Aspekt von Microservices anfügen: Durch die Konzentration auf die fachlichen Belange, nicht die technischen, wird die Bildung crossfunktionaler Teams, die in die Lage versetzt werden, stärker im Businesssinne mitzudenken, begünstigt.

Alles kann, nichts muss – und selbst der große Martin Fowler mag nicht ausschließen, dass die genannten Ziele nicht auch mit monolithischen Systemen zu erreichen sind. Mit Microservices lassen sich keinesfalls veränderte Architekturen oder gar Entwicklungskulturen erzwingen – es bleibt ein Stil, und es bleibt dabei: Finden Sie selbst heraus, was zu Ihnen, Ihren Produkten und Ihren Kunden am besten passt.

meyen_sebastian_sw.tif_fmt1.jpgSebastian Meyen, Chefredakteur

Website Twitter Google Xing

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang