Eine kurze Einführung in das Paradigma der Serverless-Architekturen – am Beispiel der AWS Cloud


Da das Schlagwort „serverlose Technologien“ im Kontext der Cloud Nutzung immer wieder genannt wird, fragen Sie sich möglicherweise, was den „serverlos“ in der Praxis genau bedeutet.

Es ist allgemein bekannt, dass man keine Rechenleistung (Compute-Workload) ohne einen physisch vorhandenen Computer bzw. Server erbringen kann. Das führt zu der Frage, wie spiegelt sich dies in den verschiedenen Serverless-Technologien wie Docker, Kubernetes und Function-as-a-Service (FaaS) wider?

Beginnen wir damit warum man diese Technologien überhaupt als „serverless“ bezeichnet, wenn doch immer noch ein Server zur eigentlichen Ausführung benötigt wird?

Ohne Software geht es nicht

Im Grunde genommen ist es aber ganz einfach: Es kommt auf den Betrachtungswinkel an.

In einer klassischen IT-Umgebung würde man einen Server bereitstellen, seine Anwendung dort installieren und diese dann dort ausführen lassen. Dabei muss man natürlich dafür sorgen, dass alle technischen Abhängigkeiten der betreffenden Anwendung (wie z.B. Sprachbibliotheken, Datenbanken, Visualisierungstools, usw.) auf dem betreffenden Server installiert sind.

Wenn ein neues Release der Anwendung verfügbar ist oder man weitere Ressourcen benötigt, weil das System zum Beispiel mehr Rechenleistung erbringen soll, muss ein Entwickler oder Administrator auf den Server zugreifen und dort die betreffende Software installieren. Das kann zwar mit Tools wie Configuration-Management, Continous-Delivery-Pipelines, zentralisiertem Logging, usw. vereinfacht werden, aber am Ende des Tages muss immer eine Person, also ein Entwickler oder Administrator, zumindest etwas Kenntnis über den betreffenden Server und seine darauf installierten Anwendungen haben. Nur dann ist sie in der Lage, im Falle, dass es technische Probleme gibt, nach einer Lösung zu suchen und diese zu beheben.

Container

An diesem Punkt müssen wir einen kleinen Abstecher in das grundlegende Konzept von Serverless machen – den sogenannten „Container“.

Ein „Container“ ermöglicht es eine Anwendung inklusive der benötigten Systemumgebung auszuliefern. Dies macht es überflüssig, anwendungsspezifische Abhängigkeiten separat zu installieren, da sie bereits zusammen mit der Anwendung als Image ausgeliefert werden.
Und daraus resultiert auch der große Vorteil von Containern: Sie laufen praktisch überall.

Mit dem Begriff „Container“ ist übrigens nicht unbedingt nur ein „Docker Container“ gemeint, sondern auch der gute alte LXC Container (worauf Docker basiert) oder jede andere Container-Technologie.

Die Nutzung von Containern verschiebt die Verwaltung der Abhängigkeiten und die Bereitstellung der für die Ausführung der Anwendung erforderliche Umgebung vom Administrator des Servers hin zu den Entwicklern der Anwendung.

Ich bin mir sicher, dass auch Ihr Betriebsteam ein Mitspracherecht haben will und sollte. Im Wesentlichen ist dies der Punkt, an dem Sie eine DevOps-Kultur oder noch besser eine DevSecOps-Kultur benötigen.

Container können verwendet werden, ohne große Änderungen in der klassischen Umgebung umzusetzen. Es ändern sich lediglich ein paar Zuständigkeiten.

Geht man einen Schritt weiter bei der Verwendung von Serverless-Technologien, verschiebt sich die Interaktion zwischen Entwickler und Anwendung vom Server zu dem gewählten Orchestration-Tool (ich verwende für den Rest des Artikels Kubernetes als Beispiel, aber dasselbe gilt auch für andere Tools). Es gibt kein direktes Deployen von Anwendungen auf dem Server oder manuelle Konfiguration von Netzwerk-Komponenten, z.B. ein Load-Balancer. Man übergibt Kubernetes einfach eine neue Konfiguration und die neuste Version der Anwendung wird auf dem verfügbaren Server (Node) oder auf mehreren Servern (Nodes) ausgeliefert.

Doch hier sind sie ja schon wieder, diese verflixten Server!?!

Ohne Server geht es nicht

Die Verwaltung dieser Server häng davon ab ob man sein Kubernetes-Cluster On-Premise oder in der Cloud als Managed-Service betreibt. Das macht einen großen Unterschied, wenn es darum geht, sein Cluster zu verwalten.

