Apps & Big Data

Software-Entwickler sehen sich heute zwei grossen Herausforderungen gegenüber: Die Analyse riesiger, unstrukturierter Datenbestände (Big Data) in verteilten Rechner-Clustern ist die eine, mobile Apps für Smartphones und Tablets die andere. 2011 gingen in der Schweiz 3,7 Millionen App-fähige Smartphones über die Ladentische. Weltweit laden Kunden pro Monat jeweils eine Milliarde Apps aus Android-Marktplätzen und Apples App Store auf ihre mobilen Devices.

Für Software-Entwickler liegt dort das ganz gros­se Geld vergraben. «Es gibt zu wenig iPhone-Entwickler und die Nachfrage nach ihren Diensten ist ungeheuer hoch», sagt Uwe Post, Chefentwickler der Software-Schmiede Ludetis, die sich auf die Programmierung mobiler Spiele spezialisiert hat. Dementsprechend sehen die Stundensätze aus, sie schlagen andere Software-Entwicklungsbereiche zurzeit um Längen. Je nach mobilem Betriebssystem – Apple, Android oder Windows Phone 7 – bekommen es die Entwickler mit ganz unterschiedlichen Herausforderungen zu tun. Java-Vorkenntnisse vorausgesetzt, falle der Einstieg in Android-Devices, die in Java programmiert werden, sehr leicht. Die technischen Hürden seien niedrig, sagt Post. Das neue Samsung Galaxy S3 mit seinem extra­grossen Display oder das Acer Iconia Tablet mit nVidia-3D-Chip eignen sich bestens auch für anspruchsvolle Applikationen.

Beim iPhone und iPad dagegen sieht es anders aus. Objective-C, die Programmiersprache für Apples iDevices, sei schon eine Sache für sich, die Syntax ungewohnt – selbst für jemanden, der in den Profisprachen C oder C++ Erfahrung habe. Mit Apples Entwicklungsumgebung müsse man sich sehr intensiv auseinandersetzen, betont Post. Eben deshalb, so darf man ergänzen, sind iPhone-Entwickler so gefragte Leute. Auf der nächsten Seite: Kampf um die Köpfe

