© istockphoto.com/PixelEmbargo, © S&S Media
Azure Mobile Web Apps vs. Azure Mobile Services

Dienst auf Stundenbasis?


Azure Mobile Services bzw. Web Apps versprechen schnelle und sichere Cloud-Backends für mobile Anwendungen, die sich auch ohne große Weberfahrung schnell implementieren lassen. Seit Einführung der RTM-Version ist die Authentifizierung von Cloud-Backends dank des neuen Azure-Portals nochmals einfacher geworden – leider nunmehr auch mit einer Einschränkung, die auf RTM angepasste Apps nahezu zum Showstopper werden lässt. Doch es gibt Workarounds.

Als Microsoft die Azure Mobile Services vor einigen Jahren eingeführt hat, war das gerade für das Migrationsbusiness schon eine geniale Sache. Schließlich haben wir es bei Softwaremigrationen mit einem Entwickler­klientel zu tun, das mit seiner Fokussierung auf monolithische Smart-Client-Anwendungen à la WPF, wenn nicht Windows Forms, mitunter nicht nur ein enormes Aufholpotenzial in Sachen Webentwicklung hat. Vielmehr schrecken die Entscheidungsträger in vielen Fällen noch heute vor der Migration oder auch der Teilmigration ihrer Software in die Cloud aus vermeintlich rechtlichen oder sicherheitsrelevanten Aspekten zurück.

Dennoch verändern sich natürlich die Anforderungen an die althergebrachten „Apps“ (Darf man eine WinForms-Businessanwendung eigentlich auch so nennen?), und damit gibt es immer Bedürfnisse – selbst in den eher konventionellen Branchen – auch mit wirklichen, mobilen Apps auf Windows Phone, iOS oder Android an den Start zu gehen.

Leicht bewölkt

Zum Glück heißt das Azure-Motto hier nicht „Cloud oder Onsite“ – es geht nämlich auch leicht bewölkt. Und so stellen wir fest, dass Azure mit den Azure Mobile Web Apps (oder vormals Azure Mobile Services) als eine recht einfach zu implementierende Lösung für eine mobile Schnittstelle in Betracht kommt: Nur die relevanten Daten, die für den mobilen Part einer monolithischen Gesamtlösung relevant sind, finden sich dabei in einer Azure-Datenbank, und das auch nur so lange wie nötig. Die mobilen Geräte, wie sie beispielsweise vom Außendienst oder von Kunden direkt verwendet werden, greifen auf die Cloud-Lösung zu. Ein Synchronisationsdienst, der Onsite läuft, verbindet sich dann mit dem in der Cloud liegenden Austauschpunkt, sammelt die notwendigen Daten wieder ein und löscht sie im Cloud-Speicher.

Klar, diese Vorgehensweise wirkt beim heutigen Stand der Technik ein wenig veraltet. Aber sie hat auch den Charme, dass die Onsite-IT sich nicht um Azure AD, SQL-Server-Synchronisation und andere, bestimmt elegantere Lösungen kümmern bzw. diese Techniken beherrschen muss. Die vorhandene Onsite-Basis bleibt exakt wie sie ist, und das Vertrauen in „das neue Cloud-Zeugs“ kann nach und nach aufgebaut werden.

Azure Mobile Services – oder nunmehr Azure (­Mobile) Web Apps – bieten sich für dieses Klientel mehr als an, und zwar aus zweierlei Gründen: Einerseits braucht man für die dennoch notwendige Implementierung der Authentifizierung am Backend so gut wie keine Expertise – man verwendet einfach einen oder mehrere der von den Services bereitgestellten Authentifizierungsprovider. Und da mit Windows Phone, Windows 10 und bei der Verwendung von Diensten wie OneDrive oder Office 365 in der Regel jeder einen Microsoft-Live-Account hat, bietet sich dieser hier an. Zum Zweiten ist jeder Entwickler des alten Teams, auch wenn er überhaupt keine Erfahrung in der Programmierung von Web-API-Backends mit ASP.NET hat, durch den einfachen Umgang mit den auf OData basierenden Mobile Services Tables nach ein, zwei Tagen Schulung fit und kann sofort produktiv im Team mitarbeiten.

Teams, die bislang mit Azure Mobile Services arbeiten, können den Dienst vorerst beibehalten, denn das Umstellen auf den Nachfolger Azure Mobile Web Apps ist keine Fünf-Minuten-Sache – zu groß sind die Break­ing Changes von den ersten 0.2x-Versionen bis zur RTM, die dann erstmals eine 1 in der Versionsnummer voran trug. Obendrein gibt es nach der Migration zu Azure Mobile Apps – bzw. Azure Web Apps, wie sie ja nach dem letzten RTM-Release genannt werden – mit dem Microsoft Authentication Provider ein weiteres Problem: Die durch ein Login verteilten Tokens reichen gerade einmal eine Stunde und eine Reauthentifizierung sehen die Mobile Services in dieser ersten RTM-Version noch nicht vor – vom Single Sign-On ganz zu schweigen.

Für den Anwender einer App heißt das: Nach einer Stunde spätestens muss das Kennwort abermals eingegeben werden und dann wieder und wieder, und das führt den gerade noch so einfach zu implementierenden Log-in-Prozess ad absurdum: Ein solches Verhalten ist schlicht nicht haltbar. Was also tun? Weiter mit den veralteten, mitunter noch fehlerbehafteten Mobile Services Apps der Version 0.2x arbeiten und warten, bis Microsoft irgendwann einmal das Migration-per-Mausklick-Tool zur Verfügung stellt? Oder nicht mehr warten, und durch den nicht so ganz einfachen Migrationsprozess manuell gehen? Und was ist dann mit dem Authentifizierungsproblem?

Dank der Microsoft OneDrive Services [1] gibt es eine Zwischenlösung. Damit lässt sich die Umstellung schon jetzt vollziehen – wie das geht, zeigen die folgenden Schritte. Wie Sie darüber hinaus das stundenweise Ablaufen der Authentifizierung in den Griff bekommen, finden Sie im Anschluss beschrieben.

Von Mobile Services zu Azure (Mobile) Web Apps

Um ei...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang