Veröffentlicht am 12-03-2019

Kosteneinsparungsstrategien mit Cloud Hosting - Teil 2

In Teil 1 fing ich an, über einige der Strategien zu sprechen, die wir bei Crunch implementiert haben, um Geld für unser Cloud-Hosting zu sparen und gleichzeitig unsere Prozesse und Kultur mit dem Engineering-Team zu verbessern. Dieser Beitrag wird an der Stelle weitergehen, an der wir mit vier weiteren Maßnahmen aufgehört haben.

Wenn Sie dies nicht bereits getan haben, würde ich Ihnen dringend empfehlen, Teil 1 vorzulesen, da Sie dadurch eine gute Einführung in die Arbeit erhalten, die wir gerade gemacht haben.

Lassen Sie uns also ohne weiteres weitergehen und weiter in dieses Thema eintauchen.

Kleinste entfernbare Einheit

Die Anzahl der Pipeline-Läufe: Ein ziemlich klares Bild davon, wie viel Geschwindigkeit wir gewonnen haben, als wir mit den Änderungen beginnen.

Wir haben viel Zeit und Ressourcen für die automatisierten Prozesse selbst aufgewendet, wenn wir Dinge bereitstellen. Ursprünglich hatten wir eine Pipeline, die alles tun würde. Dies erwies sich jedoch als unüberschaubar, da die Anzahl der Dienste zunahm.

Deshalb haben wir es auf zwei Arten in kleinere Pipelines unterteilt. Zunächst haben wir die zugrunde liegende Infrastruktur und die Dienste in eine eigene Pipeline aufgeteilt. Wir folgten diesem Schritt und teilten dann die Service-Pipeline auf, sodass jeder Service über eine eigene Implementierungs-Pipeline verfügte.

Darüber hinaus haben wir auch die Aufgaben innerhalb der Pipelines parallelisiert, wo wir konnten. Dies ermöglichte es uns letztlich, bei gleicher Rechenleistung viel mehr Wert in derselben Zeit zu liefern.

Dadurch kann das Team jetzt kleine Verbesserungen bereitstellen, da die Pipelines jetzt sehr klein, in sich geschlossen und kurz sind.

Herausforderungen

Die größte Herausforderung, die sich daraus ergab, war die Tatsache, dass wir jetzt so viele Benachrichtigungen erhalten, weil wir viel mehr Pipelines haben. Daher mussten wir unsere Benachrichtigungsstrategie überprüfen.

Wir mussten von einer Welt, in der wir den Status jeder Pipeline kennen mussten, umziehen und uns nur benachrichtigen, wenn sie ausfiel. Darüber hinaus mussten wir das Publikum bei jeder Benachrichtigung einschränken. Wir sind in einem Kompromiss gelandet, bei dem nur Personen, die sich für eine Änderung interessieren, darüber informiert werden.

Wir mussten viele neue Kanäle in Mattermost (unserem internen Nachrichtensystem) erstellen und sicherstellen, dass Personen, die die Benachrichtigungen sehen mussten, den Kanal nicht sofort stummschalten konnten, weil sie zu laut waren. Dies stellte sich als Herausforderung heraus.

Ergebnisse

Da eine Pipeline nur noch einen kleinen Bereich abdeckt, vermeiden wir es, beim Brechen mehrere Probleme in einer Pipeline zusammenzufassen. Das bedeutet, dass kleine Probleme nicht mehr zu Zwischenfällen führen.

Wir haben jetzt auch einen Anreiz, die Zeit für die Inbetriebnahme eines Dienstes zu optimieren. Dies liegt daran, dass es jetzt einer der zeitaufwändigsten Teile des Bereitstellungsprozesses ist.

Glücklicher Weg zur Produktion

Ein paar Monate später haben wir die Art und Weise geändert, in der Pipeline-Läufe gezählt werden, im Vergleich zu der anderen Grafik oben (sonst müssten wir eine logarithmische Skala verwenden).

Der Weg zur Produktion war in Bezug auf die Anzahl der erforderlichen Schritte und die Zeit, um dorthin zu gelangen, ziemlich lang. Da wir nun alle Entwicklungsumgebungen zu einer zusammengefügt hatten, hatten wir jetzt die Gelegenheit, das, was CD wirklich bedeutete, neu zu definieren.

Wir haben jetzt einen "Feature-Zweig" -Pfad, in dem Entwickler sich in einer Entwicklungsumgebung festschreiben können. Dies ist nützlich, wenn einzelne Features in einer produktionsähnlichen Umgebung überprüft werden müssen, bevor sie mit dem Master zusammengeführt werden.

