Swift: Die eine Programmiersprache für „alles“ ?! (Teil1)

tl;dr

• Swift eignet sich bereits jetzt zur Entwicklung einer produktiven verteilten mobilen Anwendung (Client-App + Backend-Webservice)
• Proof-of-Concept Beispiel: verteilte App mit Shared Code
• Deployment des Webservices via Docker-Container
• Große Vorteile für Developer, DevOps, CTOs, CIOs und die zentralen Stakeholder/Kunden
• Update: links und libraries-Empfehlungen

Apples Swift und Open Source

Im Juli 2014 hat Apple der Öffentlichkeit die neue Programmiersprache Swift vorgestellt. Zunächst wurde auf den eigenen Plattformen die Software-Entwicklung mit dieser Sprache realisiert: von der kleinen Smartwatch appleWatch (watchOS), über die Set-Top-Box appleTV (tvOS), auf ihren mobilen Geräten iPhone/iPodTouch/iPad (iOS) bis hin zu ihren Desktop-Geräten MacPro/iMac/MacBookPro/… (OSX).

Vor etwa einem halben Jahr (Dezember 2015) ging Apple dazu über, Swift als Open-Source Projekt der Öffentlichkeit bereitzustellen. Apple war mit diesem Schritt derart entschlossen und überzeugt, dass sie die Vorteile von ihrer aktuellen Programmiersprache Swift -z.B. die Flexibilität und die Skalierbarkeit (von Command-Line-Tools über Software für ‚kleine‘ embedded IoT-Geräte bis hin zu Server-Systemen und Betriebssystemen), die maschinennahe performate Ausführung  der damit erstellten Software (kompilierter/nativer Binär-Code !), sowie die modernen Features und Sprachkonstrukte- der gesamten Developer/IT-Community bereitgestellt haben wollten. Das ausgesprochene Ziel Apples: Durch die verändernden Software/IT-Anforderungen heutiger Systeme und Anwendungen, die in die Jahre gekommene native Programmiersprache C (bzw. auch C++) als de-facto-Standard mittelfristig abzulösen. Ein sehr ehrgeiziges Ziel -wie man ruhig finden darf- das nur durch Offenlegung und die Beteiligung der großen Entwickler-Community überhaupt erst machbar sein kann.

Folgerichtig musste hierfür Apple aus ihrem eigenen Kosmos ausbrechen und über ihren Schatten springen: „Swift ist nun für alle da“. Jeder kann sich nun an der „Evolution“ der Sprache selbst beteiligen (in der aktuellen 2.2-Version der Sprache, die Apple selbst in ihren eigenen Entwicklungstools xCode7.3 und aufwärts einsetzt, sind schon Beiträge und Änderungen/Anpassungen von über 200 Nicht-Apple-Beteiligten inbegriffen). Doch der Open-Source Gang von Swift hat noch einen vollkommen „uneigennützigen“ Effekt für die Sprache: Es wurde für Swift gleich eine Referenzimplementierung für die Linux-Plattform (Ubuntu: daily-ci-builds, snapshot-releases) bereitgestellt. Von diesem Moment an hat die Programmiersprache eine völlig neue Reichweite in der Developer-Community erreicht und wird somit gleich von vielen Entwicklern in zahlreichen Open-Source-Projekten auf die Probe gestellt; Die zentrale Frage lautet: Ist die Skalierbarkeit, Flexibilität und Portierbarkeit tatsächlich für solche vielschichtigen Herausforderungen und Ziele der modernen Software-Entwicklung geeignet, wie es Apple auf seinen eigenen Plattformen ‚vorlebt‘?

Community-Projekte und Portierungen mit Swift

Die Open-Source Community hat gesprochen/reagiert: Swift wurde in kürzester Zeit angenommen und daraufhin auf weitere Plattformen migriert/portiert (wip). Um es aus der Skalierungs- und Flexibilitätsperspektive zu sehen (für die eigene Einschätzung) eignen sich folgende Projekte, die bereits heute auf der Programmiersprache Swift basieren, besonders gut als Einblick (ein Auszug):

