Atlassian Hosting

Atlassian Hosting: Technische Herangehensweise

Es gibt etliche Möglichkeiten von Atlassian Hosting. Server, Data Center oder auch direkt in der Atlassian Cloud. Eine dieser Möglichkeiten ist es Atlassian Software direkt auf deinen eigenen Server oder bei AWS / Azure (Cloud Provider) zu hosten.

In diesem kurzen Artikel findest du alle Informationen und Requirements zum hosten von Atlassian Software.

Atlassian Hosting

Atlassian Hosting: Voraussetzungen

Offizielle Domain mit einem DNS-Server, auf dem EintrĂ€ge hinzugefĂŒgt werden können und die aufgelöst werden können.

DNS-EintrÀge, die auf die externe IP des Servers zeigen, auf dem die Atlassian-Anwendung laufen soll.

Wenn Route 53 verwendet wird, können wir mit dem certbot und letsencrypt Wildcard-Zertifikate fĂŒr die gesamte Domain generieren.

Anwendungsserver

Server-Bereitstellung

Als Applikationsserver verwenden wir in der Regel Ubuntu und lassen Ansible laufen, um ihn zu konfigurieren. Ansible nimmt dann einige Grundkonfigurationen vor und installiert benötigte Software, wie Docker auf dem Host. Es werden auch einige Docker-Anwendungen auf einem Host ausgerollt, wie der Reverse-Proxy.

Reverse-Proxy

Als Reverse-Proxy verwenden wir das Docker-Image xalt/nginx. Dieses kann sich an den Docker-Socket anhĂ€ngen und ist dadurch in der Lage zu lesen, welche Docker-Container auf dem Host laufen. Wenn eine Anwendung bestimmte Parameter gesetzt hat, wird die Nginx-Konfiguration automatisch geĂ€ndert und neu geladen, Upstream- und Server-Konfigurationen werden fĂŒr die angegebenen virtuellen Hostnamen und Ports erstellt. Wenn der Hostname mit einem verfĂŒgbaren SSL-Zertifikat ĂŒbereinstimmt, wird auch ein SSL-Listener fĂŒr diese Anwendung konfiguriert. Der Reverse-Proxy kann Inhalte ĂŒber 80 (http) und 443 (https) bereitstellen, diese Ports werden auf die Host-Ports 80 und 443 montiert.

Managed Atlassian Hosting

Reduzieren Sie die BetriebskomplexitÀt und vereinfachen Sie den Betrieb Ihrer Atlassian-Produkte wie Confluence, Bitbucket und Jira.

Lizenzmanagement

Es wird ein Side-Cart-Container bereitgestellt, der Let’s Encrypt-Helfer. Dieser Container hat ebenfalls Lesezugriff auf den Docker-Socket, und wenn ein Container Let’s Encrypt-Parameter bereitstellt, initiiert er eine Let’s Encrypt-Zertifikatsherausforderung und speichert die Zertifikate, damit der Reverse-Proxy-Container sie fĂŒr die https-Verbindungen verwenden kann.

Docker-Anwendung

Alle Docker-Anwendungen werden in einer Datei docker-compose.yml beschrieben, die von Ansible bereitgestellt wird. JIRA/ Confluence und die PostgreSQL-Datenbank haben ihr Home-Verzeichnis in separaten Verzeichnissen auf der gleichen Ebene wie die docker-compose.yml eingebunden. Auf diese Weise befinden sich die Anwendungskonfiguration und die Anwendungsdaten im gleichen Bereich und können leicht gepflegt werden.

JIRA/ Confluence

Dieser Docker-Container fĂŒhrt einen Tomcat mit der JIRA-Anwendung aus. Der Tomcat-Connector muss ĂŒber Environment-Variablen des Containers korrekt konfiguriert werden. Gleiches gilt fĂŒr die AnwendungsĂŒberwachung ĂŒber NewRelic. Die Heap-Parameter können auf die gleiche Weise konfiguriert werden und natĂŒrlich mĂŒssen die Reverse-Proxy-Parameter gesetzt werden, ebenso wie die Letsencrypt-Parameter, falls erforderlich.

FĂŒr Testsysteme haben wir noch ein paar weitere Features implementiert, um die Wiederherstellung der persistenten Home-Daten via ssh rsync und die Modifikation der Datenbank mit Liquibase zu ermöglichen. So können z.B. die Basis-URL oder die Applikationslinks geĂ€ndert werden.

PostgreSQL

Wir verwenden in der Regel einen PostgreSQL-Container und spawnen ihn in einem separaten, anwendungsspezifischen Docker-Netzwerk unter dem DNS-Namen „db“, der nur fĂŒr die in dieser docker-compose.yml-Datei angegebenen Container erreichbar ist. Benutzername, Passwort und Datenbank werden als Umgebungsparameter des Containers angegeben. Die Datenbank fĂŒr JIRA/ Confluence kann auch MySQL oder OracleSQL sein, wir haben uns aber aus KompatibilitĂ€tsgrĂŒnden fĂŒr PostgreSQL entschieden.

FĂŒr Testsysteme haben wir ein paar weitere Features implementiert, um die Wiederherstellung der persistenten Home-Daten per ssh rsync zu ermöglichen.

Backup

Dieser Container fĂŒhrt im Grunde einen Cron-Job aus, der den JIRA/Confluence- und PostgreSQL-Container herunterfĂ€hrt und die persistenten Home-Ordner per rsync auf den Backup-Server ĂŒbertrĂ€gt. Dieser Container wird ebenfalls durch mehrere Umgebungsparameter konfiguriert, wie z.B. die Cron-Job-Zeit, den Namen des Backup-Servers und benötigt außerdem einige Mount-Punkte, wie z.B. den Docker-Socket, um Docker-Container von innerhalb eines Docker-Containers herunterzufahren und zu starten. Außerdem werden weitere Mounts benötigt, um zu lokalisieren, wo sich die Daten befinden, die gesichert werden sollen.

Web-Anfrage

Wenn auf eine Docker-Anwendung zugegriffen werden soll, gibt der Benutzer in der Regel einen DNS-Namen in den Browser ein. Die IP versucht, durch eine DNS-Anfrage an R53 aufgelöst zu werden. Die Antwort ist in der Regel ein A-Record, der auf den Server zeigt, auf dem die Anwendung lĂ€uft. Der Browser baut eine Verbindung zum Port 80 des Anwendungsservers auf. Dort leitet der Docker-Proxy die Anfragen an den Nginx-Reverse-Proxy weiter, der auf https umleitet, wenn ein gĂŒltiges Zertifikat fĂŒr den virtuellen Hostnamen der Anwendung existiert. Wenn diese Direktive vom Browser ausgefĂŒhrt wurde, wird die Anfrage auf Port 443 am Applikationsserver angenommen. Diese geht an den Reverse-Proxy, der sie dann an den konfigurierten Upstream, die Atlassian-Anwendung, sendet und die Antwort an den anfragenden Browser ausliefert, um dort weitere Ressourcen zu laden und im en die heruntergeladene Webseite zu rendern.

Atlassian Hosting: Backup-Server

