O365 Deployment Strategien

2. Türchen

Im 1. #O365Adventskalender Türchen hatte ich kurz die Möglichkeit des hybriden Ansatzes erwähnt sowie die drei Kernprodukte von Office 365: SharePoint, Exchange und Skype for Business. Mit diesen drei Lösungen lassen sich verschiedene Deployment Strategien realisieren, um die Nutzung der Cloud-Technologien zu ermöglichen. Denn bevor man die Cloud kategorisch ausschließt, weil man glaubt, Microsoft gelangt an meine Daten und ich verliere damit die Kontrolle darüber, möchte ich erklären, was neben diesen Mythen alles möglich ist.

Un-Trusted Non-SharePoint Hybrid

Dieses Szenario wurde am häufigsten mit BPOS genutzt. Man kann dieses Szenario auch so beschreiben: man testet vorsichtig das Wasser. Hierbei werden also die Produkte „outgesourced“, deren Kosten sehr hoch und die Verwaltung kompliziert ist. Auf der anderen Seite ist die Migration und Implementierung mit O365 sehr einfach. Auch wenn die Anwender zwei Benutzerkonten haben und sich dementsprechend für die jeweiligen Dienste doppelt authentifizieren müssen, so ist dies dennoch ein sehr gern gewähltes Szenario für den Start in die Cloud.

Un-Trusted Hybrid

In diesem Szenario hat man sich bereits vergewissert, dass das Wasser schön warm ist und taucht nun den großen Zeh ein. Aus meiner Sicht das perfekte Cloud-Einstiegs-Szenario mit SharePoint. Wie im obigen Fall nutzen wir Exchange und Skype for Business in O365, aber nehmen nun noch SharePoint, bzw. OneDrive for Business (OD4B) mit hinzu. Da die persönlich-geschäftlichen Bereiche der Mitarbeiter – früher bekannt als MySite – generell separat von den „normalen“ SharePoint Web Applications verwaltet wurden, kann man so auch nun diesen Bereich einfach abtrennen und den Mitarbeitern die Vorteile der Cloud auf ihren „Laufwerken“ zur Verfügung stellen. Leider bleibt jedoch der Nachteil der doppelten Authentifizierung.

Trusted Hybrid

Bei diesem Szenario werden die Active Directory Dienste vereint und nur noch von der Cloud aus, also dem Azure AD, verwaltet. Die doppelte Authentifizierung fällt daher weg. Generell kann dieses Szenario auch ohne SharePoint oder nur mit dem OD4B Ansatz gewählt werden. Ebenso häufig begegnet mir dieser Anwendungsfall aber auch bei Firmen, die in Zukunft voll auf die Cloud-Lösungen setzen wollen. Auf spezifische Unternehmenslösungen, die nicht in Office 365 eingespielt werden dürfen, wie z.B. Custom Solutions (*.wsp), kann aber zukünftig nicht verzichtet werden, sodass sie weiterhin auf der On-Premises Farm laufen. Langfristig empfehle ich aber, diese Lösungen in Apps umzuschreiben oder sie „cloud-ready“ zu machen in Form einer online-gehosteten Anwendung, die das SharePoint Framework nutzt.

All-In

Ist man sich dann irgendwann sicher über die Vorteile der Cloud und hat auch keinen Bedarf mehr bzw. regulatorische Auflagen, weiterhin Lösungen im eigenen Datencenter bereitstellen zu müssen, dann können ausschließlich die Dienste in Office 365 genutzt werden. Dieses Szenario ist typisch für alle kleinen Firmen mit weniger als 50 Mitarbeitern, die keine eigene IT mehr verwalten wollen oder können.

Ein O365 All-In Deployment wird für gewöhnlich in der Office 365 Public Cloud gehostet. Das heißt, der Tenant (zu deutsch: Mieter = gemietete Software von Microsoft) muss sich die Microsoft Server-Ressourcen mit den Tenants anderer Kunden teilen. Damit Aktionen eines Kunden nicht das Benutzererlebnis eines anderen beeinflusst – Stichwort Performance – gibt es eine Drosselung.

Für normale Anwendungsfälle sollte es nie zu einer Drosselung kommen, da O365 explizit für viele Nutzer entwickelt wurde. Möglich ist so ein Szenario dennoch, wenn viele „Customizations“ über die Programmierschnittstellen zugreifen. Die API (Application Programming Interface) selbst ist zwar nicht gedrosselt, aber Programmzugriffe wie REST Calls, Web Services oder CSOM – erlaubt ist 1 Zugriff pro Sekunde. Werden mehr Zugriffe an O365 registriert, würde ein Endbenutzer mit dem zusätzlichen „unerlaubten“ Aufruf zu einer entsprechenden Informationsseite weitergeleitet werden. Programme würden einen HTTP Status-Code 429 von SharePoint Online erhalten. Wird dauerhaft dieser Grenzwert überschritten, kann SharePoint den Prozess sogar komplett mit einem HTTP 503 („Service unavailable“) blockieren. Quelle: https://msdn.microsoft.com/en-us/library/office/dn889829.aspx

Bei einem Szenario mit geteilten Server-Ressourcen macht so eine Drosselung natürlich Sinn. Auch andere Plattformen machen dies:

• Twitter: https://dev.twitter.com/rest/public/rate-limiting
• Facebook: https://developers.facebook.com/docs/reference/ads-api/api-rate-limitin
• Google: https://cloud.google.com/compute/docs/api-rate-limits

Bei Microsoft kann man sich eine Private O365 Cloud bestellen, um diese Drosselungen zu umgehen und weitere Vorteile einer “eigenen” Umgebung zu nutzen. Diese ganz speziellen Szenarien der privaten Cloud sowie Lösungen für Entwickler bei Drosselungsproblemen, würden hier aber zu weit führen, daher belassen wir es bei den obigen Informationen.

Nun haben wir verschiedene Anwendungsfälle mit O365 kennengelernt. Was ist eure Deployment Strategie? Wofür habt ihr euch entschieden? Lasst es mich wissen.

Happy „SharePointing“!

Zur O365Adventskalender Übersicht