App-Programmierer kämpfen, im Gegensatz zu Entwicklern von Desktop-Applikationen, mit zwei prinzipiellen Flaschenhälsen: kleine Displays und schwache Akkus. Geschäftsprozesse seien in der Regel zu komplex und müssten vereinfacht, also auf das kleinere Display heruntergebrochen werden, betont Mischa Demarmels, Experte für mobile App-Entwicklung bei Zühlke Engineering. Weniger ist mehr, heisst dabei die Devise. Der zweite Unterschied: Smartphone-Nutzer sind ungeduldiger und akzeptieren keine langen Wartezeiten (Latenzen). Die Nutzungsprofile von Desktops und Smartphones unterscheiden sich. Ausserdem gibt es auf dem Smartphone Unterbrüche, etwa durch eingehende Anrufe oder fehlende Netzabdeckung. Eine Offline-Strategie für die spätere Synchronisation der Daten sei daher unbedingt erforderlich, empfiehlt Demarmels. Schliesslich sollten sich App-Entwickler generell dem Diktat der Energie-Effizienz beugen und Strom sparend programmieren, damit die App nicht ruck, zuck den Akku leersaugt. Desktop-Programmierer sind dagegen gewöhnt, aus dem Vollen zu schöpfen, sie müssen umdenken und ihren Programmierstil ändern. Zurzeit kämpfen drei mobile Betriebssysteme um die Köpfe der begehrten Experten und die Portemonnaies der Kunden: Apple mit der Entwicklersprache Objective-C, Android mit Java und Microsoft Windows Phone mit den .NET-Sprachen C-Sharp (C#) und Visual Basic. Softwerkern, die mit ihrer Arbeit Geld verdienen wollen, stellt sich zunächst die Gretchenfrage: Welche Plattform/Sprache soll ich wählen? Zwar sind alle vier Entwickler-Idiome in der Theorie sogenannte höhere, also hardwareferne, Programmiersprachen. Theoretisch sollte es daher möglich sein, mit C-Sharp auch An­droid oder mit Java auch iPads zu programmieren. In der Praxis aber unterliegen Software-Entwickler, analog zum sogenannten «Vendor lock-in», dem «Developer lock-in»: Sie legen sich mit ihrer Wahl auf eine bestimmte Plattform fest.

Es fehle von offizieller Seite an Dokumentationen für solche exotischen Vorhaben und gerade für Anfänger dürfte das tödlich sein, sagt Post. Der Chefentwickler erzählt von einem Kollegen, der versucht hat, eine Android-App (Nativ Java) in der modernen Sprache Scala zu entwickeln. Ein eher unkompliziertes Szenario, denn Scala erzeugt Java-Bytecode, den Android schluckt. Trotzdem habe der Kollege Monate gebraucht, um eine kleine App auf die Reihe zu kriegen. Apple setzt, um auf Nummer sicher zu gehen, sogar noch eins drauf und verbietet in seinen AGBs explizit den Einsatz fremder Programmierwerkzeuge. Auf der nächsten Seite: Vorsicht: Developer Lock-in.

Der Kampf um Sprachen, Betriebssysteme und Plattformen ist nichts anderes als beinhartes Geschachere um zukünftige Marktanteile – und die Waffe heisst Developer Lock-in. Ein App-Entwickler, der sich erst einmal mit einer Plattform angefreundet hat, wird so schnell nicht mehr zur Konkurrenz wechseln. Über den Markt­erfolg von iDevices, Android und Windows Phone entscheidet zu wesentlichen Teilen aber die Grösse des Ökosystems, also die kreativen Köpfe der Entwicklergemeinde, die für die Plattform programmieren. So einfach ist das: Wer heute die Herzen der Softwerker erobert, sichert sich dadurch morgen Consumer-Marktanteile. Zwar gibt es sogenannte «Cross compile Frameworks», die Source Code automatisch auf fremde Betriebssysteme portieren. Das Problem liege aber gar nicht in der Technik, sondern in den unterschiedlichen Navigationskonzepten, unterstreicht Mischa Demarmels. Apples iOS etwa benutzt Listen, Windows 8 Metro-Style-Kacheln. Eine hundertprozentige Portierung ist unter diesen Voraussetzungen gar nicht möglich. Zühlkes App-Spezialist nennt als Lösung des Problems partielle «Cross platform development frameworks» wie MonoTouch von Xamarin. Das Konzept dahinter: Mit MonoTouch entwickeln Programmierer die Benutzerschnittstelle, das Graphical User Interface (GUI), zwar nativ, also für jedes Betriebssystem individuell. Business-Logik plus Source Code werden aber automatisch portiert – eine enorme Arbeitsersparnis für Multi-Plattform-Entwickler, denn die kodierte Business-Logik der Apps macht den Löwenanteil aus. «Allerdings können bei sehr komplexen Features plattformspezifische Eigenheiten dennoch zu Abstrichen in der User Experience führen», so Demarmels. «Gutes Know-how ist hier immer noch das A und O.» Auf der nächsten Seite: Hoffnungsträger Big Data.

Von ganz klein zu ganz gross, von mobilen Apps zu Big Data Analytics, der zweiten Herausforderung für Software-Entwickler. 2015 beginnt für die IT-Welt das sogenannte Zettabyte-Zeitalter, schätzt der Netzwerkspezialist Cisco in seinem aktuellen Visual Networking Index. Das heisst, dass der weitweite IP-Datenverkehr ein Zettabyte erreicht, das sind 1'000'000 Petabyte oder 1'000'000'000 Terabyte grösstenteils unstruk­turierter Daten. «In Big Data Analytics liegen immense Möglichkeiten, die heute erst sehr unzureichend ausgeschöpft werden», urteilt Stephen Brobst, CTO des Analytics-Spezialisten Teradata, etwa im Gesundheitswesen, der Verkehrsplanung oder der sogenannten Consumer Intelligence.

Schweizer Banken wie die Credit Suisse setzen auf Big Data Analytics grosse Hoffnungen. Und wer Big-Data-Analytics-Strategien entwirft, landet unvermeidlich bei Hadoop/Map­Reduce, einem in Java programmierten Open-Source-Framework. Hadoop teilt die riesigen Datenberge in kleinere Pakete auf und analysiert sie auf Hunderten, oft Tausenden Rechnerknoten parallel, das heisst sehr schnell (Computerworld berichtete). Konzerne wie Amazon, Yahoo und eBay setzen bereits seit Jahren grosse Hadoop-Cluster ein, die Credit Suisse analysiert damit (im Testbetrieb) ihre Logfiles. Für die meisten Firmen aber ist Hadoop/MapReduce noch ziemlich neu. Welche Anforderungen stellt der Hadoop-Ansatz der verteilten, parallelen Analyse riesiger Datenvolumen an den Entwickler? «An der Architektur ändert sich nicht viel», sagt Kai Schwidder, Business-Unit-Leiter IT-Architektur bei Zühlke, «allerdings werden Objektmodelle in Zukunft sehr wichtig.» Für den Entwickler heisst das: Nicht mehr die traditionelle Datenbank-Instanz, sondern Objektidentitäten stehen im Fokus. Hadoop sei gar nicht so kompliziert, aber arbeitsaufwendig, meint Christian Gögi, Mit­begründer und Organisator der ersten «Swiss Hadoop User Group». Zu den Initiatoren gehören das ETH-Spin-off Teralytics und der Social-Media-Monitoring-Experte MeMo News. Wenn man ein lauffähiges Hadoop-Cluster habe, könne man relativ schnell MapReduce-Jobs bauen, welche die verteilten Datenpakete analysieren und wieder zusammenführen, meint Gögi. Denn das Hadoop-Framework nehme dem Software-Entwickler bereits viel Arbeit ab.