Dieser Host wird normalerweise mit großem Speicher bereitgestellt, um die Anwendungsdaten mehrerer Docker-Anwendungen zu speichern. Er wird ebenfalls ĂŒber Ansible provisioniert.
Hier wird standardmĂ€ĂŸig nicht Docker installiert, sondern rsync und rsnapshot, die fĂŒr unser Backup-Konzept die wichtigsten Bestandteile sind. Rsync wird fĂŒr den Datentransport von Host zu Host, aber auch fĂŒr rsnapshot eingesetzt.
Die ĂŒbliche Konfiguration fĂŒr den Aufbewahrungsmechanismus erlaubt die Speicherung von 7 tĂ€glichen, 4 wöchentlichen und 12 monatlichen Backups. Dabei wird fĂŒr die Sicherung die Verwendung von Hard-Links erzwungen, um Platz zu sparen, wenn eine Datei seit dem letzten Tag nicht mehr angefasst wurde.
Auf diese Weise wird etwa das 2,5-fache der ursprĂŒnglichen AnwendungsgrĂ¶ĂŸen verbraucht (rsync der Daten vom Anwendungsserver zum Backup-Server verbraucht 1 + die rsnapshot-Kopie davon und die entsprechenden Deltas nehmen noch einmal die 1,5-fache GrĂ¶ĂŸe ein), um Backups zu haben, die bis zu 12 Monate zurĂŒckgespielt werden können.

Mehr zu Managed Atlassian Hosting

Das ganze Konzept erfordert die Erzeugung eines SSH-SchlĂŒssels auf dem Applikationsserver und die Speicherung des öffentlichen SchlĂŒssels in den autorisierten SchlĂŒsseln des Root-Benutzers des Backup-Servers:

  1. Synchronisieren der Daten (rsync) vom Backup-Container (Anwendungsserver) zum Backup-Server.
  2. Rsnapshot wird durch eine Cronjob-Logik ausgelöst, um die verschiedenen Aufbewahrungskonfigurationen einmal pro Tag, Woche und Monat auszufĂŒhren.
  3. Eine Docker-Applikation wird mit den korrekt angegebenen Backup-Parametern gestartet und wird diese Daten vom Backup-Server rsyncen, bevor die Applikation startet.

Die Daten, die wiederhergestellt werden sollen, können im Docker-Container von JIRA/Confluence und PostgreSQL konfiguriert werden. Wenn das aktuellste Backup benötigt wird, können die Zielordner des rsync-Backups angegeben werden. Wenn jedoch Daten eines Àlteren Backups wiederhergestellt werden sollen, benötigen wir hier den richtigen rsnapshot-Pfad.

Managed Atlassian Hosting

Reduzieren Sie die BetriebskomplexitÀt und vereinfachen Sie den Betrieb Ihrer Atlassian-Produkte wie Confluence, Bitbucket und Jira.

Lizenzmanagement
Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes

Deployment von Atlassian Software mit AWS und Spinnaker – Teil 3 Projektmangement & DNS

Auch im Bereich Cloud Hosting von Atlassian Software mit AWS oder Spinnaker bietet es sich an, dediziertes Projekt und User Management zu haben. FĂŒr Kubernetes gibt mehrere Möglichkeiten, die Projekt- und Benutzerverwaltung zu handhaben:

  1. Man kann mehrere EKS-Cluster einrichten und sie auf diese Weise voneinander trennen:
    • Dies ist zunĂ€chst eine einfache und saubere Lösung, da man keinen Weg finden muss, um Ressourcen und Berechtigungen zu trennen.
    • Wenn diese Cluster unabhĂ€ngig voneinander verwaltet werden sollen und wahrscheinlich unabhĂ€ngige Anwendungen bereitstellen, kann dies ein gĂŒltiger Ansatz sein.
    • Wenn die Cluster stattdessen zentral verwaltet werden sollen, verursacht dies eine Menge administrativen Aufwand und erfordert eine weitere Logikschicht, um Deployment-Pipelines, Benutzerrechte und weitere Automatismen zu implementieren.
  2. Ein einzelner EKS-Cluster kann die Projekt- und Benutzerverwaltung mit nativen Kubernetes-Funktionen handhaben.
    1. Projekte können in verschiedenen Namespaces verwaltet werden:
    2. Deployments können durch umfangreiches Tagging getrennt werden.
    3. Kubernetes bietet die Möglichkeit, Rollen mit dedizierten Berechtigungen auf Kubernetes-Ressourcen einzurichten, auf die Benutzer und Ressourcen zugreifen können, um eine feingranulare Rechteverwaltung zu ermöglichen
    4. Mit diesem Konzept können natĂŒrlich zusĂ€tzlich weitere Cluster eingerichtet werden, zum Beispiel fĂŒr Projekte mit abweichenden Konfigurationen oder fĂŒr Kubernetes-Updates.

Beide Optionen sind legitim und es kommt darauf an, wie Sie den/die Cluster in Zukunft administrieren wollen.

Netzwerk/ DNS

Die Compute Nodes selbst sind ĂŒber ein anderes Netzwerk miteinander und mit dem Master verbunden. Damit eine in Kubernetes bereitgestellte Anwendung von außerhalb des Clusters erreichbar ist, muss ein Ingress bereitgestellt werden, der als Tor außerhalb des Clusters fungiert.

Innerhalb des Clusters ist es fĂŒr jeden Pod immer möglich, sich mit einem anderen Pod zu verbinden. Das liegt daran, dass Kubernetes sein eigenes Netzwerk erzeugt, in dem alle Deployments stattfinden. Jeder Pod innerhalb von Kubernetes erhĂ€lt eine eigene IP-Adresse.

Vernetzung innerhalb Kubernetes

Wie die Vernetzung innerhalb von Kubernetes funktioniert, hÀngt stark davon ab, welche Netzwerk-Plugins und welcher Ingress-Controller installiert ist. Dadurch wird sichergestellt, dass die Umgebung innerhalb von Kubernetes auf die Anforderungen der Anwendung zugeschnitten werden kann.

EKS ist in der Lage, je nach installiertem Ingress-Controller verschiedene Arten von Loadbalancern zu spawnen. Hier empfiehlt es sich, einen externen DNS-Dienst zu verwenden und damit sicherzustellen, dass mindestens ein Pod immer ĂŒber diesen DNS-Namen erreicht werden kann, um maximal ausfallsicher zu sein.

Netzwerk/ DNS

Die Compute Nodes selbst sind ĂŒber ein anderes Netzwerk miteinander und mit dem Master verbunden. Damit eine in Kubernetes bereitgestellte Anwendung von außerhalb des Clusters erreichbar ist, muss ein Ingress bereitgestellt werden, der als Tor außerhalb des Clusters fungiert. Innerhalb des Clusters ist es fĂŒr jeden Pod immer möglich, sich mit einem anderen Pod zu verbinden. Das liegt daran, dass Kubernetes sein eigenes Netzwerk erzeugt, in dem alle Deployments stattfinden. Jeder Pod innerhalb von Kubernetes erhĂ€lt eine eigene IP-Adresse.

Wie die Vernetzung innerhalb von Kubernetes funktioniert, hÀngt stark davon ab, welche Netzwerk-Plugins und welcher Ingress-Controller installiert ist. Dadurch wird sichergestellt, dass die Umgebung innerhalb von Kubernetes auf die Anforderungen der Anwendung zugeschnitten werden kann.

