ATLASSIANS ZWEIJÄHRIGE CLOUD-REISE - TECHCRUNCH - EIGENSCHAFTEN - 2019

Anonim

Vor ein paar Jahren schockierte Dropbox eine Menge Leute, als es sich dazu entschloss, die Public Cloud größtenteils fallen zu lassen und eigene Rechenzentren aufzubauen. In letzter Zeit hat Atlassian das Gegenteil getan und die meisten Rechenzentren geschlossen und in die Cloud gewechselt. Unternehmen treffen diese Auswahl aus verschiedenen Gründen. Als Atlassian CTO Sri Viswanath 2016 hinzukam, traf er die Entscheidung, die größten Anwendungen des Unternehmens nach AWS zu verlagern.

Dies ist zum Teil eine Geschichte technischer Schulden - das ist das Konzept, dass Ihre Anwendungen im Laufe der Zeit durch Schichten von krustigem Code belastet werden, was es schwieriger zu aktualisieren und immer schwieriger zu verwalten ist. Für Atlassian, das im Jahr 2002 gegründet wurde, kam diese Rechnung im Jahr 2016, als Viswanath für das Unternehmen zur Arbeit kam.

Atlassian wusste bereits, dass sie den Code aktualisieren mussten, um in die Zukunft zu gehen. Einer der Gründe, warum sie Viswanath an Bord geholt haben, war, diesen Vorwurf zu führen, aber die Gedanken waren bereits vorhanden, noch bevor er dort ankam. Ein kleines Team wurde 2015 gegründet, um die Vision und die Architektur für den neuen Cloud-basierten Ansatz zu erarbeiten, aber sie wollten ihren ersten CTO haben, um es zu verwirklichen.

Wechsel zu Microservices

Er setzte den Plan in die Tat um und gab ihm den internen Codenamen Vertigo - vielleicht, weil der Gedanke, den größten Teil seines Software-Stacks in die Public Cloud zu verschieben, das Entwicklerteam schwindlig machte, überhaupt darüber nachzudenken. Ziel des Projekts war es, die Software so neu zu konzipieren, dass sie mit den größten Produkten Jira und Confluence begann, so dass sie für das nächste Jahrzehnt den Grundstein für das Unternehmen legte - ohne Druck oder so.

Foto: WILLIAM WEST / AFP / Getty Images

Sie haben einen großen Teil des Jahres 2016 damit verbracht, die Software neu zu schreiben und sie auf AWS einzurichten. Sie konzentrierten sich darauf, ihren 15 Jahre alten Code in Microservices umzuwandeln, was letztendlich zu einer kleineren Codebasis führte. Er sagte, die technischen Schuldenprobleme seien sehr real, aber sie müssten vorsichtig sein, um das Rad nicht neu zu erfinden, sondern nur das ändern, was nach Möglichkeit geändert werden müsse.

"Die Codebasis war ziemlich groß und wir mussten zwei Dinge tun. Wir wollten es für Multi-Tenant-Architektur bauen und wir wollten Microservices erstellen", sagte er. "Wenn es einen Service gab, der herausgezogen und in sich geschlossen werden konnte, haben wir das getan, aber wir haben auch neue Services als Teil des Prozesses geschaffen."

Kunden migrieren

Letztes Jahr war das Migrationsjahr, und es war in der Tat ein ganzjähriges Projekt, um jeden letzten Kunden auf das neue System umzustellen. Es begann im Januar und endete im Dezember und umfasste den Umzug von Zehntausenden von Kunden.

Foto: KTSDesign / Wissenschaftsfoto-Bibliothek

Zuallererst haben sie alles automatisiert, was sie konnten, und sie waren auch sehr bedacht in Bezug auf die Migrationsreihenfolge, da sie sich der Migrationen bewusst waren, die schwieriger sein könnten. "Wir waren nachdenklich in welcher Reihenfolge zu migrieren. Wir wollten am einfachsten nicht zuerst und am härtesten am Ende. Wir wollten nicht nur die härteren machen und keine Fortschritte machen. Wir mussten (unsere Ansätze) zu mischen behebt Fehler und Probleme während des gesamten Projekts ", sagte er.