Läuft es On-Premise, so muss man das Kubernetes-Cluster selbst verwalten und pflegen. Die Systemadministratoren müssen sich nicht länger mit dem Verwalten einzelner Anwendungen beschäftigen, sondern nur um das Cluster (oder mehrere Cluster) und alle dazugehörigen Server kümmern.

Wenn Kubernetes als Managed-Service in einer Cloud wie Amazon (AWS) Elastic Kubernetes Service (EKS), Google (GCP) Google Kubernetes Engine (GKE) oder Azure Kubernetes Service (AKS) läuft, reduziert sich der Verwaltungsaufwand aufgrund der automatischen Updates und des Betriebs der Master-Nodes durch den Provider drastisch. Das einzige, was von dem Prozess übrig bleibt, ist die Sicherheitskonfiguration der Umgebung.

In beiden Fällen hat man immer noch Zugriff auf die Server VM-Instanzen, auch wenn man einen Cloud-Service verwendet, da die Server als ganz normale virtuelle Maschinen bereitgestellt werden. Aber nachdem das Cluster eingerichtet ist, kann man nach Belieben Server zum Cluster hinzufügen und das Bereitstellen geschieht automatisch. In der On-Premise Variante kommt man um den normalen Verwaltungsprozess nicht herum.

Also hat man bei einem verwalteten Kubernetes-Service zwar immer noch Server aus denen der Cluster besteht und man verwaltet lediglich, wie stark automatisiert es skaliert, aber die Server muss man nicht direkt verwalten.

Somit sind wir schon ein wenig weiter mit unserer Erwartung an eine Serverless-Infrastruktur: Der Entwickler sieht den Server nicht mehr und man muss ihn auch nicht mehr verwalten.

Weg mit der Zuständigkeit

Aber können wir noch ein Stück weiter gehen und Server komplett aus unserer Zuständigkeit entfernen?

Ja, das können wir! Da jedoch das Rechnen ohne Computer / Server nicht möglich ist, ist dies nur durch Dienste möglich, bei denen die untergeordneten Rechenressourcen von jemand anderem verwaltet werden und entsprechend abstrahiert sind.

