Jira Projekte Synchronisieren

Jira Projekte zwischen mehreren Jira Instanzen synchronisieren

Jira Projekte und Tickets zu synchronisieren bietet eine einfache Möglichkeit mit externen Partner an Projekten zusammenzuarbeiten oder mehrere interne Jira Instanzen miteinander zu verknĂŒpfen.

Warum Jira Projekte, Tickets und Issues synchronisieren?

Jira ist ohne Zweifel eines der besten Projektmanagementtools fĂŒr agile Softwareentwicklung und darĂŒber hinaus. Es wird weltweit von unzĂ€hligen Unternehmen und Teams fĂŒr die Kollaboration bei rĂ€umlicher Distanz verwendet. Und ermöglicht so ein prozessorientiertes Arbeiten digitalisiert. Der große Vorteil ist, dass es hervorragende Konfigurationsmöglichkeiten bietet und es sich oftmals mit geringem Aufwand individuell an die BedĂŒrfnisse verschiedenster Abteilungen und Teams anpassen lĂ€sst.

UnternehmensĂŒbergreifende Zusammenarbeit von Entwickler-Teams

In vielen Branchen werden externe Teams, Dienstleister oder Freelancer zur UnterstĂŒtzung bei der Abwicklung von Projekten ins Boot geholt. Sei es aus GrĂŒnden von zusĂ€tzlicher Expertise oder aufgrund eines ganz speziellen Skills. Stell dir vor, du und dein Team arbeiten zusammen mit externen Dienstleistern an einem grĂ¶ĂŸeren Projekt in Jira. Sei es in der Softwareentwicklung, im Marketing oder der Digitalisierung von Unternehmensprozessen. Die “Externen” benötigen allerdings meist Zugang zu deinen internen Systemen und deiner Instanz. Dies kann allerdings aufgrund von Compliance oder Sicherheitsbedenken nicht ohne weiteres Umgesetzt werden. ZusĂ€tzlich arbeiten verschiedene Teams oftmals in ihren eigenen Systemen, eigenen Workflows und Methoden. Und ĂŒbertragen dann die Tickets oder Issues in das Hauptsystem. Dadurch können schließlich gravierende Probleme in der Kommunikation und dem Projektfortschritt entstehen. Bei der Übertagung der Informationen gehen so wichtige Daten verlorenen oder Updates werden vergessen.

Zusammenarbeit von Softwareentwicklung und Support Teams

In der Software Branche ist die Entwicklung neuer Features  und die damit verbundene Wartung des Produkts meist eng miteinander verbunden. Service Teams betreuen jedoch meist mehrere Apps innerhalb ihrer Jira Service Management Instanz. Weiterhin arbeiten diese dann meist mit verschiedenen Entwicklungsteams in einer Jira Software Instanz zusammen. Anfragen, die z.b. als Service Request oder Incidents vom Service Team im Jira Service Management angenommen werden, mĂŒssen analysiert und fĂŒr den bevorstehenden Entwicklungsprozess fĂŒr die jeweiligen Entwicklerteams in der Jira Software Instanz aufbereitet werden. 

Deshalb ist es notwendig, den Entwicklungsprozess mit dem Customer Support Prozess auch in technischer Hinsicht zu verflechten. So ist die Zusammenarbeit von Entwicklung und Kundenservice zu vereinfachen und den gemeinsamen Workflow effizienter zu gestalten. 

Ein Szenario:

  • User melden ĂŒber ein Service Desk (z.B. Jira Service Management) neue Bugs oder stellen Anfragen fĂŒr neue Features. Diese werden als Service Request oder Incident Management verarbeitet und in die Planung fĂŒr das nĂ€chste Update mit aufgenommen bzw. priorisiert.
  • Anschließend werden diese Tickets als Insights-Objekt mit dem Change Management synchronisiert. Und vom Entwickler Team in einem Jira Software Projekt verarbeitet.

Die entscheidende Frage lautet, wie können Tickets aus Jira Service Management exportiert und in das Software-Projekt importiert werden. Ohne dass wertvolle Informationen verlorenen gehen und die Kommunikation beider Teams professionell und effizient ablĂ€uft? Üblicherweise werden diese Tickets zusammengefasst und via E-Mail an die Entwickler weiter gegeben. Doch statt Bug und Feature Reportings manuell als Mail anzufertigen und an die Entwicklung weiterzugeben, kann mittels einer Jira Integration dieser Prozess automatisiert werden. Dadurch können Supportmitarbeiter Issues erstellen und synchronisieren, sodass das Entwicklungsteam sofort Zugriff auf die entsprechenden Tickets erhĂ€lt. Und zwar ohne, dass sie erst ihre E-Mails durchforsten mĂŒssen. Das bedeutet auch, dass der Supportmitarbeiter Einsicht in den Status der jeweiligen Tickets hat, und kann somit eine Status-Änderung (z.B. Fixed) direkt an den User kommunizieren.