• Die besondere out-of-the-box-Verträglichkeit/Kompatibilität von Swift mit low-level-C APIs sorgte für eine recht zeitnahe Migration der Sprache auf den Rasberry-PI . Wer die Software-Entwicklung auf seinem kleinen „Bastelcomputer“ zu Hause bisher gescheut hat, da u.A. „kryptische“ Low-Level C (Pointer-Arithmetik 😉 ) Kenntnisse notwendig waren, kann man nun mit dieser „modernen“ Hochsprache, die zudem eine kurze Lernkurve verspricht,  die zukünftigen Anwendungen der Internet-of-Things (IoT) programmieren.

• Auch die führenden „Wettbewerber“ von Apple, sowohl auf dem Desktop (Windows) und dem mobilen Plattform-Markt (Android) wurden in der Vergangenheit nicht von einer Nutzung/Migration durch Swift als Software-Entwicklungssprache ‚verschont‘. Der Mehrwert und die klare und moderne Syntax der Sprache überzeugte selbst hartgesottene C# und Java-Entwickler (die offen genug für Neues sind und nicht die Gewohnheit siegen lassen 😉 ). Selbst notgedrunge Cygwin-Nutzer auf Windows können mitterweile swiften. Seit Google mit größeren rechtlichen Auseinandersetzungen mit Oracle zu kämpfen hat, wird auch ernsthaft darüber nachgedacht Swift als Programmiersprache für Android einzusetzen. Die optimale C -und ab Swift 3.0- auch C++ API-Bridging/Kompatibilität macht es zu einer optimalen Nachfolge-App-Programmiersprache für das jetzige hauptsächlich genutzte Java auf der Android-Plattfrom. Facebook und Uber sehen in Swift bereits auch einen würdigen technologie-strategischen Kandidaten. (Einigen Facebook-Mitarbeitern kann es hier wohl nicht schnell genug gehen mit Swift auf Android.)