EKS ist in der Lage, je nach installiertem Ingress-Controller verschiedene Arten von Loadbalancern zu spawnen. Hier empfiehlt es sich, einen externen DNS-Dienst zu verwenden und damit sicherzustellen, dass mindestens ein Pod immer ĂŒber diesen DNS-Namen erreicht werden kann, um maximal ausfallsicher zu sein.

Spinnaker

FĂŒr die Bereitstellungsebene wird in diesem Konzept Spinnaker verwendet. Spinnaker ist eine Deployment-Software, die fĂŒr Massen- und standardisierte Deployments von containerisierten Anwendungen in Kubernetes entwickelt wurde.

Hier ist es möglich, verschiedene Input-Quellen zu definieren, Pipelines zu erstellen, um Deployments zu automatisieren und Regeln/ Checks fĂŒr Pipelines zu definieren, um die IntegritĂ€t der gesamten Umgebung zu erhöhen.

Es ist auch möglich und empfehlenswert, in dieser Phase Deployment-Fallbacks zu implementieren, wie z. B. ein Blue-Green-Deployment und Versionierung fĂŒr Anwendungs-Deployments. Hier ist eine kleine Skizze, um zu sehen, wie Spinnaker Anwendungen bereitstellt:

Spinnaker, Kubernetes und Projektmanagement

Spinnaker kann natĂŒrlich weit mehr als nur Pipelines und Deployments erstellen. Es kommt auch mit einer einfach zu bedienenden Web-UI, um Ihnen einen transparenten Überblick ĂŒber die verschiedenen Deployments und Projekte in Kubernetes zu geben. Mit ein paar Klicks können Sie diese Ă€ndern.

Vorteile von Spinnaker:

  • Standardisiert.
  • Zukunftssicher.
  • Schnelle Deployments.
  • Schnelles Rollback.
  • Hoher Deployment-Durchsatz.
  • Sehr hoher Automatismus.
  • Geringer administrativer Aufwand nach der Implementierung.
  • Nahtloser Wechsel zu neuen Deployment-Workflows.
  • Cloud-Provider-Wechsel möglich.

Nachteile von Spinnaker:

  • Deployment-Workflow muss gut durchdacht sein.
  • Hoher initialer Administrationsaufwand.
  • Mehrere neue Anwendungen und Logikschichten mĂŒssen vom Betrieb verstanden und gelernt werden.
  • Funktioniert nur mit containerisierten Umgebungen.

← ZurĂŒck zu Teil 2: Deployment

Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes

Deployment von Atlassian Software mit AWS und Spinnaker – Teil 2 Bereitstellung

Wie in Teil 1 beschrieben bietet die Bereitstellung / Deployment von Atlassian Software mit AWS und Spinnaker einige essenzielle Vorteile.

Bereitstellung auf Basis von YAML Dateien

Deployments werden in mit YAML-Dateien durchgefĂŒhrt, in denen die Konfiguration von Anwendungen, Diensten und mehr fĂŒr Kubernetes festgelegt wird. Diese sollte weiterhin zum einen einen Namen, eine Definition dessen, was man bereitstellen möchte, und zum anderen die Anzahl der Replikate enthalten. Wenn wir zum Beispiel eine Fail-Save-Anwendung auf Kubernetes deployen wollen, wĂŒrden wir 2 Komponenten einsetzen.

Bereitstellung / Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes

1. Die Anwendung

ZunĂ€chst die Anwendung selbst. Da wir sie ausfallsicher machen wollen, wĂŒrden wir sie in Form eines “ Replica-Sets“ mit 3 Replikaten bereitstellen. Kubernetes beginnt dann mit dem Deployment von 3 Pods mit der beschriebenen Anwendung und verteilt diese auf die Compute Nodes. Dies geschieht anhand von HardwarebeschrĂ€nkungen und Tags.

2. Der Service

Die zweite Komponente ist ein „Service“. Man kann ihn sich wie einen Loadbalancer innerhalb des Clusters vorstellen. Zudem sorgt dieser Dienst nun fĂŒr den Lastausgleich auf allen unseren drei Pods. Dies geschieht auf der Grundlage bestimmter Tags, die wir in der Deployment-Yaml angegeben haben. Je nach Service-Typ kann EKS einen AWS Loadbalancer mit einem öffentlichen Domain-Namen erzeugen. Dadurch können wir ohne manuelle Netzwerkanpassungen auf unsere Anwendung zugreifen. Weiterhin ist es auch möglich, Ingress-Controller bereitzustellen und unsere Anwendung mit anderen Tools erreichbar zu machen.

Verwendung von Spinnaker

Jeder, der Zugriff auf den Cluster hat, kann nun Anwendungen manuell bereitstellen. Daher entwickeln wir eine Methode, um alle Deployments fĂŒr jeden, der damit arbeitet, transparent zu machen und Deployments ĂŒber einen standardisierten und zuverlĂ€ssigen Weg zu kanalisieren.

Hier kommen Spinnaker und seine Pipelines ins Spiel. Diese geben uns einen Überblick ĂŒber die im Cluster laufenden Anwendungen. Außerdem können wir so einfach weitergehende Informationen ĂŒber Bereitstellungen wie Deployment-Versionen, Pipeline-LĂ€ufe oder den Status des Loadbalancers erhalten. Spinnaker selbst wird in den Cluster bereitgestellt. Dadurch profitiert Spinnaker von der gleichen Ausfallsicherheit, die Kubernetes fĂŒr alle Anwendungen unter dessen Kontrolle bietet.

DevOps hilft ihrem Unternehmen dabei noch effzienter und effektiver Software Lösungen auszuliefern und Ihre Kunden durch konstante Updates von sich zu ĂŒberzeugen. Mehr ĂŒber DevOps erfahren.

Infrastruktur aus Microservices

Die Idee ist hier, eine Infrastruktur zu haben, die aus containerisierten Microservices besteht. Jeder Microservice/Applikation wird aus einem dedizierten Repository gebaut und nachdem Änderungen vorgenommen wurden, wird die Applikation gebaut, die dann fĂŒr den Build eines neuen Docker-Images verwendet wird. Dieses Image wird in eine private Docker-Registry gepusht.

Spinnaker Pipeline

Dies löst eine Spinnaker-Pipeline aus, die nun den geĂ€nderten Container mit der bereitgestellten Konfiguration als neue Version in den Cluster einspielt und den Service Loadbalancer so Ă€ndert, dass er den Datenverkehr nur auf die neu deployte Version leitet. Wenn diese Version die eingebauten PrĂŒfungen nicht besteht, wird die Änderung rĂŒckgĂ€ngig gemacht und die alte Version wieder ĂŒber den Service Loadbalancer aktiv gesetzt.

Idealerweise stellt die Spinnakers-Pipeline alle Container zunĂ€chst in einer Dev/Stage-Umgebung bereit, um auf Fehler zu prĂŒfen, bevor die Änderungen in der Master/Production-Umgebung bereitgestellt werden. Ein fehlgeschlagenes Update kann dadurch automatisch und auch manuell ĂŒber die Spinnaker-Web-UI rĂŒckgĂ€ngig gemacht werden.

Sie möchten mehr ĂŒber Atlassian Hosting auf AWS erfahren? Hier gehts zu unseren Cloud Hosting Services

Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes

Deployment von Atlassian Software mit AWS und Spinnaker – Teil 1 Infrastruktur