Outsourcing der QualitĂ€tssicherung fĂŒr Entwickler, die durch mehrere Jira-Instanzen getrennt sind

In großen Software oder Gaming Unternehmen ist es meist ein Best Practice, die QualitĂ€tssicherung (QS) von Software-Projekten outzusourcen. Diese Unternehmen arbeiten sehr oft mit einer Vielzahl von verschiedenen Prozessen, PrioritĂ€ten und Vorgaben. Dadurch mĂŒssen diese Mitarbeiter stĂ€ndig neue Methoden adaptieren und flexibel in Ihrer Arbeitsweise agieren. Üblicherweise haben die QS Mitarbeiter hĂ€ufig keinen Zugriff auf die Jira Instanz der Entwickler. Und können so lediglich auf deren eigene Service Management Instanz zugreifen. Um Aufgaben fĂŒr die Entwickler zu generieren, mĂŒssen QS Mitarbeiter Zugriff auf die Instanz der Entwickler erhalten, um Tickets manuell in deren Jira anlegen zu können und zu pflegen. Dies kostet nicht nur viel Zeit und Geld hinsichtlich Lizenzkosten und doppelter Datenpflege, sondern kann auch zu Problemen bei der Aktualisierung des Contents in beiden Instanzen fĂŒhren. 

Durch ein Sync Tool können die QS Mitarbeiter jedoch in Ihrer eigenen Instanz arbeiten und nur jene Tickets oder Projekte synchronisieren die fĂŒr Ihre Kollegen wichtig sind.

Ein Szenario: 

  • QS Mitarbeiter findet Bug
  • Der Mitarbeiter erstellt ein Jira Ticket
  • QS Team Lead analysiert und priorisiert die Tickets und synchronisiert diese mit dem Projekt der Entwickler
  • Das Ticket wird in der Instanz der Entwickler automatisch erstellt
  • Die Entwickler bearbeiten das Ticket und Ă€ndern den Status auf “Resolved”
  • Der Status Ă€ndert sich in der Instanz der QS Mitarbeiter

In diesen FĂ€llen können einzelne Jira Projekte, Tickets und beliebige Felder mit einer externen Instanz  synchronisiert werden. Dadurch fördert man letztendlich die Kollaboration verschiedener Anspruchsgruppen. Dadurch steigt letztendlich nicht nur die Effizienz der Bearbeitungszeit von Aufgaben, sondern es verbessert sich auch die unternehmensĂŒbergreifende Kommunikation zwischen den einzelnen Stakeholdern. Aus diesem Grund bietet ein Synchronisierungs-Tool die Option unternehmensĂŒbergreifend an Jira Projekten oder Jira Tickets gemeinsam zu arbeiten. So kann wertvolle Zeit gespart werden und in Krisenzeiten (Corona) effizientes Projektmanagement betrieben werden. 

Je nachdem welche Anforderungen an die Synchronisierung von Projekten, Tickets  und Feldern etc. bestehen, kommen mehrere Lösungen und Apps in Frage. In diesem Fall gehen wir nĂ€her auf die Lösung Jira Sync ein. Diese kommt ganz ohne Installation eines Plugins aus und bietet weitaus mehr Sicherheit gegenĂŒber alternative Lösungen. Die Integration wird so konfiguriert, dass es hinter der eigenen Firewall installiert werden kann und unabhĂ€ngig der User-Anzahl der Instanzen agiert. Das bedeutet, dass mit Jira Sync weitaus geringere Kosten auftreten und als Microservice verwendet werden kann. ZusĂ€tzlich ist diese Lösung bereits fĂŒr alle Versionen von Jira und Jira Service Management erhĂ€ltlich und fĂŒr Cloud und Data Center verfĂŒgbar.

Wie man Workflows, Tickets und Jira Projekte synchronisiert

1. Workflow Mapping