• Abseits der „Hobby-Bastler-Ecke“ mit kleinen (z.T. embedded) Devices und Desktop-Anwendungen existiert insbesondere auch für Server-Dienste (Webservices, Webseiten, Webportale, etc.) eine große, wenn nicht sogar die größte Entwickler-Zielgruppe wenn man die offiziellen Linux-Bestrebungen von Swift genauer betrachtet. Auch für Backend/Middleware-Anwendungen gibt es bis dato zahlreiche nennenswerte Community-Projekte zu verzeichnen:
  • Kitura: ein leichtgewichtiges Webframework von IBM, das bereits mit einer Webserver-Implementierung an Board ausgeliefert wird. Damit wird eine rudimentäre Bibliothek bereitgestellt, um Webservices mit Swift umzusetzen. IBM verfolgt bereits ab der ersten Stunde (2014) die Bestrebung, intern ihre Software-Engineers mit dieser Sprache „awesome solutions“ realisieren zu lassen. 😉 Wer ohne große Installationen mit seinen ersten Swift-Gehversuchen gleich loslegen möchte, kann mit diesem IBM-eigenen-Webportal direkt im Browser den aktuellen Entwicklungsstand der im Herbst finalen 3.0-Version von Swift mit einem „Hello world“ bewundern und editieren.  –> „pretty awesome“ 😉
  • Perfect: eine Open-Source Toolchain eines mittlerweile eigenes dafür/drumherum gegründeten Startups; es verspricht sowohl für Frontend-Belange (z.B. App oder Webseite) als auch für das zwangsläufig benötigte Gegenstück eines Server-Backends mit nur einer Programier-Sprache (Swift) und einer homogenen Entwicklungsumgebung (insbesondere auf dem Mac für xCode) zu dienen.
  • „Alles schön und gut, aber in der realen Entwicklungs-Welt von Webanwendungen und Webservices wird ein solides Software-Fundament mit grundlegender Basis-Funktionalität und Flexibilität benötigt, um den modernen Anforderungen einer Server/Backend-Entwicklung gerecht zu werden. Das Rad muss (und will)  ja nicht neu erfunden werden. Man will ja die eigentliche Webanwendung effizient entwickeln (mit Swift), nicht jegliche Grundfunktionalität auch selbst umsetzen müssen“ — würde jetzt manch einer berechtigterweise sagen.
    • Für diese Argumentation gibt es für die meisten aktuell verbreiten Server-Programiersprachen entsprechende fertige Software-Bibliotheken bzw. ganze Frameworks; bei PHP (Symfony) und bei Ruby (Rails) – hier mal als exemplarisches Beispiel genannt. Nebenbei erwähnt: Diese Skriptsprachen haben gegenüber Swift den Nachteil, dass deren Source-Code bei der Ausführung interpretiert werden muss und somit entscheidende Performace-Nachteile in der Ausführungszeit entstehen gegenüber einer nativ-kompilierten Swift Executable/Binary.
    • Andere Webtechnologien, die beispielsweise auf  „Zwischen-Maschinencode“ (für VM-Runtimes) setzen, um die Geschwindigkeit bzw. Reaktionszeit indirekt „responsiver“ zu halten (hier sei Java und .Net erwähnt) haben auch einige Defizite gegenüber Swift; z.B. historisch bedingte Speichermanagement-Philosopien im Einsatz (hier sei die regelmäßige stattfindende Garbage-Collection erwähnt), welche insbesondere bei datenallokierungs-intensiven Anwendungen zu einem langsameren Anwendungs-Laufzeitverhalten führen (im Vergleich zum effizienteren Swift-basierten Automatic-Reference-Counting/ARC). Zudem agieren diese Anwendungen auch nicht so ressourcenschonend wie das modernere Swift (was den Arbeitsspeicher/RAM und dessen ‚peaks‘ angeht) .
    • Generell kann man als weiteren ‚Vorteil‘ einer binär-auslieferbaren/ausführbaren (kompilierten/nativen) Backend-Anwendung erwähnen, dass damit auch lizenzrechtliche Modelle (z.B. kostenpflichtige Premium-Tools) besser abbildbar sind, wobei der SourceCode der Lösung/Produktes nicht mit ausgeliefert werden muss. (Im Gegensatz zu den Skriptsprachen PHP, Ruby, JS, etc.)
  • Als letztes Beispiel für ein Swift-basiertes Webframework sei hier Switon erwähnt: Dieses Open-Source-Projekt hat ebenfalls einen Webserver mit an Board und bietet (angelehnt an Rubys Unicorn) -im Gegensatz zu dem erwähnten Kitura- eine Symfony und Ruby-on-Rails ähnliche Architektur bzw. Anwendungs-Strukturierungs-Konvention samt Basis-Funktionalitäten. Durch diese bereits bestrittenen Bemühungen der Open-Source-Community bietet dieses Framework einen idealen Einstiegspunkt für eine ersten selbstprogrammierten exemplarischen Swift-Webservice auf einem Linux-Server.

 

Eine verteilte Swift-Webanwendung – Ein Proof-of-Concept:

Ein lange gelebter Traum von IT/Software-Unternehmen mit Entwicklungs-Teams war es schon immer, auf eine (oder sehr wenige) dedizierte Technologien zu setzen, bei denen man möglichst viele, um nicht zu sagen nahezu alle Belange von Softwareentwicklungen abdeckt. Jeder CTO hat ein berechtigtes Interesse, seine eingesetzten Technologien, Tools, Kompetenzen, Know-How in seinen Entwicklungs-Abteilungen so homogen und ‚zukunftsfähig‘ wie möglich zu halten. Das ist nicht nur ein kostenorientierter Faktor für ein Unternehmen  (Experten, Know-How/Expertise, Lernkurven, Umsetzungs-Effizienz sind große Kostenfaktoren aber auch das größte Gut von Tech-companies) sondern auch eine zentral strategische Entscheidung bei der heutzutage stetig wachsenden Digitalisierung unseres Lebens-Alltags. Gewissenhafte und zukunftorientierte CTOs bewerten stetig neue Möglichkeiten und Wege, technologische Neuerungen entweder selbst zu adaptieren oder von einem erfahrenen Lösungs-Dienstleister (wie SIC! 😉 ) zukunftsweisende Produkte umzusetzen bzw. hausintern ‚gecoached‘ betreut etablieren zu lassen.