Die Bereitstellung bzw. Deployment von Atlassian Software kann mit etlichen Tools erfolgen. Hier eignen sich gerade AWS in Kombination mit Kubernetes und Spinnaker eignen sich dafĂŒr hervorragend. Im ersten Teil dieser Reihe konzentrieren wir uns auf die Infrastruktur bei der Bereitstellung von Atlassian Software mit AWS.

Durch die Kombination der Vorteile der ZuverlĂ€ssigkeit und Skalierbarkeit von Kubernetes mit dem Bereitstellungsautomatismus und der Anwendungsverwaltung von Spinnaker erhalten wir eine Umgebung, in der wir verschiedene Arten von Anwendungen frei bereitstellen können. Ohne sich Gedanken darĂŒber machen zu mĂŒssen, wie und wo sie in der Infrastruktur bereitgestellt werden.

Diese Deployment-Lösung definiert Ebenen fĂŒr Entwicklung und Betrieb und Verantwortlichkeiten getrennt. Auf diese Weise weiß jeder ĂŒber die umgebenden Anwendungen und den Bereitstellungsablauf Bescheid. Dadurch kann man sich anschließend auf die Aufgaben in der vorgesehenen Ebene konzentrieren.

Hier ist ein Beispiel fĂŒr diesen Bereitstellungsworkflow:

Bereitstellung / Deployment von Atlassian Software mit AWS und Spinnaker - Workflow und Infrastruktur

In dieser Grafik sehen wir vier Infrastruktur Ebenen der Bereitstellung: Code Repository, Container Registry, Deployment und Infrastructure. Wenn ein Entwickler eine Anwendung bereitstellen oder eine neue Umgebung fĂŒr sein Projekt erstellen muss, sollte er dafĂŒr nicht in den Deployment- oder Infrastructure-Layer gehen mĂŒssen. So sollten vielmehr Operations-Teil Schnittstellen in Form von Code-Repositories bereitstellen, die es einem Entwickler ermöglichen, in seiner Umgebung zu arbeiten. Dadurch wird Operations wird als Administrator fĂŒr die tieferen Deployment-Schichten, Layout-Regeln und die Prozessautomatisierung mit den Deployment-Tools und Pipelines seiner Wahl fungieren. Entwicklung und Operations sollten dennoch den gesamten Deployment-Workflow kennen und Zugriff auf alle Tools haben.

Automatismen auf jeder Ebene

Die Automatismen erstrecken sich ĂŒber alle Ebenen der Infrastruktur. So entsteht eine gepflegte und sorgfĂ€ltig geplante Pipeline, um Anwendungen sicher zu bauen, zu testen und bereitzustellen. Dadurch sind bei jedem Deployment Entwicklung und Betrieb in der Lage, alles, was live passiert, mitzuverfolgen und können ĂŒber Monitoring, Logging und Feedback-Schleifen auch auf aggregierte Informationen zugreifen.

Container fĂŒr alle Anwendungen

Damit dieses ganze Konzept funktioniert, mĂŒssen alle Anwendungen containerisiert werden. Die Idee hinter diesem Konzept ist es, das Deployment von Anwendungen so weit wie möglich zu standardisieren und zu automatisieren, um die Entwicklung und die Veröffentlichung neuer Funktionen zu beschleunigen. Anschließend wird Schritt fĂŒr Schritt der Prozess aufgebaut um Anwendungen nach und nach zu integrieren und um alte Legacy-Installationen zu ersetzen.

Infrastruktur

Kubernetes bietet eine große FlexibilitĂ€t und eine wachsende Anzahl von Möglichkeiten bei der Integration. Dazu gehören mehrere Cloud-Provider, Standorte und Vielfalt von Compute-Nodes, sowie die interne Vernetzung. Daher kann das Big-Picture der Infrastruktur je nach Funktionsanforderungen und AnwendungsfĂ€llen von der unten stehenden Grafik abweichen.

Deployment von Atlassian Software mit Spinnaker, AWS und Kubernetes - Infrastruktur in AWS

Elastic Kubernetes Service (EKS) von AWS

In diesem Beispiel entscheiden wir uns fĂŒr EKS als Managed Service von AWS, aber auch andere verwaltete oder sogar selbst gehostete Kubernetes-Systeme könnten eine valide Option sein.
Da sich Kubernetes nicht um die Hardwarekonfiguration und -verteilung der zu einem Cluster hinzugefĂŒgten Compute-Nodes kĂŒmmert, können wir eine Vielzahl von AnwendungsfĂ€llen mit unterschiedlichen Anforderungen abdecken. Wir wĂŒrden empfehlen, einen Instanztyp zu wĂ€hlen, mit dem Sie sich wohlfĂŒhlen und der eine stetige Skalierbarkeit fĂŒr Ihre Anwendungen ermöglicht. Die GrĂ¶ĂŸe dieses Instanztyps kann je nach der Anwendung, die Sie einsetzen möchten, unterschiedlich sein. Ein Compute-Node sollte in der Lage sein, mehrere Instanzen der Anwendung, die Sie bereitstellen möchten, zu halten.

Skalierung von Clustern

Um eine horizontale Skalierung des Clusters innerhalb der Infrastruktur zu ermöglichen, haben wir AWS Auto Scaling Groups (spĂ€ter als ASG bezeichnet) verwendet, die in der Lage ist, neue Instanzen zu spawnen und sie automatisch zum Cluster hinzuzufĂŒgen, wenn eine bestimmte Last erreicht wird. Je nach Anwendung können Sie auch hier Trigger implementieren, die auf der gesamten RAM- und/oder CPU-Auslastung aller Compute Nodes basieren und die aktuell Teil des Clusters sind. Auf diese Weise stellen Sie sicher, dass der Cluster immer genĂŒgend Ressourcen fĂŒr die Deployments hat. Außerdem sollten Sie nicht vergessen, einen Trigger hinzuzufĂŒgen, um den Cluster wieder herunterzuskalieren, wenn die Gesamtlast der Compute Nodes wieder sinkt. Auf diese Weise können Sie Lastverschiebungen und -spitzen sicher und kosteneffizient bewĂ€ltigen.

Nutzung von Kubernetes Tags

Da Kubernetes viel mit Tags arbeitet und Deployments auf Basis von Compute-Node-Tags verteilen kann. Mit mehreren ASGs lassen sich unterschiedliche Instanztypen, Konfigurationen und Tags einrichten und hochskalieren. Kubernetes kann dann Projekte oder Anwendungen auf Hosts mit bestimmten Tags deployen.
ErwĂ€hnenswert ist auch, dass die Compute Nodes nicht in der gleichen Cloud wie der Master existieren mĂŒssen. Vielmehr ist es möglich, Nodes aus verschiedenen Clouds und sogar On-Premises-Hardware zu kombinieren. DafĂŒr ist es erforderlich, mehr Arbeit in die gesamte Cluster-Netzwerkkonfiguration zu investieren

Weiter zu Teil 2: Deployment →

Atlassian Cloud vs Data Center AWS vs Azure

Atlassian Hosting: Atlassian Cloud vs. Data Center auf AWS oder Azure

