Top 5 Developer – Trends für 2017

Polyglotte Systeme

Vor gar nicht allzu langer Zeit waren viele Entwickler noch PHP-Programmierer oder Java-Programmierer - heutzutage sind viele Full-Stack-Developer oder DevOps-Engineers. In den derzeit populären Job-Titeln, spiegelt sich wider, dass sich der Alltag eines modernen Entwicklers nicht so einfach mit der Expertise in einer Programmiersprache gleichsetzen lässt. Selbst bei einfachen Web-Applikationen kommen heutzutage häufig mehrere Markup-, Script- und/oder Programmiersprachen zum Einsatz. Immer mehr Entwickler schreiben regelmäßig Code in mehreren Sprachen. Durch den vermehrten Einsatz von Microservices wird die IT heterogener. Kleine autonome Services laden dazu ein pragmatische Lösungen zu finden und neue Wege zu gehen. Tools und Programmiersprachen können so abhängig vom konkreten Anwendungsfall gewählt werden und bieten Raum für Experimente. Diese Experimente mit neuen Technologien sind verhältnismäßig günstig, da ein kleiner Service schnell ersetzt werden kann - der Lerneffekt ist allerdings umso höher, denn im Produktiv-Einsatz lernt man am meisten. Infrastructure-as-Code und die Automatisierung von Prozessen wie z.B. Deployment und Testing tun ihr Übriges, die Vielfalt an Sprachen, die im Einsatz sind, zu erhöhen. Umso wichtiger ist es, für eine Atmosphäre des Voneinander-Lernens und Austauschs zu sorgen und sich mit Konzepten wie dem Just-In-Time-Learning auseinanderzusetzen.

Plattform-Gnostik

Viele Machine Learning-Algorithmen und Verfahren der künstlichen Intelligenz lassen sich durch den Einsatz von spezialisierter Hardware effizienter ausführen. Während GPUs aufgrund Ihrer Effizienz bei parallelisierbaren Aufgaben bereits seit Jahren im Einsatz sind und Public Cloud-Anbieter entsprechend bestückte Instanzen anbieten bzw. anbieten werden, geht der Trend nun bei den großen Technologiekonzernen hin zu spezieller Hardware für einzelne Use Cases. Microsoft setzt auf FPGA-Technologie (Field Programmable Array) und hat Rechenzentren weltweit damit ausgerüstet. Google geht einen anderen Weg und hat mit der TPU (Tensor Processing Unit) einen speziellen Chip für künstliche Intelligenz entwickelt. Google’s Ansatz bietet mehr Performance pro Watt für die passenden Workloads, während Microsoft sich einen gewissen Grad an Flexibilität erhält, da die FPGAs rekonfiguriert werden können und so eine Reaktion auf geänderte Gegebenheiten ermöglicht. Die Tatsache, dass die großen IT-Konzerne Vorreiter sind bei dieser Entwicklung, liegt daran, dass diese viele Machine Learning Workloads fahren und diese effizienter abwickeln wollen. Es ist davon auszugehen, dass die speziellen Chips weiter in die Public Cloud Angebote integriert werden. Inwieweit externe Entwickler mit der spezialisierten Hardware arbeiten können (low-level / APIs / mittelbar via Services) ist nicht ganz klar. Anzunehmen ist: Workloads die jetzt nicht kosteneffizient sind, werden es in absehbarer Zeit sein und dabei rücken die beiden Welten Hardware und Software nah zusammen.

Das Internet-of-Things hat wiederum seine eigenen technischen Rahmenbedingungen. Durch Anforderungen, wie niedrige Produktionskosten, Energieeffizienz und kleine Bauform, sind die Möglichkeiten limitiert. Netzwerk ist möglicherweise nicht immer stabil verfügbar und möglicherweise nur mit niedriger Bandbreite. Auch hier müssen Entwickler stärker auf die Hardware Rücksicht nehmen.

Interessanterweise gibt es zum dem Trend hin zu starker Berücksichtigung der Hardware aber auch einen Gegentrend: weiter weg von der Hardware, hin zu Containern oder sogar soweit, dass man von Serverless spricht. Hierbei wird Software entwickelt und in den Produktiveinsatz geschickt ohne, dass es das Konzept eines Servers überhaupt noch gibt. Dennoch dürfen die spezifischen Gegebenheiten wie die zur Verfügung stehenden Compute-Ressourcen und die damit verbundenen Kosten nicht vernachlässigt werden. Ein Verständnis der Plattform und des Kontextes in dem die Software am Ende läuft, ist ein wichtiger Erfolgsfaktor. Denn dieses bildet die Grundlage für Lösungen, die effizient und stabil laufen.