Aus der Ecke „Eine Technologie für alles“ (one size fits all) gibt und gab es mehrere technologische Bestrebungen die letzten Jahre: allen voran die bereits erwähnten: Java, .Net aber auch Javascript. Swift will sich hier differenzieren: Leicht zu lernen sein, effizient geschriebenen und leicht verständlichen streng-typisierten Code garantieren (wenige LOC selbst für ‚komplexe‘ Kostellationen), und Top-Performance in der Anwendungs-Ausführung bieten. Das sind die wahren Stärken von Swift und diese bieten einen gehörigen Mehrwert in der Entwickler-Praxis.

Erfahrene Entwicklungs-Teams wissen, dass eingesetzte Technologie insbesondere dann effizienzsteigernde Effekte bei der täglichen Arbeit hervorbringt, wenn bereits geleistete Umsetzungen wiederverwendet werden können (shared-code); und zwar nicht nur in ein und der selben Anwendung mehrmals verwendet, sondern auch möglichst für andere Anwendungen nutzbar. Diesem Shared-Code-Paradigma wollen wir uns auch bei der Umsetzung der nachfolgenden gezeigten kleinen/exemplarischen verteilten Swift-Anwendung annehmen (verteilt im Sinne von Backend-Code + Frontend-Code/App + etwaiger Shared-Code).

Sinnvoll ‚geshared‘ zwischen Anwendungen können in der Praxis ‚Modell‘-Klassen und Engine/Helper/Wrapper-Bestandteile, welche diese Datenmodelle einsetzen. Für den exemplarischen Swift-Webservice, der hier lediglich als „Proof-of-Concept“ für die heutzutage möglichen Realisierungen von Swift-Serveranwendungen dient, planen wir einen einfachen Service, der einen HTTP-(Post)-Request mit Daten (JSON) annimmt und mit einer entsprechenden Response (ebenfalls JSON-Daten) antwortet. Um sowohl die Machbarkeit als auch eine „Dynamik“ der Anwendung hier zu präsentieren, fällt die Response inhaltlich, abhängig von den Request-Daten, unterschiedlich aus. Um dem code-sharing Aspekt gerecht zu werden, wird sowohl im Webservice als auch in der App, die mit dem Webservice ’spricht‘,  sowohl auf Server- als auch auf Client-Seite mit der selben JSON-Strukturierung/Datenmodellierung gearbeitet.

Somit agieren diese Modell-Klassen für den Daten-Austausch (Request/Response) als optimale Kandidaten für ein separates Git-Repository (als Git-Submodule für die jeweiligen Client- und Server-Code-Repos) für den Shared-Code:

Swift Shared-Code:

Die beiden obigen exemplarischen Datenmodell-Klassen nutzen den JSON-Typ, um die definierte Anwendungs-Kommunikations-Struktur zu serialisieren/deserialisieren; dieser Typ ist Bestandteil der weit verbreiteten (und empfehlenswerten) leichtgewichtigen SwiftyJSON-Bibliothek (ebenfalls nutzbar in Client und Server-Code)

Eine Real-World Anwendung könnte hier viel mehr Komponenten als wiederverwendbare Module herauslösen, um komplexe Anwendungsszenarien zu realisieren, wie beispielsweise die Umsetzung von Fat-Clients, die mit dem Server Daten von mehreren Gigabytes (Datenbanken mit mehreren Millionen Einträgen im 7/8-stelligen Bereich) austauschen und Persistieren, um eine offline-fähige Nutzung zu gewährleisten; inklusive einer Delta-basierten Synchronisation des riesigen lokalen Datenbestandes. (auch insbesondere heute noch sind mobile Internet-Szenarien in der Praxis nur selten im alleinigen Online-Betrieb/Webservices möglich da die Netzabdeckung und der Nutzungskontext, z.B. in Kellern oder anderweitigen Regionen schlecht bis garnicht verfügbar ist). Beispiele wie diese aber auch weitere realitätsnahe Anforderungen sind mit einer nativen/performanten Sprache wie Swift ideal zu lösen sind.