Wir haben auch einen "Hauptzweig" -Pfad, in den Entwickler Code festlegen und automatisch erstellt werden. Diese werden dann für PreProduction bereitgestellt, automatisierte Tests werden ausgeführt und bei Erfolg in die Produktion verschoben.

Herausforderungen

Die Umstellung der Bereitstellung auf die Produktion war keine große Herausforderung, da es uns bereits gelungen war, die Testumgebung zu einer zu verschmelzen.

Tester waren jedoch am stärksten von dieser Änderung betroffen, da die Qualität der schriftlichen Tests viel wichtiger geworden ist. Ein flockiger Test ist jetzt ein größeres Risiko, da diese Tests nur noch mit PreProduction durchgeführt werden.

Ergebnisse

Da der Weg zur Produktion jetzt 15 Minuten beträgt und ein Rollback fünf Minuten dauert, haben wir keinen Anreiz, die Dinge von Hand zu beheben.

Mit einem kurzen Einstieg in die Produktion stellen wir viel mehr pro Tag bereit, wodurch die Bereitstellung einer kleinen Erhöhung möglich ist, was unser Bestreben unterstützt, eine agilere Organisation zu werden. Die Änderungsrate der Pipelineläufe ist um eine Größenordnung höher, wenn nicht um zwei Größenordnungen höher als zuvor.

Investition

Eine der Paradigmenwechsel beim Cloud Computing ist, dass Sie pro Sekunde, Minute und Stunde bezahlen. Während dies für alle flüchtigen Workloads sehr gut ist, ist der Großteil der Produktionsinfrastruktur rund um die Uhr verfügbar.

Alle früheren Bemühungen waren darauf ausgerichtet, die Menge und Qualität der Ressourcen zu reduzieren, die im Rahmen unserer Entwicklungspraktiken erforderlich sind. Für langlebige Server (Think-Datenbank usw.) ist nicht viel möglich.

Die automatische Skalierung ist ideal, wenn Sie eine große Saisonabhängigkeit hinsichtlich des Verkehrsaufkommens Ihrer Produkte haben. Es hat sich jedoch herausgestellt, dass wir keinen Grund haben, mehr als drei davon zu rechtfertigen. Für die Notfallwiederherstellung haben wir jedoch mindestens drei von allem. Dies bedeutet, dass Autoskalierung nicht wirklich etwas ist, mit dem wir sparen können.

Stattdessen mussten wir sicherstellen, dass wir die richtige Workload auf der richtigen Instanz ausführen. Dann mussten wir nur eine Reservierungsvereinbarung auswählen und das Geld von unserem Finanzteam erhalten.

Herausforderungen

Eine der größten Herausforderungen bestand darin, den richtigen Instanztyp / Betriebssystem / Workload-Match zu finden. Um herauszufinden, welche Workloads für einen "T2" -Instanztyp geeignet sind, bei dem die CPU-Auslastung niedrig ist, aber viel Speicherplatz beansprucht, sind einige Tests erforderlich. Ein Upgrade auf die richtige Instanz / das richtige Betriebssystem erfordert Zeit und Planung.

Zu unserem Finanzcontroller zu gehen und mit einem glaubwürdigen Versprechen, etwas zu sparen, Geld zu verlangen, war ziemlich einfach, es ist nur eine Frage des Timings und des Cashflows.

Ergebnisse

Es lief nicht perfekt - wir hatten einige AWS-Instanzen reserviert, die wir nicht verwenden konnten, da Einschränkungen bei unseren Anbietern dies für zwei Monate unmöglich machen. Das bedeutet, dass wir keine perfekte Rendite erzielen konnten.

Wir haben jedoch immer noch 30% eingespart, indem wir im Vorfeld Geld investiert haben. Wir haben diese Zahl erreicht, weil wir im Durchschnitt 99% von dem, was wir reserviert haben, verwenden. In diesem Zusammenhang sind dies im Laufe des Jahres etwa zweieinhalb Monate Einsparungen. Das ist eine Menge Geld!

Wir haben derzeit eine geringe Abdeckung, etwa 44% unserer Infrastruktur sind reserviert. Ziel ist es, in der nächsten Reservierungsrunde bis zu 60% abzudecken, mehr zu zahlen und mehr zu sparen. An dieser Stelle können wir uns vor Ort mit den restlichen 40% unserer Infrastruktur befassen.

Lieferantenmanagement

Wir sind große Open-Source-Benutzer, wir glauben, dass dies für bessere Software sorgt. Einige sind jedoch einfacher zu verwalten als andere. Redis, RabbitMQ, ELK-Stack, Linux, Prometheus und Kubernetes sind alles Werkzeuge, die wir wirklich gerne verwenden.