Open Source / Tech Communities

Open Source erlebt derzeit eine neue Blütezeit. Es gibt Millionen von öffentlichen Code-Repositories allein auf GitHub und es werden täglich mehr. Neben einer Vielzahl an kleinen Projekten einzelner Entwickler oder kleiner Gruppen haben viele Unternehmen in den letzten Jahren Technologien als Open Source verfügbar gemacht oder Open Source Projekte unterstützt. Im Deep Learning-Bereich scheint sich dieser Trend noch zu verstärken. Egal ob Amazon, Baidu, Google, Facebook oder Microsoft - alle haben Machine Learning Technologie als Open Source veröffentlicht. Es mag im ersten Moment widersinnig erscheinen, Kerntechnologien in zukunftsträchtigen Bereichen öffentlich zur Verfügung zu stellen, doch diese Technologiekonzerne haben unlängst verstanden, dass Open Source Software verschiedene Vorteile bringt. So erhält man wertvolles Feedback aus der Community. Open Source Projekte machen aber auch auf das eigene Unternehmen aufmerksam und können so den Recruiting Prozess unterstützen bzw. eigene Angebote wie Services oder die eigene Public Cloud bewerben. Auf der anderen Seite kann so aber auch der Entwicklung in diesen strategisch wichtigen Gebieten sein Stempel aufgedrückt werden und die Entwicklung beschleunigt sowie ein Stück weit gelenkt werden. So können eigene Service Angebote und Plattformen von den Open Source Aktivitäten profitieren. Open Source ist ein wichtiger Innovationstreiber und macht einen Großteil der Technologien die heute im Einsatz sind aus. Es ist daher wichtig sich mit Open Source auseinanderzusetzen und auszutauschen. In Großstädten gibt es nahezu täglich Veranstaltungen zu Technologie-Themen, wie zum Beispiel User Groups. Aber auch abseits von Open Source entstehen Communities um Technologien, Plattformen und Organisationsmethoden. Es scheint als öffne sich die IT nach außen und tausche sich vermehrt aus. Begünstigt wird die Entwicklung von Meetup.com, einer zentralen Online-Plattform zum Organisieren und Entdecken von Communities. Unternehmen und ihre CIOs tun gut daran, sich in den Communities zu engagieren und Präsenz zu zeigen.

(Near)-Realtime

In einer Welt, in der es selbstverständlich ist Zugriff auf Informationen jederzeit und von überall zu bekommen sowie über das Internet mit anderen zu kommunizieren und zu kollaborieren, wächst das Bedürfnis nach Echtzeit bzw. nahezu Echtzeit Funktionalitäten. Realtime Lösungen sind ein wichtiger Teil der Customer Experience. Mittlerweile sind Nutzer daran gewöhnt aktuelle Informationen und Empfehlungen zu bekommen oder direkt mit einem Ansprechpartner aus dem Browser heraus chatten zu können. Nahezu alle populären Apps und Services des täglichen Gebrauchs setzen irgendwo Echtzeit-Funktionalität ein. Im Bereich der Collaboration hat Realtime einen festen Platz im Alltag vieler gefunden. Paralleles Editieren von Dokumenten und Echtzeitkommunikation sind nicht mehr wegzudenken.

Während Datenberge wachsen, wächst auch das Bedürfnis nach Realtime-Insights. Im Bereich IT-Operations sind Realtime-Dashboards lange schon zum Standard geworden, jedoch nach wie vor nicht in allen Unternehmensbereichen angekommen. Klassische Business Intelligence reicht aber häufig nicht mehr aus. Die neuen Anwendungen in Industrie 4.0 und Internet-of-Things sind ohne (Near)-Realtime gar nicht zu denken. Damit Echtzeit-Anwendungen gelingen, muss die richtige Technologie dafür zum Einsatz kommen. Clients, Backend-Systeme und die Kommunikation zwischen den Systemen müssen den Anforderungen, wie zum Beispiel schneller Verarbeitungsgeschwindigkeit und niedriger Latenz gerecht werden, um ein optimales Ergebnis zu erzielen. Je nach Anwendungsfall bedarf es zudem einer elastischen Infrastruktur die flexibel skaliert. Die Wahl der richtige Datenarchitektur muss zudem wohl überlegt sein. Das gute alte Batch-Processing steht auf dem Prüfstand während Stream-Processing oder Lambda-Architekturen weiter Verbreitung finden.