Die obere Package.swift Datei ist eine Art Meta-Information auf Dateisystem root-Ebene des eingeführten ‚SharedCode‘-Git-Repositories, um später dem Swift Build-Prozess sowohl diesen SharedCode als downloadbare Einheit (Package) zu definieren, aber auch, um später beim Einsatz des SharedCodes im Anwendungs-Code dieses mit dem definierten Modulname „SharedCode“ zu importieren. Interessanterweise nutzt das nun quelloffene Swift als Meta-Sprache für den Bauprozess selbst syntaktisch Swift; also auch hierfür muss keine neue „Meta“-Sprache erlernt werden. 😉 (Im Gegensatz zu den bisherigen verbreiteten OSX library-dependency-manager CocoaPods und Carthage)

Swift Server-Code:

Als Einstiegspunkt/Hook einer Swift-Anwendung dient, wie bei vielen Programmiersprachen auch, die main(.swift) Datei. Diese fällt in unserem exemplarischen Server-Fall sehr klein aus: Wir geben hier lediglich an, welche HTTP-Methode unser Webservice unterstützt (post), welche (URL/Path) Routen er unterstützen soll („/login“), welche Klasse sich um die Abhandlung einer HTTP-POST-Anfrage auf diese Route kümmern (LoginController) und welche „Action“ diese Controller-Klasse für diese Route ausführen soll. Mit der (blockierenden) Funktion serve() wird der eingebaute HTTP-Webserver Curassow gestartet und wartet/horcht auf eingehende HTTP-Request Anfragen von Clients. Mehr Konfiguration oder Routing-Einstellungen benötigen wir erstmal nicht.

Die Implementierung der in der main.swift referenzierte/initierte LoginController Klasse haben wird hier auch klein gehalten. Unter dem Einsatz der beiden geshared-ten Modellklassen LoginRequest und LoginResponse (Unser erstelltes Modul „import SharedCode“ wird hierfür eingesetzt) wird die definierte Action „login“ implementiert: Hierfür wird das userId-Property von unserer Request-Datenmodell-Klasse verwendet, um das text-Property der Response-Datenmodell-Klasse (pseudo-dynamisch) zu berechnen/abzuleiten. 😉 Diese beiden Implementierungsdateien reichen bereits aus, um einen rudimentären (Swift)-Webservice umzusetzen. (Der zugegebenermaßen nicht viel in diesem Beispiel vollbringt, jedoch mit den Möglichkeiten des eingesetzten Swifton-Frameworks die Möglichkeiten schier unbegrenzt offen hält für anspruchsvolle Webseiten und Webanwendungen.)

Auch darf für die tatsächliche (Swift) Webservice-Anwendung eine Package.swift Metadatei nicht fehlen. Auch hier geben wir an, wie dieses Package zu heißen hat (DockerSwiftBackend), referenzieren jedoch auch zusätzlich auf die benötigten Bibliotheken, die wir zum Bauen/Kompilieren der Anwendung benötigen; darunter auch unser eingesetzte Shared-Code Git-Repository. (inkl. sematischer Versionierung der Dependency-Bibliotheken anhand von Git-Tags-Namen) Via „swift build“-Befehl lässt sich die Swift-(Web)-Anwendung auf der Kommandozeile bauen/kompilieren, wenn man sich auf dem Dateipfad der Package.swift Datei befindet; das bedeutet,  dass auch die ganzen Dependencies dabei aufgelöst werden (also der download/git-clone der referenzierten Package-Repositories angestoßen wird), diese gebaut werden und abschließend in einer „Executable-Binary“ zusammengelinkt werden. Das Resultat ist eine native Anwendung die mit dem „gewöhnlichen“ linux-bash-Ausführungsbefehl „./.build/debug/DockerSwiftBackend –bind 0.0.0.0:80“ gestartet wird (In unserem Beispiel soll unser Webservice auf dem (HTTP)-Netzwerk-Port 80 auf seine Requests horchen, ohne bind-Angabe wird der default-Port 8000 vom Curassow-Webserver automatisch gewählt).

Swift Client-Code:

Für eine exemplarische Client-Implementierung zu unserem Swift-Webservice haben wir es uns mit der komfortablen xCode7.3 IDE bequemer gemacht und diese mit einer der 4 Apple-Plattfomen (z.B. iOS) als kleines Client-UI-Frontend umgesetzt. Hierbei wird im Grunde, unter dem Einsatz der bereits bekannten beiden Modell-Klassen aus unserem Shared-Code Repo/Package/Modul, ein HTTP-Post Request (nach einer Nutzereingabe und Button-Bestätigung) an unseren Webservice abgeschickt, die Antwort ausgewertet und in einem Textfeld (UI) dargestellt.

Zu den im Client eingesetzten Typen/Funktionen gehören u.A. NSMutableURLRequest, NSURL, NSURLSession, NSData, NSURLResponse, NSHTTPURLResponse, dispatch_async(). Diese Typen sind eigentlich streng genommen Bestandteil von Apples ursprünglich stammenden Foundation-Framework und libdispatch-Bibliothek. Netterweise stellt Apple auch diese sehr nützlichen Funktionalitäten und APIs auch der Open-Source-Community in Form von den Swift Core Libraries bereit. Ab Herbst 2016 als Swift3.0-Release sogar mit erweitertem Funktions-Umfang.

Deployment und Hosting des (Swift)-Webservices

Um bei einer „Real-Life“-Lösung einen Webservice für Clients/Frontends im Internet anzubieten, gibt und gab es in der Vergangenheit, und zum Teil heutzutage evolutionär größtenteils abgelöst, die Möglichkeit, einen dedizierten Linux-Server (Hardware/Bare-Metal mit installierter Linux-Distribution als OS) hinzustellen und wie mit unserem Fall darauf die (Swift-)Webservice-Anwendung (samt dem installierten aktuellen offiziellen 2.2-Swift-Release) zu starten. Den Server kann man  im ‚haus-eigenen‘ Rechenzentrum/Serverraum (on-premise) betreiben oder bei einem der zahlreichen Hosting-Anbieter anmieten. Ganz klassisch muss man sich hier die Kosten/Nutzen/Wartungs Frage selbst beantworten, welchen Weg man gehen möchten für ein spezielles Vorhaben/Projekt.

Etwas eleganter, leichtgewichtiger, und zum Teil auch kostengünstiger was die Wartung und Inbetriebnahme angeht, hat sich der Einsatz  von sogenannten Virtuellen Maschinen etabliert (VM-Beispiele: VirtualBox, VMWare, VirtualPC). Hier besteht die Möglichkeit, auf einer (Server-)Hardware mehrere „virtuelle“ Maschinen mit eigenständigen Betriebssystemen auszuführen. Als (absurdes 😉 ) Beispiel: Auf einem Windows-Server-2016 Hardware-Rechner wird via VMWare (in dieser Rolle auch „Hypervisor“ genannt) eine Virtuelle Maschine mit einem installierten OSX und eine weitere Maschine mit Linux (Ubuntu) ausgeführt. Der Mehrwert für DevOps/Admins und die kostenbetrachtenden CTO ist hier bereits offensichtlich. Man muss nicht für jedes Vorhaben, für jedes benötigte Betriebssystem oder für jede Software-Lösung gleich wieder in Hardware investieren.

Der nächste Evolutionsschritt in der (verteilten) Software-Entwicklung und Bereitstellung (Deployment and Maintenance) geht in Richtung Container; die bekannteste Vertretung aus dieser Gattung nimmt Docker ein. Ein Container ist grob gesagt ein auf dem Linux-Kernel basierter „Sandboxing“-Ansatz, der es ermöglicht, Anwendungen -völlig abgeschottet von der eigentlichen Linux-Distributions-Umgebung- autark und unabhängig ‚laufen‘ zu lassen. Hierbei kann man einem Container, ähnlich wie bei einer virtuellen Maschine, entsprechende System-Ressourcen des „hostenden“ Betriebssystems bereitstellen (z.B. Arbeitsspeicher, persistierender Speicher/Storage, CPUs und Netzwerk-Ports). Ein Container ist wesentlich „leichtgewichtiger“ aufgebaut als eine VM, z.B. ist er innerhalb von wenigen Sekunden erstellt und ausgeführt, muss kein Betriebssystem installieren um ihn sinnvoll nutzen zu können (ein Linux-Subsystem/bash ist bereits gänzlich einsatzbereit) und verbraucht deutlich weniger System-Ressourcen als die großen Brüder der Virtuellen-Maschinen. Ein Faktor der zukunftsorientierte CTO hellhörig werden lassen sollte!