AWS bietet derzeit den Fargate-Service an, mit dem Sie Docker-Container ausführen können, ohne Compute-Instances (EC2) bereitzustellen, auf denen die Container ausgeführt werden. Dies bedeutet, dass Sie Ihre Docker-Container ausführen können, ohne jemals einen Server zu sehen oder zu verwalten. Es besteht auch die Möglichkeit, dass AWS in Kürze eine Option anbietet, dass EKS-Cluster von Fargate unterstützt werden (https://github.com/aws/containers-roadmap/issues/32). Dies würde bedeuten, dass auch Server (EC2-Instanzen) aus Ihrem EKS-Cluster wegfallen.

Eine andere Möglichkeit, die Server, die Sie mit Rechenleistung versorgen, vollständig loszuwerden, ist FaaS. AWS bietet den Dienst AWS Lambda an, in dem die Anwendung nur dann ausgeführt wird, wenn sie tatsächlich gebraucht wird. Der Service wird ausgeführt, wenn er ausgelöst wird. Wie eine Funktion ausgelöst werden kann, hängt von dem von Ihnen ausgewählten Cloud-Anbieter ab, da diese alle unterschiedliche Funktionsumfänge in diesem Bereich haben. Die Verwendung des systemeigenen Dienstes der Plattform für Nachrichtenwarteschlangen und HTTPs funktioniert mit allen Anbietern. FaaS führt Ihre Anwendung auch in einem Container aus – dies ist möglicherweise nicht direkt ersichtlich, wenn Sie die Dienste verwenden, da Sie kein Container-Image bereitstellen. Ihre Anwendung wird jedoch in einem Container ausgeführt, um sie zu isolieren. GCP bietet außerdem auch einen Dienst „Cloud Run“ an, welcher zwar Docker Container unterstützt aber aktuell nur über einen HTTPS Aufruf getriggert werden kann.

 

Fazit

Sie können nur dann wirklich „serverlos“ werden, wenn Sie Managed-Services von Cloud-Providern wie z.B. AWS verwenden, welche die Interaktion mit den Servern so weit abstrahieren, dass Sie diese nicht mehr direkt verwalten müssen.

Das bedeutet in der Regel, dass die Architektur einer Anwendung entsprechend ausgelegt werden muss. Ja, das macht zunächst ein wenig Arbeit, aber die gesparten Kosten sowohl bei der Administration der Anwendung als auch beim Betrieb in der Cloud machen sich erfahrungsgemäß recht schnell bezahlt.


Gerne beraten Sie unsere Spezialisten zum Thema Serverless mit AWS und unterstützen Sie bei Ihren IoT-Projekten.

Nehmen Sie Kontakt mit uns auf:

zum Kontaktformular


 

Modbus über MQTT – wie geht das?

Im Zeitalter der Digitalisierung und im Rahmen von Industrie 4.0 Anwendungen kommt zwangsläufig die Frage auf, wie bestehende Anlagen zukunftsfähig gemacht werden können. Die Grundlage hierfür sind die am Markt gängigen Systeme für die Vernetzung und den Informationsaustausch von Industrie-Steuerungen und angeschlossenen Sensoren und Aktoren.

Dieser Artikel beschäftigt sich mit der Möglichkeit, vorhandene Systeme zu vernetzen, um Industrie 4.0 Anwendungen überhaupt erst zu ermöglichen. Ganz konkret soll es in diesem Artikel um das Thema „Modbus“ und dessen Vernetzung gehen.

Modbus ist eines von mehreren gängigen Kommunikationsprotokollen für industrielle Anlagen und in der Automationstechnik. Modbus hält zusammen mit der TCP Variante immerhin einen Anteil von 11% am Gesamtmarkt der industriellen Netzwerke.

Quelle: http://www.elektroniknet.de/markt-technik/automation/feldbusse-und-ethernet-im-zeitalter-von-industrie-4-0-128660.html

Modbus ist ein relativ einfaches Master/Slave-Protokoll (https://de.wikipedia.org/wiki/Modbus), welches über verschiedene Leitungswege übertragen werden kann.
Die Frage, wie bestehende Modbus-Systeme mit einer Remote-Überwachung ausgestattet werden können, bzw. wie sich in solchen Systemen eine Predictive-Maintenance-Lösung aufbauen lässt, begegnet uns in Projekten immer häufiger.

Grund genug, hier ein paar grundlegende Gedanken zu diesem Thema zu Papier zu bringen.
Für die Übertragung der Daten in eine Cloud-Lösung á la Azure oder IBM Watson braucht es ein modernes Protokoll, welches auch dafür gemacht ist, mit geringem Ballast relevante Daten zu übermitteln. Ein in diesem Umfeld bewährtes Protokoll ist das MQTT Protokoll, welches wir in früheren Beiträgen schon ausführlich beschrieben haben, siehe:

Das MQTT Protokoll & Hintergründe (Teil 1)

Das MQTT Protokoll & Praxis (Teil 2)

Die Frage die sich nun stellt, ist: Wie kommen die Daten aus einem Modbus in MQTT? Eine kurze Internetrecherche bringt hier einige Ansätze, wie den von Oliver Wagner (https://github.com/owagner/modbus2mqtt) zum Vorschein. Allerdings ist diese Lösung genau wie viele andere für den Einsatz in bestehenden Installation ungeeignet. Der Grund liegt einfach in der Konzeption, denn die meisten gehen davon aus dass Sie ein Modbus Master sind und dann die Daten in MQTT übersetzen.

Das würde allerdings bedeuten, dass die MQTT Implementierung z.B. auf der bestehenden SPS erfolgen müsste, was in der Praxis nicht realisierbar ist.
Der Weg für bestehende Anlagen kann nur über einen Modbus Slave erfolgen. Einen solchen Slave könnte man relativ leicht auf einem Gateway implementieren. Dieses Gateway kann als normaler Busteilnehmer am Modbus arbeiten, ohne den Betrieb zu beeinflussen und alle Daten, die über den Bus laufen, mithören.
Eingriffsmöglichkeiten gibt es in dieser Konstellation zwar keine, aber das ist bei bestehenden Anlagen auch nicht wirklich gewollt.
Sollte man auch Steuerungsmöglichkeiten benötigen, könnte das Gateway als Busteilnehmer Register setzen, welche dann von der SPS in entsprechende Befehle für die anderen Busteilnehmer umgesetzt werden müssen.

Wie man einen solches Gateway aufbaut und welche Komponenten (Software/Hardware) zum Einsatz kommen können, wird der nächste Artikel beleuchten.


Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

IoT Protokolle – MQTT vs. AMQP

MQTT Protokoll – Anwendungsbeispiele

Embedded Software Entwicklung mit dem Standard Finite State Machine Framework

 

Die Evolution von Swift – the next level

Teil1

Es ist gut ein Jahr vergangen (Dezember 2015) seit Swift als Open-Source Programmiersprache das Licht der Welt(-Öffentlichkeit) erblickt hat. So finde ich, dass es mal wieder an der Zeit ist zu schauen, welche Evolution und Resultate diese recht junge Programmiersprache mittlerweile nach meiner ersten Bewertung und Prognose vom April 2016 in der Open-Source Entwickler Community gefunden hat. Um eine Sache vorweg zu nehmen: Mit Swift werden bereits produktive (Web-)Portal-Projekte umgesetzt (wie beispielsweise die Webseite des dänischen Triathlon-Events Ironman; Github-Source). So hat sich Swift tatsächlich in so kurzer Zeit von einer reinen Apple-Plattform Sprache (iOS, macOS, tvOS, watchOS) zu einem Linux-freundlichen Backend/Webframework-tauglichen Gesamtsystem entwickelt. Die aktuelle Version Swift3 genießt zudem große Kompatibilität im Segment der „kleinen ARM-Architektur Computer“ wie beispielsweise dem Raspberry Pi3 und dem dafür verfügbaren Ubuntu 16.04 als Betriebssystem; ergo die Software der Internet-Of-Things (IoT) kann ab jetzt tatsächlich ebenfalls mit dieser hochmodernen und performanten Programmiersprache entwickelt werden.

Weiterlesen

Viele Leser unseres Blogs haben uns nach dem Studium unseres Grundlagenartikels zum MQTT-Protokoll nach Anwendungsbeispielen gefragt. Diesem Wunsch wollen wir gerne entsprechen und präsentieren Ihnen nachfolgend eine kleine Sammlung einiger interessanter Projekte, bei denen das MQTT-Protokoll zum Einsatz kommt.

Wir bei SIC! Software setzen das MQTT Protokoll im Bereich von Embedded Projekten sehr häufig ein, da dieses Protokoll einfach zu handhaben ist und sich dank breiter Unterstützung zum DeFacto-Standard im Bereich von Internet of Things (IoT) und Industrie 4.0 entwickelt hat.

Wie z.B. beim Forschungsprojekt IMPROVE, bei dem das MQTT Protokoll dazu eingesetzt wird, um Echtzeitdaten vom Fahrzeug zu übertragen.
/forschungsprojekte/improve-automotive/

 

Da unsere Kundenprojekte der Vertraulichkeit unterliegen, listet die nachfolgende Sammlung beispielhaft öffentlich zugängliche Projekte mit MQTT-Support auf.

 

Beispiel 1: Übermittlung von Temperatursensor-Daten

Implementierung von MQTT auf dem  ESP8266 WIFI Funkmodul mit einer „einfachen“ publish / subscribe Routine.

http://www.s6z.de/cms/index.php/homeautomation-homecontrol/hardwareplattformen/esp8266/113-mqtt-basic-esp8266-mqtt-example

Beispiel 2: Übertragung des Haustürklingel-Signals

Installation des Moskito MQTT Broker auf einem Raspberry Pi. Ein ESP8266 nimmt das Klingelsignal an der Haustür auf und sendet es drahtlos an Fhem via MQTT.

http://blog.wenzlaff.de/?p=6487

Beispiel 3: Temperatur-Überwachung (Englisch)

Eine Musterhafte Lösung zur Überwachung von Temperaturen mit dem ESP8266 WIFI Funkmodul und der Anbindung an einen MQTT-Broker-Dienst unter Ubuntu:

http://www.instructables.com/id/Remote-Temperature-Monitoring-Using-MQTT-and-ESP82/

Beispiel 4: Basis-Plattform für Home-Automation (Englisch)

Implementierung eines MQTT-Stacks auf einem ATMEL  ATmega328p

http://blog.atx.name/building-avr-board-with-mqtt-support-for-iot/

Beispiel 5: Steuerung einer LED-Beleuchtung (Englisch)

Steuerung einer LED-Beleuchtung mit einem WS2812 LED Controller über das MQTT-Protokoll.

http://www.instructables.com/id/ESP8266-Led-Strip-MQTT-Control-Lights-WS2812/?ALLSTEPS

Beispiel 6: Regelung der CPU-Kühlung eines Raspberry Pi (Englisch)

Regelung der CPU-Kühlung eines Raspberry Pi über einen mit dem MQTT-Protokoll konfigurierbaren PID Regler:

http://www.instructables.com/id/PID-Control-for-CPU-Temperature-of-Raspberry-Pi/

Beispiel 7: Steuerung eines LCD-Displays (Englisch)

Applikationsbeispiel zur Steuerung eines LCD-Displays am INTEL Edison über das MQTT-Protokoll:

http://www.instructables.com/id/MQTT-what-is-this/

Weitergehende Grundlagen und Informationen zur MQTT-Standardisierung sind auf der Webseite http://mqtt.org/ beschrieben.


Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

IoT Protokolle – MQTT vs. AMQP

Modbus über MQTT – wie geht das?

Embedded Software Entwicklung mit dem Standard Finite State Machine Framework

Das „Internet of Things“ – kurz „IoT“ – ist im Moment das große Thema in der Industrie und Softwarebranche. Nachdem wir schon in einem etwas älteren Blockartikel das Thema MQTT aufbereitet und analysiert haben, ist es Zeit, sich einem zweiten wichtigen Protokoll im Umfeld von IoT anzunehmen. In diesem Artikel werden wir die beiden Protokolle vergleichen und mögliche Unterschiede bei den Einsatzszenarien beschreiben.

Wer heute ein IoT-Projekt umsetzen möchte, muss sich vor allem Gedanken darum machen, wie er die auszutauschenden Daten möglichst effizient und standardisiert übertragen kann. Zu diesem Zweck gibt es verschiedenste Protokollstandards, die entwickelt wurden, damit Plattform und Technologie übergreifend miteinander kommunizieren können.

Speziell im IoT Umfeld erfüllen die entwickelten Protokolle vor allem noch die Aufgabe möglichst mit wenigen Ressourcen auszukommen.

Was ist also AMQP und was kann es leisten?

AMQP steht für Advanced Message Queuing Protocol und wurde durch ein Konsortium von großen Unternehmen aus verschiedenen Branchen – u.a. VMware, Microsoft und Cisco – entwickelt. Bereits in 2010 gab es den ersten Draft des Protokolls.

Im Kern handelt es sich um ein asynchrones Protokoll zur Nachrichtenübertragung. Die bisher beste Erklärung zur Idee hinter AMQP findet man auf der Seite von RabbitMQ (https://www.rabbitmq.com/tutorials/amqp-concepts.html).

AMQP funktioniert demnach nach folgendem Prinzip:
Nachrichten werden an sogenannte Börsen (Exchanges) übertragen (vergleichbar mit einem Postamt). Die Börsen verteilen dann Nachrichtenkopien in Warteschlangen (Queue) basierend auf Regeln, sogenannten Bindings.

Die Nachrichten werden dann vom Empfänger direkt abgeholt, wenn er das möchte. Alternativ kann der Empfänger die Nachrichten auch bei einer Warteschlange abonnieren und bekommt diese dann direkt zugestellt.

Wenn die Nachrichten publiziert werden, kann der Herausgeber der Nachricht diese noch mit Attributen (Meta-Daten) versehen. Diese Metadaten können vom Empfänger beliebig genutzt werden.

Nachrichten bleiben so lange in den Warteschlangen, bis der Empfänger bestätigt hat, die Nachricht auch wirklich empfangen zu haben. Damit ist auch bei schlechtem Netz und Abbrüchen bei der Verbindung sichergestellt, dass die Nachricht den Empfänger erreicht.

Wenn eine Nachricht nicht zugestellt werden kann, erhält der Sender eine entsprechende Nachricht.
Die Umsetzung der Börse und der Warteschlange erfolgt innerhalb des sogenannten Brokers. Ein Broker ist z.B. der freie Server von RabbitMQ.

Die Börse ist dafür zuständig, die Nachrichten in eine oder mehrere Warteschlangen zu übertragen. Die Regeln dafür leiten sich aus den vordefinierten Austauschformaten (exchange types) und den Bindings ab.

Es gibt vier solche Austauschformate:

  • Direct –> Stellt eine feste Verbindung zwischen einer Börse und einer Warteschlange dar. Wenn eine Nachricht mit einem entsprechenden Schlüssel ankommt, wird diese gleich an die verknüpfte Warteschlange zugestellt.
  • Fanout –> Wird für sogenannte Broadcast Nachrichten verwendet. Die Nachricht wird von der Börse an alle angeschlossenen Warteschlangen zugestellt
  • Topic –> Wird für Publish/Subscribe Szenarien verwendet. Die Nachrichten werden an eine oder mehrere Warteschlangen ausgeliefert, abhängig vom Binding Key. Folgendes Bild von RedHat veranschaulicht das sehr schön.

    https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/2/html-single/Messaging_Programming_Reference/index.html
  • Headers –> Die Zustellung der Nachricht zur Warteschlange erfolgt hier über den Nachrichten-Header und nicht den Routing Key. Es ist vergleichbar mit dem Direct Routing – nur mit etwas mehr Möglichkeiten zur Regelerstellung.

Neben den Austauschformaten gibt es eine Reihe von Attributen für die Nachrichten. Die wichtigsten sind:

  • Name
  • Durability (gibt an, ob die Börse einen Neustart des Broker übersteht)
  • Auto-delete (Börse wird gelöscht, wenn keine Warteschlange diese benötigt)

AMQP vs. MQTT im Vergleich

Der größte Unterschied der beiden Protokolle besteht in den Möglichkeiten für die Nachrichtenzustellung. Während MQTT ausschließlich auf Publish/Subscribe basiert, lassen sich mit AMQP auch andere Zustellungsformen realisieren.

Außerdem ist der Unterschied bei der Implementierung nicht zu unterschätzen. MQTT ist mit seinen 5 Methoden relativ schnell und einfach umzusetzen, während AMQP schon einen vergleichsweise großen Umfang mit sich bringt. Das betrifft sowohl die Definition des eigenen Protokoll wie auch die Implementierung und Test.

Die kleinste Paketgröße bei AMQP ist mit 60 Byte auch nicht zu vernachlässigen. MQTT begnügt sich im besten Fall mit 2 Byte. Das beeinflusst insbesondere bei einer großen Zahl von Geräten und Nachrichten den aufzuwendenden Aufwand erheblich. Dazu kommen größer Laufzeiten der Pakete die je nach Anwendungsfall auch kritisch zu betrachten sind.

Es gilt also abzuwägen, ob der Funktionsumfang von AMQP im jeweiligen Anwendungsfall wirklich benötigt wird oder nicht. Wenn man mit dem Publish/Subscribe Model von MQTT auskommen kann, hat man in jedem Fall eine einfacher umzusetzende und auch ressourcenschonende Lösung.


Vielleicht auch interessant:

Das MQTT Protokoll – Hintergründe (Teil 1)

Das MQTT Protokoll – Praxis (Teil 2)

MQTT Protokoll – Anwendungsbeispiele

Modbus über MQTT – wie geht das?

Embedded Software Entwicklung mit dem Standard Finite State Machine Framework

 

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.

Weiterlesen

Beacons
Im Sommer 2013 wurden sie offiziell vorgestellt und so langsam kommt die ganze Sache auch ins Rollen. Die Rede ist von der Beacon Technologie. Beacons (Signalfeuer) sind kleine Bluetooth-Sender, welche an einem Ort angebracht werden können und in regelmäßigen Zeitintervallen ein Erkennungssignal aussenden. Dieses Signal kann dann von einem Beacon-fähigen Gerät wie einem Smartphone oder Tablet empfangen und in ortsabhängige Informationen umgewandelt werden. Die Anzahl an Anwendungsgebieten ist dabei grenzenlos. Meistens werden Beacons mit typischen Einsatzgebieten wie …

Weiterlesen

Während unser erster Blog-Artikel zum Thema MQTT eher theoretischer Natur war, möchten wir uns nun dem praktischen Teil widmen.

Alles was wir dazu benötigen ist eine MQTT-Client Library sowie einen Broker. Eine große Auswahl an verschiedenen Client- und Broker Implementierung bietet das Eclipse Paho Projekt. Zur Zeit stellt es Implementierungen für C, Java, Javascript, Python, Lua, C++, Embedded C und bald auch Objective-C bereit. Als Broker empfehlen wir die kostenlose Lösung von Mosquitto. Wer Probleme mit der Installation hat, sollte sich diesen Link zu Gemüte führen: Guide to Installing Mosquitto MQTT. Zu Demonstrationszwecke oder einfachen Versuchen, lohnt es sich allerdings die sogennanten Public-Brokers zu verwenden. Eine kleine Auswahl an solchen ist hier zu finden: Public Brokers.
Weiterlesen

Internet of things: Viele haben schon mal was davon gehört, aber nur wenige können so richtig beschreiben was es überhaupt ist… dieses „Internet of things“? Wikipedia beschreibt es folgendermaßen:

The Internet of Things refers to the interconnection of uniquely identifiable embedded computing like devices within the existing Internetinfrastructure. 

Weiterlesen