APIs

In Zeiten von Microservice Architekturen, Plattformen und “As-a-Service”-Angeboten kommunizieren moderne IT Systeme über APIs mit einer Vielzahl von Systemen. Dies sind sowohl Systeme des gleichen Unternehmens aber auch von Drittunternehmen wie Partnern,  Kunden und speziellen Service-Anbietern.

Die Anzahl privater APIs nimmt durch die Verbreitung von Microservice-Architekturen naturgemäß weiter zu. Zudem gibt es auch immer mehr öffentliche APIs, allein das Verzeichnis von ProgrammableWeb listet mehr als 16.000. Es gibt eine stetig wachsenden Anzahl von Public Cloud-Angeboten (Machine Learning-as-a-Service, Database-as-a-Service), die per API in eigene Systeme integriert werden können. In einer Microservice-Welt, können auch Services anderer Unternehmen genutzt werden. Spezialisierte Angebote von Unternehmen, die genau einen Service anbieten (z.B. Headless CMS), sind auf dem Vormarsch. Hier kann sich ein Unternehmen auf die Lösung eines Problems konzentrieren. Sind die Anwendungsfälle datengetrieben, gibt es den Vorteil durch das Sammeln und konsolidieren großer Datenmengen unterschiedlicher Quellen eine solide Basis für Machine Learning & AI Algorithmen zu bekommen. Beispielsweise gibt es Services zur Fraud-Detection, wo größere Datenmengen naturgemäß bessere Ergebnisse liefern. Das einzelne Unternehmen hat vielleicht einfach nicht genügend relevante Daten, um das Problem zuverlässig zu lösen. Abhilfe schafft hier die Auslagerung an einen Spezialisten der per API angebunden wird und die Daten verschiedener Unternehmen vorliegen hat. Außerdem sind Weiterentwicklung und Betrieb von diesen Services ausgelagert. Dies erlaubt ein Fokussieren auf Mehrwert, anstatt das Rad mit weniger Ressourcen und weniger Expertise neu zu erfinden. Auf der anderen Seite stellt dies Unternehmen auch vor Herausforderungen. Ein solides API-Management für interne und externe APIs sowie entsprechende Guidelines, wie mit externen APIs umzugehen ist, gehören zu den Grundvoraussetzungen, die es zu erfüllen gilt. Dies gilt auch für all diejenigen Unternehmen, die gerade die Transformation vom Industrie- zum Software-Unternehmen durchlaufen. Im IoT-Zeitalter schreiben und verwalten immer mehr Produkt- und Industriefirmen ihre eigenen Software-Plattformen, die zum Aufbau eines “Ökosystems” extern via API geöffnet werden sollen. Hier ist viel Expertise und Erfahrung nötig, um die API-Strategie richtig aufzusetzen und zu implementieren.

Mehr zu den Themen AI API DevOps-Engineers Field Programmable Array Full-Stack-Developer IaaS IoT Java KI Machine Learning PHP Plattform-Gnostik Polyglotte Systeme Tensor Processing Unit

Share on:


Über den Autor:

VP System Design & Site Reliability Engineering

Daniel KlemmDaniel Klemm ist VP System Design & Site Reliability Engineering bei Crisp Research. Als erfahrener Cloud- und Plattform-Architekt berät er Kunden bei Planung, Design und Betrieb von geschäftskritischen Plattformen und digitalen Lösungen. Seine Schwerpunktthemen sind Platform & Microservices Architecture, Cloud Native Application Design, API Management, Multi Cloud Operations, Infrastructure-as-Code und Site Reliability Engineering. Daniel Klemm verfügt über mehr als 15 Jahre Berufserfahrung im Technologie- und Startup-Bereich. So sammelte er operative Erfahrung als CTO eines Internet-Startups im Media- und eCommerce-Umfeld, im Scientific Computing bei der Modellierung von Decision Support Systems sowie zuletzt als Senior Analyst bei Crisp Research in der Beratung von CIOs und IT-Entscheidern im Kontext der Cloud-Transformation. Daniel Klemm ist aktives Mitglied der Cloud Native Computing Community und einer der Initiatoren der Amazon Web Services User Group in München sowie der Cloud Native User Group Kassel.