Die Cloud ist allgegenwĂ€rtig und tagtĂ€glich werden neue Apps veröffentlicht, die direkt und on-demand und nativ im Web genutzt werden können. Doch nicht immer ist das von Unternehmen auch gewĂŒnscht. Oft gibt es Sicherheitsbedenken seitens IT-Administratoren oder fehlende FlexibilitĂ€t von Apps in der Cloud. Auch Atlassian hat sich dazu entschlossen seine beiden beliebten Apps, Jira, Confluence, Bitbucket und Co in die Cloud zu migrieren. Dadurch werden beide Apps nach wie vor auch als Data Center Variante angeboten. So stellt sich die Frage, welche Lösung ist die beste fĂŒr dein Unternehmen: Atlassian Cloud oder Hosting auf AWS oder Azure?

Atlassian Software Stack auf AWS oder Azure

Cloud Lösungen auf AWS erfreuen sich vor allem im Enterprise Bereich grĂ¶ĂŸter Beliebtheit. Das liegt nicht nur daran, dass du mit AWS deine Cloud nach Belieben Skalieren kannst und dadurch flexibel aufgestellt bist. Sondern auch aufgrund von Faktoren wie Performance und VerfĂŒgbarkeit. Weiterhin hast du auf AWS oder Azure die Möglichkeit neben den Atlassian Software Produkten auch deine eigenen Apps zu hosten. 

Vorteile Atlassian Hosting auf AWS oder Azure

Skalierbarkeit und FlexibilitÀt

Ähnlich wie die native Atlassian Cloud wĂ€chst auch Data Center Lösungen von Atlassian mit deinem Unternehmen mit. Jedoch gibt es hier einige Vorteile zu beachten:

  • Horizontale Skalierbarkeit durch zuschalten weiterer Hardware oder Upgrades durch AWS / Azure
  • Kein User Limit: Selbst 5.000 oder 10.000 und mehr sind mit Data Center auf AWS oder Azure möglich
  • Keine Ausfallzeiten: Upgrades passieren im Hintergrund und fĂŒhrt zu keinen Ausfallzeiten deiner Atlassian Software Instanzen.

Sicherheit mit Hosting auf AWS oder Azure

IT-Sicherheit wird durch zusĂ€tzliche Maßnahmen durch deinen Hosting Partner und deiner IT-Abteilung gewĂ€hrleistet. Dazu gehören:

  • Sichere Authentifizierungsprotokolle und fortgeschrittene Auditierung.
  • Integration von SAML-SSO 2.0: Sichere deine WebzugĂ€nge zusĂ€tzlich ab.
  • AWS / Azure Sicherheitsvorkehrungen: Weitere VerschlĂŒsselungsebenen wie zum Beispiel fĂŒr den gesamten regionsĂŒbergreifenden VPC Peering Traffic und Customer- oder Service-to-Service TLS-Verbindungen
  • VollstĂ€ndiger Admin und Datenbankzugang
  • Standortauswahl der Rechenzentren: Stelle sicher, dass deine Daten in deiner bevorzugten Region abgespeichert werden.

ZuverlÀssigkeit und StabilitÀt

  • Der Zugriff auf deine Systeme ist durch den Betrieb von örtlich getrennten Rechenzentrums bei einem Server-Ausfall gewĂ€hrleistet.
  • Systemzugriff auch bei Server-Ausfall: Örtlich getrennte Rechenzentren bieten eine erweiterte ZuverlĂ€ssigkeit bei Server-AusfĂ€llen
  • Integrierte Desaster Recovery: Stelle deine Systeme unkompliziert wieder her und minimiere Downtimes

Infrastruktur und Betrieb

  • Custom Domain Name (DNS): Verbinde deine eigene Webdomain mit deinen Atlassian Softwarelösungen.
  • Auslagerung des Betriebs: Wende dich an einen externen Partner zum Management und Wartung deiner Hosting Infrastruktur

Integration und Plugins

  • Hohe VerfĂŒgbarkeit der Plugins: Die meisten Atlassian Marketplace Partner stellen ihre Plugins bereits zur VerfĂŒgung gestellt (ca. 3.000).
  • Atlassian API: Entwicklung von Anwendungen, Anpassungen und Integrationen möglich.

FĂŒr wen ist Data Center Hosting geeignet?

Jira oder Confluence Data Center auf AWS oder Azure eignet sich vor allem fĂŒr grĂ¶ĂŸere Teams die 500 User oder mehr und FlexibilitĂ€t Ihrer Infrastruktur benötigen. Aufgrund der Vielzahl der verfĂŒgbaren Apps mĂŒssen zusĂ€tzlich mit wenigen Einschnitten bei der Erweiterung der Instanzen gerechnet werden. ZusĂ€tzlich ist Data Center fĂŒr Unternehmen geeignet, die einen zusĂ€tzlichen Layer an Sicherheit benötigen und volle Kontrolle ĂŒber ihre Infrastruktur haben möchten.

Managed Atlassian Hosting

Reduzieren Sie die BetriebskomplexitÀt und vereinfachen Sie den Betrieb Ihrer Atlassian-Produkte wie Confluence, Bitbucket und Jira.

Lizenzmanagement

Nachteile von Atlassian auf AWS oder Azure

Trotz einiger Vorteile hat die Atlassian Data Center auf AWS auch mit einigen Nachteilen zu kÀmpfen:

  • Hohe Kosten fĂŒr den Betrieb und Aufbau der Serverinfrastruktur.
  • V.a. fĂŒr kleinere Teams ungeeignet und fĂŒhrt schnell zu hohen Kosten durch ein höheres User-Tier.
  • Betriebskosten steigen aufgrund der Bereitstellung mehrerer Infrastrukturkomponenten.
  • Erhöhter Verwaltungsaufwand durch aufwĂ€ndigere Infrastruktur.
  • Noch nicht alle Apps der Marketplace-Anbieter sind schon fĂŒr Data Center verfĂŒgbar.

Hosting auf Atlassian Cloud – Jira und Confluence 

Weiterhin Jira und Confluence sind direkt bei Atlassian als SaaS (Software as a Service) verfĂŒgbar und werden direkt bei Atlassian gehostet. Dadurch kann ein jedes Unternehmen schnell und ohne Umwege in deinem Unternehmen integriert werden. Solltest du bisher eine Server Data Center Lizenz nutzen, bietet Atlassian zusĂ€tzlich kostenfreies Tools zur Migration deiner Jira oder Confluence Daten in die Atlassian Cloud an.

Jira und Confluence gehostet bei Atlassian ist fĂŒr kleine Teams bei bis zu 10 User kostenlos verfĂŒgbar und bietet bereits einen ausreichenden Funktionsumfang. 

Vorteile der Atlassian Cloud

Skalierbarkeit: Jira und Confluence wachsen mit deinem Unternehmen mit

Ein großer Vorteil der Atlassian Cloud ist, dass beide Apps mit deinem Unternehmen mitwachsen. Das heißt, je nachdem wie viele User du fĂŒr die Software benötigst, desto kostenintensiver wird es. Jedoch kannst du dadurch genau deine Kosten im Auge behalten und jederzeit auf Änderungen in deinem Unternehmen reagieren. ZusĂ€tzlich gibt es derzeit ein User Limit von 1000.

Sicherheit der Atlassian Cloud