Die Eigenschaften und Vorteile für den Einsatz von (Docker)-Containern (gegenüber konventionellen Herangehensweisen) lesen sich wie die von Swift 😉

• leichtgewichtig
• skalierbar
• portabel
• reccourcenschonend
• kostenlos (keine Hypervisor-Kosten)
• ‚überall‘ verfügbar

Im Grunde ist der Einsatz von Docker sowohl eine Bereicherung für Entwickler als auch für Admins (Developer and DevOps): Entwickler können ihren für das jeweilige Projekt benötigten Software-Stack innerhalb eines Containers definieren (wie in unserem Webservice-Beispiel, Swift2.2-Release + die Webservice-Anwendung selbst, die darauf basiert) ihn lokal auf einer Entwicklungsmaschine/Workstation/Laptop ihrer Wahl umsetzen, verbessern, testen usw. und das fertige  Container-(Image) dann beispielsweise auf einem Staging oder gar gleich Produktiv-System ebenfalls als Container laufen lassen. Der sehr optimierte Workflow für diesen Software-Entwicklungsprozess ist das Hauptziel für den Einsatz der (Docker-) Container Technologie. Achja: für die Nutzung von Docker kann auch Windows oder ein Mac-OSX eingesetzt werden, obwohl diese über keinen benötigten Linux-Kernel verfügen, Docker stellt hierfür ihre Toolbox für die Linux-fernen Entwickler-Maschinen bereit. Damit kann sogar mit der Unterstützung einer UI-Maske das Management von Containern bewerkstelligt werden. (größtenteils ohne Konsole)

Wenn Microsoft seine Ankündigung gut macht, erhalten wir mit der Windows10Pro Aktualisierung im Sommer 2016 mit etwas Glück einen (Docker-)Container tauglichen Linux-Kernel als Ubuntu-Subsystem für Entwickler direkt in Windows integriert (Update: Leider scheint hier Microsoft nur ein halbgares Resultat abzuliefern).  Damit wäre der Einsatz der jetzigen „Toolbox“ bzw. deren weitere Vorhaben nicht mehr zwingend notwendig für den (Entwickler-)Einsatz von Containern unter Windows.

Google beispielsweise nutzt bereits mindestens eine Dekade lang die Container-Technologie auf deren Produkt-Serversystemen. Und auch beim überzeugten Container-Einsatz besteht die Möglichkeit die Hosting-Strategie, je nach Belangen, frei zu wählen. Ob in der hauseigenen Serverlandschaft mit der containerfreundlichen CoreOS Linux-Distribution (als zentrales „Orchestration“-Tool für das Management der Container sei fleet hier erwähnt bzw. auch diverse Alternativen die sich hervorragend für das Management/Monitoring von (Micro-)Services eignen; als Königstool zählt hier dcos), oder sogar auf dem privaten oder in der Firma genutztem NAS-System, oder ganz klassisch bei einem Webdienstleister gehostet (hier sei der Made/Host-in-Germany Newcomer Sloppy erwähnt ).

Das Thema „Container in der Cloud“ hat mittlerweile einen so hohen Stellenwert bekommen, das bereits ein Akronym (um nicht zu sagen das nächste buzzword am Horizont) dafür gefunden wurde: CaaS (Containers-as-a-Service). Der weltgrößte Server-Hosting Anbieter Heroku bietet ebenso Container-Unterstützung an wie die folgenden Cloud-Dienst Global-Player:

• Google
• Amazon
• Microsoft (Ja, richtig gelesen! Selbst in Redmond setzt man seit geraumer Zeit auf ein große Linux-Infrastruktur; weil das eigene Betriebssystem nicht Container-tauglich ist)