Viswanath erklärte, dass das übergeordnete Ziel darin bestehe, die Kunden ohne größere Zwischenfälle zu bewegen. "Wenn du mit irgendjemand sprichst, der Migration macht, ist das eine große Sache. Jeder hat Narben, die Migrationen machen. Wir waren uns bewusst, das ziemlich vorsichtig zu machen." Überraschenderweise, obwohl es nicht perfekt war, schafften sie es, die gesamte Übung ohne einen größeren Ausfall zu absolvieren, ein Punkt, auf den das Team mit Recht stolz ist. Das bedeutet nicht, dass es immer glatt oder einfach war.

"Es klingt superleicht: 'Wir waren nachdenklich und wir wanderten, ' aber jeden Tag gab es Krieg. Wenn du abwandst, schlägst du gegen eine Wand und reagierst. Das war für uns das ganze Jahr über täglich", erklärte er. Es erforderte eine komplette Teamarbeit mit Engineering, Produkt und Support. Dies beinhaltete, dass eine Kundenbetreuerin an den täglichen Scrum-Meetings beteiligt war, damit sie ein Gefühl für die Probleme der Kunden entwickeln und sie so schnell wie möglich beheben konnten.

Was sie gewonnen haben

Wie in jedem Cloud-Projekt gibt es einige allgemeine Vorteile beim Verschieben einer Anwendung in die Cloud im Hinblick auf Flexibilität, Flexibilität und Ressourcenelastizität, aber es gab mehr als das, wenn es um dieses spezielle Projekt ging.

Foto: Ade Akinrujomu / Getty Images

Vor allem hat es eine schnellere Bereitstellung mit mehreren Bereitstellungen gleichzeitig ermöglicht, was größtenteils auf den umfangreichen Einsatz von Microservices zurückzuführen ist. Das bedeutet, dass sie neue Funktionen viel schneller hinzufügen können. Während des Migrationsjahres hielten sie größtenteils neue Funktionen zurück, weil sie die Dinge so statisch wie möglich halten wollten, aber mit dem neuen System konnten sie sich viel schneller bewegen, um neue Funktionen hinzuzufügen.

Sie erhalten eine viel bessere Leistung und wenn sie einen Leistungsengpass haben, können sie einfach mehr Ressourcen hinzufügen, weil es die Cloud ist. Darüber hinaus waren sie in der Lage, in der EU vor Ort präsent zu sein, und das verbessert die Leistung, da die Anwendungen näher bei den Endbenutzern angesiedelt sind.

Schließlich fanden sie die Cloud tatsächlich als eine wirtschaftlichere Option, etwas, das nicht jedes Unternehmen findet, das in die Cloud wechselt. Durch die Schließung der Rechenzentren und die Senkung der Investitionskosten für den Kauf von Hardware und die Einstellung von IT-Personal konnten die Kosten gesenkt werden.

Verwalten der People-Teile

Es war ein langwieriges Projekt und als solches mussten sie wirklich über den menschlichen Aspekt nachdenken. Sie wechselten Leute hinein und hinaus, um sicherzustellen, dass die Ingenieure frisch blieben und nicht ausbrannten, um beim Übergang zu helfen.

Eine Sache, die geholfen hat, war die Unternehmenskultur im Allgemeinen, die Viswanath freimütig als eine mit offener Kommunikation und einer allgemeinen "No Bullshit" -Politik beschreibt. "Wir haben eine offene Kommunikation aufrechterhalten, auch wenn es nicht gut lief. Die Leute würden ihre Hand heben, wenn sie nicht mithalten könnten, und wir würden ihnen Hilfe bringen", sagte er.

Er räumte ein, dass es in der Firma einige Unruhe gab und dass er persönlich ein Projekt dieser Größenordnung durchführte, aber sie wussten, dass sie es für die Zukunft der Organisation tun mussten. "Es war auf jeden Fall nervös, was passiert, wenn dieses Projekt nicht gut läuft. Es schien die offensichtlich richtige Richtung zu sein und wir mussten es tun. Das Risiko bestand darin, dass wir in der Ausführung Fehler machten und wir nicht die Vorteile erkannten machen."

Am Ende war es eine Menge Arbeit, aber es hat gut geklappt und sie haben das System für die Zukunft. "Jetzt sind wir für die nächsten 10 Jahre aufgestellt", sagte er.