Am Ende haben wir festgestellt, dass die ELK-Stapel ein teurer zu verwaltender Stapel sind. Wir verwendeten unsere eigenen, aber es war teuer und arbeitsintensiv. Bei unserem ursprünglichen Anbieter war es auch teuer, aber weniger arbeitsintensiv. Bei unserem neuesten Anbieter ist es weniger teuer, es ist kein Arbeitsaufwand an unserer Seite und es wurde ein Mehrwertdienst hinzugefügt, der einige zusätzliche Dashboards ist, die wir gerne nutzen, um uns vom Markt zu unterscheiden.

Wir haben auch unseren Kubernetes-Anbieter migriert. Wir hätten uns für KOPS auf EC2 entscheiden können, aber am Ende haben wir uns für EKS entschieden. Unser früherer Anbieter war recht teuer, sodass wir eine ganze Menge Geld sparen konnten. Da AWS die Komponenten-Upgrades von K8 verwaltet, sparen wir uns auch einiges an Zeit.

Herausforderungen

Die Arbeit mit Anbietern ist ziemlich zeitaufwändig. Wir müssen nicht nur über das beste Geschäft verhandeln, sondern auch die Gesetzmäßigkeiten und die Bestimmungen der DSGVO prüfen.

Da das Synergy-Team über eine gute Erfolgsgeschichte verfügt, war es nicht allzu schwierig, neue Anbieter zu gewinnen und andere zu sonnen. Hätten wir mit dem Lieferantenmanagement begonnen, um Kosten zu sparen, wäre es ein viel schwierigerer Verkauf für das Management- und Finanzteam gewesen.

Die Migration unserer gesamten Arbeitslast von einem Anbieter zu einem anderen ist ziemlich riskant. Wir mussten die Migration von Kubernetes sehr sorgfältig kommunizieren und planen. Wir haben das Glück, dass wir über die Engineering-Abteilung und das Vertrauen und die Unterstützung der breiteren Unternehmen verfügen, um eine so große Veränderung durchzuführen.

Ergebnisse

Durch den Einsatz von Anbietern, anstatt diese intern zu verwalten, haben wir eine Menge Geld gespart, da deren Kosten geringer sind als in EC2-Instanzen. Außerdem wird im Synergy-Team viel Zeit gespart, da die Cluster nicht intern verwaltet werden müssen. Wir haben auch weniger Anbieter im Allgemeinen, was den Zeit- und Arbeitsaufwand für die Verhandlung von Deals reduziert.

Fazit

Dies ist die Geschichte aus der Sicht von Synergy, aber insgesamt war es eine Abteilungsänderung. Wir verwenden Kosteneinsparungen als Strategie, um verschiedene Rückkopplungsschleifen zu verbessern. Jeder Teil, in dem wir die Kontrolle über unsere Ausgaben wiedererlangten, diente auch einem anderen Zweck.

Die größten Einsparungen, die wir gemacht haben, hatten mit Kultur und Entwicklungspraktiken zu tun. Erst wenn diese Änderungen vorgenommen wurden, können Sie wirklich ein abenteuerlustiges Abenteuer erleben.

All diese Änderungen waren möglich, weil wir uns mit einem klaren Ziel angesprochen und das Feedback der Menschen mit einfließen ließen: Sie haben die Kontrolle über unser Cloud-Budget und verbessern den Service, während wir dabei sind.

Wir haben fundierte Entscheidungen mit Daten getroffen und dort investiert, wo es darauf ankommt. Wir haben unsere Energie konzentriert, um große Wirkung zu erzielen und die Geschwindigkeit zu erhalten. Im Zuge dieses Kulturwandels haben wir das Vertrauen in unsere Entwickler erhöht, um ihren Produktionswechsel eigenständig durchzuführen.

Den Status Quo herauszufordern ist schwierig, weil es Gewohnheiten und Kultur herausfordert. Gut gemacht, es ist eine befreiende Übung.

Worauf wartest du?

Geschrieben von Florentin Raud, IT- und Support-Manager bei Crunch.

Hier erfahren Sie mehr über das Technologie-Team von Crunch und unsere aktuellen Möglichkeiten.

Siehe auch

Schaffung von Möglichkeiten für Schüler, die in der Tech-Community unterrepräsentiert sindFunktion HalloWorld () {Was sind Goroutinen? Und wie funktionieren sie eigentlich?Das Dilemma des Android-BenutzersInklusive Einstellung und bessere JobbeschreibungenNau Mai Haere Mai Ki Dev Academy, Newmarket.