Wie bereits angesprochen ist ein kritischer Faktor die Sicherheit von Cloud Lösungen. Schließlich sollen sensiblen Unternehmensdaten nur von deinen Mitarbeitern eingesehen werden können. Die Atlassian Cloud bietet aus diesem Grund einige Sicherheitsvorkehrungen:

  • Erstelle Berechtigungen fĂŒr deine User: Nutze die integrierte Rollenfunktion um Zugriffsberechtigungen zu kontrollieren.
  • SSL, SSO: Die Cloud ist mittels TLS bzw. SSL abgesichert und verschlĂŒsselt und kann durch eine Anbindung an einen SAML-Single-Sign-On Provider zusĂ€tzlich abgesichert werden.
  • Standortauswahl des Servers: Um GDPR und DSGVO KonformitĂ€t zu erreichen und den exakten Standort deiner Daten zu kennen, ist es möglich den Ort des Servers zu wĂ€hlen. 
  • Passwortrichtlinien: Lege fest, welche Voraussetzungen die Passwörter deiner User haben mĂŒssen.

ZuverlÀssigkeit und StabilitÀt

Ihr Team benötigt in der Atlassian Software in der Cloud störungsfreien Zugriff auf Ihre Instanzen.

  • VerfĂŒgbarkeit der Cloud: Je nach Ausbaustufe ist eine VerfĂŒgbarkeit von bis zu 99,5% zu erreichen.
  • Updates: Alle Updates werden automatisch eingespielt, sobald sie verfĂŒgbar sind. So entstehen keine Downtimes
  • Desaster Recovery: Es werden alle 24 Stunden Backups erstellt und 7 Tage aufbewahrt, um auch auf das schlimmste vorbereitet zu sein.
  • Sichere Wiederherstellungsverfahren: Sollte dennoch mal etwas schiefgehen, gibt es kontrollierte Möglichkeiten zu Datenrettung

Infrastruktur und Betrieb

  • Geringer Aufwand und Betriebskosten durch die Verwaltung der Cloud durch Atlassian
  • FunktionalitĂ€t ist immer up to date. Du erhĂ€ltst immer die neuesten Funktionen und musst keine eigenstĂ€ndigen Updates ausfĂŒhren.

Integrationen und Plugins

Die Atlassian Cloud wird stĂ€ndig ausgebaut. Und so auch die VerfĂŒgbarkeit von Marketplace Apps.

  • Derzeit sind ca. 1000 Apps in der Cloud verfĂŒgbar und es werden tĂ€glich mehr. 
  • Noch nicht alle Apps von bekannten Anbietern sind in der Cloud verfĂŒgbar.

Berechne deine Kosten fĂŒr die Atlassian Cloud

Finde heraus welche Kosten auf die und den Unternehmen zukommen, wenn du in die Atlassian wechselst.

Atlassian Cloud Cost Calculator

Nachteile der Atlassian Cloud

Trotz unschlagbarer Vorteile sind bei der Nutzung der Atlassian Cloud einige Faktoren zu berĂŒcksichtigen die fĂŒr Unternehmen eine Herausforderung darstellen können.

  • Anzahl der User: Ohne Enterprise-Lösung ist die Anzahl der User auf 1000 begrenzt. So kann die Cloud vor allem fĂŒr große Unternehmen keine Option darstellen.
  • EingeschrĂ€nkter Admin Zugang: Mit der Atlassian Cloud hat Ihre IT-Abteilung keinen direkten Zugang auf die Datenbank.
  • Atlassian Cloud gebunden: Ihnen steht keine Auswahl des Cloud-Anbieters zur VerfĂŒgung.
  • Plugins und Integrationen: Derzeit ist nur eine begrenzte Anzahl von Apps im Marketplace verfĂŒgbar.

FĂŒr wen ist die Atlassian Cloud geeignet?

Die Atlassian Cloud ist in erster Linie fĂŒr kleinere Teams oder Startups geeignet, die die nötige FlexibilitĂ€t fĂŒr ihre Jira oder Confluence Instanzen und ein on-demand System direkt zur VerfĂŒgung haben möchten. 

In jedem Fall gilt, dass du fĂŒr die Migration in die Cloud (Data Center oder Atlassian Cloud) einen starken Partner an deiner Seite hast, der dich bei allen relevanten Fragen zu Anforderungen und Problemstellungen berĂ€t.

Du benötigst einen starken Partner an deiner Seite und dich bei allen Fragen zur Migration in die Cloud unterstĂŒtzt? Hier findest du weitere Informationen zur Migration in die Cloud und wie ein Wechsel von Server auf Data Center genau aussieht.

Datensicherheit in der Atlassian Cloud

Datensicherheit in der Atlassian Cloud

Ein essenzieller Vorteil einer eigenen Umgebung und der Nutzung von Servern liegt darin, dass du immer darĂŒber Bescheid weißt, was mit deinen Daten passiert und wo sie gespeichert sind. Datensicherheit in der Atlassian Cloud ist fĂŒr viele Unternehmen einer der Kernfaktoren, wenn es darum geht eine Migration in die Cloud in ErwĂ€gung zu ziehen.

Da Atlassian nun allerdings in seiner Cloud Roadmap mitgeteilt hat, dass Server Produkte nur noch bis Anfang 2024 unterstĂŒtzt werden. Stellen sich viele Unternehmen die Frage, welche Optionen Sie jetzt haben. Zum einen hast du und dein Unternehmen die Wahl nativ in die Cloud von Atlassian zu migrieren. Oder Atlassian Produkte wie Jira oder Confluence ĂŒber ein Data Center (AWS, Azure, on-premises) zu hosten. In jedem Fall verwendest du eine Cloud Lösung und ziehst daraus einige Vorteile.

Du möchtest mehr darĂŒber erfahren, welche Vorteile ein Wechsel in die Cloud mit sich bringt? Unser Artikel ‘5 GrĂŒnde fĂŒr einen Wechsel in die Cloud’ geht darauf nĂ€her ein.

Garantierte Datensicherheit in der Atlassian Cloud?

Je nachdem fĂŒr welches System bzw. “Cloud Art” du dich letztendlich entscheidest, deine Daten sollen in jedem Fall sicher sein und nach Datenschutzrichtlinien wie DSGVO oder GDPR abgesichert werden. 

Sichere Daten in der Cloud?

Ein global agierendes Unternehmen wie Atlassian muss sich natĂŒrlich auch den Datenschutzrichtlinien der EU bzw. Deutschland beugen. Das bedeutet, wenn Produkte wie Jira oder Confluence im hiesigen Markt angeboten werden, mĂŒssen alle Richtlinien befolgt werden.

Atlassian gibt an, dass Sie unter erheblichen Aufwand, “Kunden bei der ErfĂŒllung DSGVO-relevanter Anforderungen und lokaler Gesetze [zu] unterstĂŒtzen.” (Mehr zum Atlassian Datenschutz). Neben der DSGVO und GDPR KonformitĂ€t hat Atlassian weitere Sicherheitsvorkehrungen etabliert um den Zugang zu der Cloud weiter abzusichern. 