Für die Umsetzung unserer exemplarisch gezeigten Swift Webservice-Anwendung haben wir uns auch an einem der mittlerweile zahlreich verfügbaren öffentlichen (Container-)Images bedient. Als eine zu erwähnende  zentrale Anlaufstelle bietet der Dienst Docker-Hub viele direkt als Container ausführbare Images in dessen Repositories an. Dieser Registry/Repositories-Dienst für Container-Images ist vergleichbar mit Git-Hub für SourceCode Hosting-Belange.

Folgende Docker-(Container)-Image Repositories bieten sich optimal dafür an mit einem bereits fertig eingerichteten Swift-Software Stack eigene (Web-)Anwendungen umzusetzen:

• Ein Docker-Image mit dem bereits vorinstallierten Swift2.2. Release vom März-2016: https://hub.docker.com/r/swiftdocker/swift/ (in unserem Fall eingesetzt)
• Ein Docker-Image mit Swift2.2 + dem Webservices-Framework Swifton: https://hub.docker.com/r/atsnngs/docker-swifton-example/
• Ein Docker-Image für einen My-SQL Datenbank-Service, als ideale persistierende Ergänzung für unseren bisher rudimentäre Swift-Webservice-Anwendung: https://hub.docker.com/_/mysql/

Fazit

Swift, die Programmiersprache für „alles“, und Docker-Container ergänzen sich optimal in dem Arbeits-Workflow von Software-Entwicklungen von „komplexen“ verteilten Systemen. Mit diesem Traum-Duo konnte recht leichtgewichtig und einfach eine Swift-basierte Serveranwendung umgesetzt werden, die mit Clients kommuniziert. Das Versprechen der großen Skalierbarkeit dieser Sprache konnte mit einem Praxisbeispiel angedeutet und zum Teil bestätigt werden. Mit Swift ist es bereits heute möglich produktive verteilte Software auf jeglichen Plattformen umzusetzen und sogar Code wiederzuverwenden. (mit allen erwähnten Vorteilen die diese Sprache zu bieten hat, und zukünftig ab Herbst mit Swift 3.0 zusätzlich bieten wird). Unternehmen und deren IT-strategischen Entscheider, insbesondere die CIOs und CTOs sind heute eher denn je gefragt sich für die zukünftigen Herausforderungen und Kundenerwartungen and Lösungen zu wappnen und auf die zukunftsicherste, flexibelste, effizienteste und kostengünstigste Technologie zu setzen, bzw. die Entscheidung zu treffen die Entwicklungsabteilungen darauf gezielt vorzubereiten und externe Dienstleister aufgrund dieser unternehmenskritischen Perspektive sorgsam auszuwählen. Nur so kann in einer modernen vernetzten Zukunft Aussfallsicherheit (High-Availability mit Fail-Over), Reaktionszeit (Response-time), Umsetzungsgeschwindigkeit (time-to-market) und Flexibilität (z.B. durch Container-Microservices) die Kunden und Stakeholder weiterhin zufrieden stellen. Der kostenorientierte Entscheider, sei es bezüglich Human-Ressources (Know-How, Developement, Architecture, Maintenance, Administration ) oder Hardware-Ressources (Bare Metal)  und Hosting (Miet-Kosten) seien hierbei ebenso angesprochen wie auch die Entwickler selbst.

Für Fragen, Anregungen, Austausch, kann gerne Kontakt mit mir aufgenommen werden bzw. auch die untere Kommentar-Funktion verwendet werden. Wir unterstützen Sie gerne bei Ihrem IT-strategischen Vorhaben oder ihrer individuellen Lösungs-Vision. 🙂

Update: Augfrund von mehreren Anfragen hier noch einige weiterführende links und frameworks/libraries für den produktiven Swift-Einsatz:

IBM swift package-catalog: Eine handerlesene libraries-Übersicht von IBM für den produktiven Web-Service Einsatz

Swift-Toolbox: eine weitere library-Übersicht für den Einsatz für eigene Swift-Projekte (hauptsächlich apple-native UI-Kompotenten)

SwiftWatch: Die neuesten Errungenschaften zum Thema Swift

RxSwift: reactive Programming with Swift. (library)

Commander: Comand-Line-Interface-Tools (CLI) mit Swift umsetzen (library)

Swift and (lowlevel) C: Everything you need to know

 Teil2