Nicht immer können direkt ganze Unternehmensprozesse als Workflows in eine zweite Instanz ĂŒbertragen werden. Oftmals ist es bereits ausreichend, nur einzelne Prozessschritte (Status) zu ĂŒbertragen, welche in der zweiten oder externen Instanz tatsĂ€chlich vorhanden sind und demnach bearbeitet werden können. Hierzu bedarf es die Anpassung eines individuellen Workflow Mappings. 

Abstimmung des Workflows beider Teams

Damit ein effiziente Synchronisierung gelingen kann, sollte vorher unbedingt besprochen werden wie einzelne Workflow Prozessschritte (Status) in den jeweiligen Instanzen aussehen. Via Workflow Mapping wird jeder einzelne Prozessschritt aus einer Instanz mit dem entsprechenden Prozessschritt aus der anderen Instanz aufeinander abgestimmt. Sobald sich nun der Status im Referenzticket Ă€ndert, wird diese Änderung automatisiert eine Statusanpassung im Zielticket bewirken. 

Jira Simple Workflow
Einfacher Jira Workflow
Jira Support & Service Workflow
Support & Service Workflow

3. Synchronisierung von Jira Ticket Informationen

Nachdem du dich mit deinen Teams bereits ĂŒber Workflows abgestimmt hast, geht es jetzt darum zu ĂŒberlegen, welche Felder im Ticket synchronisiert werden sollen. Benötigst du lediglich einfache Informationen wie Ticket-Name, PrioritĂ€t und Beschreibung? Oder sollen zusĂ€tzlich auch AnhĂ€nge, Epics, Kommentare und Benutzerdefinierte Felder in die zweite Instanz oder Projekt ĂŒbertragen werden? Mit Jira Sync ist es zudem möglich, die geteilten Informationen jederzeit anzupassen und ganz auf deine BedĂŒrfnisse zuzuschneiden. 

Jira Ticket Synchronisierung
Jira Ticket Synchroniserung

4. User Mapping

Neben den ĂŒblichen Informationen der Jira Tickets, stellt sich die Frage, ob auch einzelne Bearbeiter oder Autoren in eine zweite Instanz “gemapped” werden sollen. So können beispielsweise der User aus der ersten Instanz den Namen “John Doe” haben, in der zweiten / externen Instanz wird dieser dann auf den Namen “John Doe (External) gemapped. 

Jira Sync User Mapping

Alternativ ist es auch möglich mehrere User aus dem Projekt A auf einen User aus Projekt B zu ĂŒbertragen. Dadurch wird ermöglicht, externe Dienstleister oder Teams einfacher zu verwalten und es erĂŒbrigt sich unzĂ€hlige weitere User zu deiner Jira Instanz hinzuzufĂŒgen. 

Jira Projekte in Echtzeit synchronisieren

SelbstverstĂ€ndlich kann es im TagesgeschĂ€ft, bei Software-Realease, großen Updates oder in kritischen Projektphasen auch mal stressig zugehen. Probleme, Bugs und Anpassungen mĂŒssen in solchen Zeiten dann möglichst schnell implementiert werden. Das bedeutet wiederum auch, dass Aktualisierungen von Tickets möglichst schnell in die zweite Instanz bzw. Projekt ĂŒbertragen werden mĂŒssen. Mit Jira Sync gehört dies der Vergangenheit an und alle Tickets werden in Echtzeit synchronisiert. Dadurch haben alle beteiligten Teams stets die neuesten Informationen zur VerfĂŒgung und können ohne Unterbrechungen ihre Arbeit fortsetzen.

Jira Sync

Jira Sync - Erlebe nahtlose Zusammenarbeit zwischen internen und externen IT-Teams beim Einsatz von Jira

Synchronisiere Jira Tickets, AnhĂ€nge, Workflows, Kommentare und mehr zwischen mehreren Jira Instanzen. Ohne deinen externen Partnern umfangreichen Zugang zu deiner Jira Instanz geben zu mĂŒssen.

Zusammenfassung

Je nachdem welche Anforderungen oder welcher Use Case bei Ihnen in Frage kommt, können unterschiedliche Informationen der Jira Issues in eine zweite Instanz ĂŒbertragen werden. Deshalb ist es notwendig, zu definieren, welche Informationen benötigt werden. ZusĂ€tzlich gilt es zu analysieren, wie der Workflow der beteiligten Teams aussieht und sich anschließend auf einen Status Quo einigen. Je genauer die Anforderungen vorher definiert werden, desto effizienter kann ein Jira Sync Tool konfiguriert werden.

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.