Geschichte

Während vielen Jahren haben zuerst SOAP und dann REST APIs Einzug gehalten und die Strukturen und vor allem die Performance und Usability von professionellen WebApplikationen optimiert.
Die APIs können asynchron von der WebSeite gerufen werden und sobald ein Resultat da ist, kann es auf der Seite angezeigt werden.

Das hat uns ermöglicht, WebApplikationen zu bauen, welche fast wie eine Desktop-Applikation funktioniert. Die jedoch im Browser angesteuert werden kann und daher einem breiten Publikum zur Verfügung steht und auch viel einfacher Highly Available gemacht werden kann.

Problemstellung

Es gab aber immer das Problem, dass die Schnittstelle nur ein-dimensional ist (get) und keine Server zu Browser Kommunikation erlaubt hat.
Wie oft haben Sie „polling“ eingeführt, welches zu einer Unmenge von unnötigen Requests zum Server geführt hat?

Des Weiteren ist es auch nicht sonderlich produktiv, dass bei jedem API request eine neue HTTP connection aufgebaut werden muss.

Lösung

Die Lösung dafür heisst WebSockets.
Damit kann man einen WebSocket Kanal öffnen, der zwischen dem Browser und dem Server bestehen bleibt. Danach kann man so viele Nachrichten durch den Kanal schicken, wie man möchte.

Und ja, man kann auch Informationen vom Server direkt zum Browser „pushen“ – das Ende des Polling 🙂

Performance-Technisch hat sich erwiesen, dass die Verbindungen (vor allem bei höherer Anzahl) viel schneller sind und keine neuen connections aufgebaut werden müssen.

Interessiert? Kontaktieren Sie uns 🙂

Problemstellung

Wenn Sie Atlassian JIRA nutzen, kennen Sie vielleicht das Problem, dass viele Issues im System verloren gehen. Vor allem, wenn ein User inaktiv wird ist es schwierig nachzuvollziehen, welche Arbeit übergeben werden soll.

Manuelle Zwischenlösung

Ja, man könnte doch alle Issues einfach per Bulk-Request an jemand anderen assignen?
Ist das die richtige Lösung? ==> Nein…

Die richtige Lösung

Wir haben ein NodeJS Lambda Funktion in AWS entwickelt, welche unsere JIRA Instanz täglich nach inaktiven Usern überprüft und nicht geschlossene, dem inaktiven User zugewiesene Issues automatisch an den Projekt Lead des Issues assigned.

So kann der Projekt Lead dann den Issue entsprechend neu zuweisen und die Aufgabe geht nicht vergessen/verloren.

Interessiert? Kontaktieren Sie uns 🙂

Problemstellung

Viele KMUs haben heute noch On-Premise oder Semi-Cloud Infrastruktur, welche lokal verwaltet werden muss.
Daraus ergibt sich das Problem, dass lokale Infrastruktur (auch wenn virtuell) immer auf den neusten Stand gebracht werden muss.
Viele Server sind nur teilweise ausgelastet und es ist schwer und risikoreich, Applikationen auf dem selben Server zu deployen und zu starten.

Zwischenlösung 1) Cloud Services

Nun migrieren viele KMUs Ihre Applikationen in die Cloud. Dafür ist aber viel Know-How und auch Fingerspitzengefühl nötig.

An vielen Stellen scheitert das Projekt dann an den Kosten – denn nicht jeder Service macht direkt Sinn in der Cloud.
Und es ist auch wichtig zu verstehen, wie man die Services in die Cloud migrieren muss, damit es kostenmässig Sinn macht.

Zwischenlösung 2) Applikationen in Containern

Andere streben die bessere Ausnutzung der On-Premise Infrastruktur an. Hier kann man mit Containern eine wunderbare Aufteilung der Ressource schaffen.
So ist es aber noch nicht viel mehr als eine Virtualisierung, mit den bekannten Nachteilen der steigenden Komplexität.

Daher ist es noch nicht die Lösung, aber ein grosser Schritt in die Vereinfachung der Deployments und in die Portierbarkeit der Applikationen. Der Schritt ind ie Cloud ist so deutlich leichter und man kann einen fliessenden Übergang von On-Premise zur Hybrid Cloud erreichen.

Die Lösung

Ganz einfach: die Hybrid Cloud.

In der Hybrid Cloud verbindet man seine On-Premise-Infrastruktur mit der Cloud und deployed eine Applikation wo sie am meisten Sinn macht und wo es gerade Platz gibt.
Eine Migration von On-Premise zu Cloud wird denkbar leicht und man kann die Power und die Vorteile der beiden Lösungen miteinander Verbinden.

In unserem letzten Projekt haben wir eine Hybrid Cloud mit Docker Swarm auf On-Premise und AWS eingerichtet.

Per Tagging haben wir die Freiheit zu entscheiden, wo etwas deployed werden soll – und Docker Swarm übernimmt den Rest.

Wenn ein Server ausfällt, ganz egal ob On-Premise oder in der Cloud, läuft alles weiter, da die Services automatisch neu gestartet und über die Systeme verteilt werden.

Interessiert? Kontaktieren Sie uns 🙂