Im Folgenden haben wir die wichtigsten Vorkehrungen zur Datensicherheit in der Cloud fĂŒr dich zusammengefasst:

  • DSGVO: Der interne Umgang mit sensiblen Kundendaten ist DSGVO-konform. Es werden Tools bereitgestellt, um den rechtlichen Verpflichtungen und lokalen Gesetzen nachzukommen.
  • Datenklassifizierung: Interne Kontrolle fĂŒr ZugriffsbeschrĂ€nkungen auf Kundendaten.
  • ISO 27001 Zertifizierung: Informationssicherheitsmanagementsystem.
  • ISO 27018 Zertifizierung: Datenschutz in der Cloud.
  • VerschlĂŒsselung ruhender Daten: Alle deiner Daten werden vollstĂ€ndig in der Cloud verschlĂŒsselt.
  • Verpflichtende Zwei-Faktor-Authentifizierung: Möglichkeit eine Zwei-Faktor-Authentifizierung zu aktivieren.
  • Mehrere Authentifizierungsrichtlinien pro DomĂ€ne: Konfigurieren Sie unterschiedliche Authentifizierungsanforderungen; z.B. SSO, Zwei-Faktor-Authentifizierung, Passwortrichtlinie)

Weitere Informationen zu Sicherheit in der Cloud und Vorkehrungen von Atlassian finden Sie hier.

5 GrĂŒnde fĂŒr einen Wechsel in die Cloud

Wo werden deine Daten gespeichert?

Atlassian Cloud (Nativ)

Bei der Nutzung der nativen Cloud, d.h. Cloud hostet von Atlassian gibt es derzeit noch keine Möglichkeit fĂŒr die Stufen, Standard und Premium einen bestimmten Ort zu wĂ€hlen, an dem deine Daten gespeichert werden. Das heißt, trotz DSGVO- und GDPR-KonformitĂ€t kann nicht sichergestellt werden, dass die Daten deines Unternehmens auch in Deutschland gespeichert werden. 

Weiterhin wird angegeben, dass Daten so gesichert werden, dass die Latenz minimiert wird. FĂŒr Unternehmen in Deutschland gilt somit logischerweise (jedoch nicht garantiert), dass deine Daten in Frankfurt oder Dublin abgelegt werden.

FĂŒr Enterprise Kunden bietet Atlassian die Option an, Daten einem “Realm” zuzuweisen. Das heißt, wenn dein Unternehmen in Deutschland ansĂ€ssig ist, kannst du deine Daten an das Realm Frankfurt oder Dublin pinnen. 

Weitere Informationen dazu findest du hier.

Confluence und Jira in Data Center

Neben der nativen Cloud Umgebung gibt es weiterhin die Möglichkeit, das Atlassian Data Center zu nutzen und die Produkte mithilfe eines Cloud Solution Providers wie AWS oder Azure zu hosten. Dadurch wird es dir ermöglicht, den Ort an dem deine Daten gespeichert werden selbst zu bestimmen und somit DSGVO-konform zu sein. 

Weiterhin bieten Atlassian Data Center Produkte Ă€hnliche Sicherheitsvorkehrungen zum Schutz deiner sensiblen Unternehmensdaten und zusĂ€tzlich die Möglichkeit, Confluence und Jira nach deinen BedĂŒrfnissen individuell anzupassen.

Zusammenfassung: Datensicherheit in der Cloud

Je nachdem welche Sicherheitsfaktoren fĂŒr dich und dein Unternehmen am Ende am wichtigsten sind, hast du zwei Möglichkeiten wie du in die Cloud migrieren kannst. Beide bieten Ă€hnliche Optionen deine Daten zu schĂŒtzen. Sollte der Faktor Speicherort fĂŒr dich wichtig sein. Und du gerne zu 100 % sicherstellen möchtest, dass deine Unternehmensdaten in Deutschland gespeichert werden sollen, dann ist eine Data Center Lösung fĂŒr dich die bessere Wahl.

Du benötigst UnterstĂŒtzung bei der Migration in die Cloud oder möchtest eine erste Beratung zu deinen Möglichkeiten? Auf unserer Cloud Services Seite findest du weitere Informationen zum Thema. Gerne beraten wir dich auch in einem ersten persönlichen GesprĂ€ch.

Cloud Migration

5 GrĂŒnde warum du in die Cloud wechseln solltest

Der Wechsel in die Cloud ist nicht mehr aufzuhalten. Ende 2020 finden schĂ€tzungsweise bereits 83% aller Workloads der weltweiten Unternehmen in der Cloud statt. Und es wird davon ausgegangen, dass sich dies in den kommenden Jahren noch weiter verstĂ€rken wird. 

Anfang 2020 wurde dieser Effekt aufgrund der COVID-19-Pandemie verstĂ€rkt. Unternehmen wurden teilweise von jetzt auf gleich dazu gezwungen Ihren Mitarbeitern die Möglichkeit zu geben, Remote arbeiten zu können. So mussten Unternehmensdaten, Workflows und Apps zu jederzeit und an jedem Ort verfĂŒgbar sein.

“9 von 10 aller neuen Atlassian Kunden bevorzugen eine Cloud-Lösung ĂŒber eine On-Premise (Server) Lösung.”

Quelle: Atlassian

Doch nicht nur die VerfĂŒgbarkeit ist ein Grund in die Cloud zu wechseln. Sicherheit, Nachhaltigkeit, AgilitĂ€t, Skalierbarkeit und Kosteneffizienz sind Faktoren, die Sie bei einer Migration in die Cloud beachten sollten. 

Lesen Sie jetzt unsere 5 GrĂŒnde in die Cloud zu wechseln.

Skalierbarkeit von (Atlassian) Cloud Lösungen

Unternehmen, Teams und Apps wachsen, und so mĂŒssen es auch Ihre IT und ServerkapazitĂ€ten. Stellen Sie sich vor, Ihr Team wĂ€chst innerhalb weniger Monate um 200 Personen, Sie verkaufen 10x so viele Ihrer Produkte oder Dienstleistungen in kĂŒrzester Zeit. Sie verbuchen das natĂŒrlich als “Win”, doch Ihre IT und Team hat dabei vermutlich stark zu kĂ€mpfen. Und so stĂ¶ĂŸt eine On-Premise Lösung schnell an seine Grenzen und verlangt nach immer schnelleren Update- und Upgrade-Zyklen. Das ist letztendlich nicht nur kostenintensiv, sondern bedeutet auch fĂŒr Ihr Team, weniger Zeit fĂŒr wichtigere Aufgaben zu haben (z.B IT-Sicherheit).

Sie benötigen also eine Technologie die je nach Bedarf automatisch skaliert. Genau hier kommen Cloud Lösungen zum Einsatz. Diese ermöglichen Ihnen und Ihrem Unternehmen auf ein flexible und anpassungsfĂ€hige Services zurĂŒckgreifen, ohne sich stĂ€ndig ĂŒber kostenintensive und manuelle Upgrades Gedanken machen zu mĂŒssen. 

Mehr Umsatz und geringere Admin-Kosten durch einen Wechsel in die Cloud

Server, Hardware und Wartung sind teuer und ein großer Kostenfaktor innerhalb Ihres Unternehmens. Ihre IT muss in regelmĂ€ĂŸigen AbstĂ€nden erneuert werden, damit Ihre WettbewerbsfĂ€higkeit gewĂ€hrleistet werden kann. Doch auch ein Wechsel in die Cloud, bedeutet, dass Kosten von Form von monatlichen und jĂ€hrlichen GebĂŒhren auftreten. Vor allem kurzfristig ist eine Migration in die Cloud kostenintensiver als Ihre bewĂ€hrte On-Premise Lösung. Langfristig durch Cloud native Abbildung ihrer Infrastruktur und Services, werden Sie erkennen, dass die Cloud die weitaus kostengĂŒnstigere Wahl darstellt. 

“GrundsĂ€tzlich kann davon ausgegangen werden, dass Sie durch eine Migration in die Cloud langfristig eine Kostenersparnis von ca. 30% haben werden.”

Laut einer Studie von Office 365

WĂ€hrend bei On-Premise Lösungen die offensichtlichen Kosten wie Hardware / Hosting Kosten und LizenzgebĂŒhren weitaus geringer sind als Abo- und Admin-Kosten, sind vor allem die versteckten Kosten bei On-Premise ein Grund langfristig Cloud-Lösungen zu verwenden. Kosten fĂŒr IT-Sicherheit, Upgrades, Performance, Wartung (und weitere) werden erst mit der Zeit sichtbar.

Mehr Performance und Geschwindigkeit durch Cloud Migration

42% von IT-Professionals geben an, dass Performance des Netzwerks einer der Top GrĂŒnde fĂŒr einen Wechsel in die Cloud darstellt. Doch nicht nur das. VerfĂŒgbarkeit und Geschwindigkeit spielen vor allem im SaaS Bereich (Software as a Service) eine Große Rolle. Seine Kunden langfristig zu binden und dafĂŒr zu sorgen, dass der User Ihren angebotenen Service unterbrechungsfrei nutzen kann, lĂ€sst sich durch eine dezentrale Lösung einfacher bereitstellen, als durch eine Lokale.

Stellen Sie sich vor, Sie benutzen eine Ihrer GoTo Apps, um Ihre Arbeit zu erledigen. Und just in diesem Moment, stĂŒrzt deren Server ab, da zur aktuellen Zeit zu viele User aktiv sind und die ServerkapazitĂ€t nicht mehr ausreicht. Sie sind dann wahrscheinlich sichtlich genervt und entscheiden sich, das Tool nicht mehr zu verwenden und der Anbieter verliert Sie als Kunden.

Eine 24/7 mit 99,95% garantierter Uptime und VerfĂŒgbarkeit ohne Performance-EinbrĂŒche kann durch eine Migration in die Cloud weitaus einfacher erreicht werden. Sollte Sie sich also in einer Situation befinden, in der Ihre Services und Apps jederzeit VerfĂŒgbar sein mĂŒssen, kann die dezentrale Cloud Ihr Risiko drastisch reduzieren.

Exklusives Whitepaper fĂŒr IT-Experten und Remote Teams

Cloud Migration: Acht Cloud Mythen unter der Lupe

Von Datensicherheit bis hin zur Systemleistung. XALT hat die gĂ€ngigsten IrrtĂŒmer zum Thema Move-to-Cloud fĂŒr Sie genauer analysiert.

Cloud migration

Verbesserung der ProduktivitÀt Ihrer Teams

Fast 80 % der IT-Profis geben an, dass die Umstellung auf die Cloud ihre ProduktivitĂ€t verbessert hat (Quelle: Office 365) und laut Stanford sind Team die Remote arbeiten und Cloud-Apps verwenden um ca. 13% produktiver als vergleichbare Teams. Doch aus welchen GrĂŒnden verbessert ein Wechsel in die Cloud die ProduktivitĂ€t Ihrer Teams?

Weniger ToDo’s auf der Agenda Ihrer IT-Teams

ToDo’s wie Wartung, Upgrades oder Updates werden sekundĂ€ren Tasks und mĂŒssen von Ihnen weniger stark ĂŒberwacht werden. Es bleibt somit mehr Zeit fĂŒr wichtigere Tasks. Ihr IT-Team kann sich dann schließlich mit Themen, wie Sicherheitsfragen, User & Access Management oder dem allgemeinen Setup Ihrer Organisation beschĂ€ftigen, welche Ihr Unternehmen weiter voranbringen und innerhalb Ihrer Organisation einen Mehrwert stiften.

“FĂŒr unsere Ingenieure ist es wichtig, sich so weit wie möglich auf die Dinge zu konzentrieren, die fĂŒr unser GeschĂ€ft einzigartig sind, und nicht auf den Betrieb einer Unmenge von Infrastruktur.”

– Mike Curtis, Airbnb VP of Engineering

Generell kann also festgehalten werden, dass dass die meisten IT-Teams einen teil ihres Arbeitsalltags mit Aufgaben beschĂ€ftigt sind, welche keinen direkten Mehrwert fĂŒr das Business liefern.

Die Cloud fördert die Zusammenarbeit Ihres Teams

Viele Unternehmen und Teams sind oft ĂŒberregional, international und ĂŒber Etagen getrennt. Da kann es schon eine große Herausforderung darstellen, ĂŒber alle laufenden Projekte und Tasks bescheid zu wissen. Durch die Migration Ihrer Workflows in die Cloud, gehört das allerdings der Vergangenheit an und fördert nicht nur die Kommunikation untereinander, sondern schafft auch Transparenz, fördert die ProduktivitĂ€t und Performance. 

Teams aus den unterschiedlichsten Fachbereichen, ganz egal ob Marketing, Entwicklung, Produktmanagement oder Engineering können gleichzeitig auf die gleichen Systeme zugreifen und sich untereinander austauschen. 

Die Cloud ist Teil der Zukunft, Sie auch?

Die Cloud ist aus dem modernen Unternehmen nicht mehr wegzudenken. Und das betrifft noch nicht mal Ihre eigene Unternehmens-Cloud. Und ĂŒberlegen sie; Ihre Teams verwenden meist ohne das Wissen Ihrer IT-Abteilung etliche Cloud basierte Apps und Tools um ihre tĂ€gliche Arbeit zu vereinfachen. Diese sog. Shadow-IT macht meist bis zu 98% aller genutzten Apps aus. 

Die Frage, die Sie sich also stellen sollten ist, sind Sie und Ihr Unternehmen es auch? Werden Sie also ein Teil der Zukunft und setzen Sie bereits Heute auf Cloud-Basierte System um nicht wettbewerbsfĂ€hig zu bleiben, sondern auch um Kosten zu sparen, die ProduktivitĂ€t Ihres Team steigern und Ihren Mitarbeitern ihren tĂ€gliche Arbeit und Workflows zu vereinfachen. Weiterhin ermöglicht Ihnen die Migration Ihres Unternehmens in die (Atlassian) Cloud auch, dass Sie aus einem weitaus grĂ¶ĂŸerem Pool aus Talenten fischen können, welche vielleicht nicht direkt bei Ihnen lokal ansĂ€ssig sind, aber bereit dazu sind Remote Teil Ihres Teams zu werden. 

Die Vorteile einer Cloud liegen somit nicht nur in der IT, sondern betreffen Ihr gesamtes Unternehmen. Sie möchten noch mehr ĂŒber die Chancen einer Migration Ihres Unternehmens in die Cloud erfahren? Laden Sie unser Whitepaper: 5 GrĂŒnde fĂŒr einen Wechsel in die Cloud herunter.

Exklusives Whitepaper fĂŒr IT-Experten und Remote Teams

Cloud Migration: Acht Cloud Mythen unter der Lupe

Von Datensicherheit bis hin zur Systemleistung. XALT hat die gĂ€ngigsten IrrtĂŒmer zum Thema Move-to-Cloud fĂŒr Sie genauer analysiert.

Cloud migration