Archiv des Autors: Kevin Heusinger

Wie gut kann ChatGPT einen Werbetext schreiben?

Schreibe eine Antwort

ChatGPT als Sparringspartner für Marketingaktivitäten? Normalerweise, da ich kein Werbe- oder Kommunikationsexperte bin, gehe ich bei Kommunikationsfragen so vor, dass ich zuerst die Strategie und Mathematik mache und nach einigen amatheurhaften ersten Ideen für die konkrete Kommunikation (Pressetexte, Social Media, Leistungsbeschreibungen, etc.) gehe ich damit zum Kommunikationsberater meines Vertrauens und wir Brainstormen bis die Richtung stimmt. Dann geht alles seinen Gang.

Nach der Ideenfindung erster Botschaften gebe ich die Konkretisierung üblicherweise aus der Hand. Wie weit kann ChatGPT bereits im Vorfeld die Botschaften konkretisieren? Kann es Benefits und Vorteile verstehen? Wie gut sind die Texte, die es schreibt? Kann es zwischen den verschiedenen Kanälen und Zielgruppen unterscheiden?

Dazu müssen wir zuerst verstehen, was eigentlich der Inhalt des neuen Angebots ist. Folgendes ist dem Team bei Kehrwasser in letzter Zeit klar geworden: Was Kehrwasser bei seinen Kunden tut, ist über die Zeit zur Innovationsberatung geworden. Es steht im Raum, die Beratung an die erste Stelle zu Stellen und die Entwicklungsdienstleistung an Zweite. Es geht im Kern mittlerweile darum, Ideen der Kunden für neue Produkte systemtisch so aufzustellen, dass sie eine echte Nachfrage erzeugen. Also unbedingt Rohrkrepierer verhindern, vor allem aber die beste Wertigkeit des Produkts erhalten. Nicht durch raten, sondern durch systematisches, iteratives und empirisches Vorgehen.

Per Chatdialog zum ChatGPT Werbetext

Von ChatGPT wollte ich zuerst wissen, ob es versteht, welche Dienstleistung mein amatheurhafter Werbetext beschreibt:

Was für eine Dienstleistung erklärt der folgende Text? „Nicht jedes Produkt oder jede Erfindung ist gleich eine Innovation. Es muss tatsächlich den Nutzen erhöhen. Und ob es das tut, entscheiden die Nutzer. Sie müssen erst erkennen, dass sie ein Problem haben und dann verstehen, wie das Produkt oder der Service ihnen dabei helfen kann, es zu lösen.
Es ist nicht einfach, eine neue Produktidee, eine Erfindung oder einen neuen Service erfolgreich auf den Markt zu bringen und vor Nachahmern zu schützen.
Wir haben Erfahrung in mehreren digitalen Projekten bekannter und vor allem mittelständischer Unternehmen gesammelt.“

Grundsätzlich hauen mit diese Antworten von ChatGPT immer wieder um. Ich habe eine gewisse Erfahrung mit neuronalen Netzen und dem Fachgebiet „Intelligent Data Analysis“, dass ChatGPT soetwas erreichen kann, damit hätte ich nicht so früh gerechnet. Aber das ist nichts Neues bei ChatGPT, aus dieser Sicht verblüfft mich jede Antwort. Aus Marketingsicht erfüllt es in gewisser Weise meinen Anspruch. Besser als was so manche Freelancer liefert. Es fehlt mir so ein bißchen, dass es mir erklärt, was ich noch nicht weiß. Mein Kommunikationsberater kann das.

The text describes a service that helps companies introduce new products or inventions into the market in a way that they are accepted, perceived, and protected from competitors. The service is specifically focused on digital projects for medium-sized companies, and the company providing the service has experience in this area.

Antwort ChatGPT

Weitere Fragen betrafen die Zielgruppe, die konkreten Unternehmen aus der Zielgruppe und so weiter.

Prägnanz und eigener Werbetext

Als Nächstes ging es mir aber darum, einen konkreten Text zu bekommen, der im Gegensatz zu meinem Versuch wenigstens zur Not vorzeigbar wäre. In gewisser Weise ein Prototyp eines Marketingtextes. Also wollte ich zuerst wissen, was es von dem Text in Bezug auf seine Prägnanz (also Conciseness) hält.

I would rate the text on a scale from 1 to 10 as a 5 in terms of conciseness.

The text is not very concise because it repeats similar ideas and uses many conjunctions, such as „und“ (and), which makes the text longer than necessary. Additionally, it does not provide specific information about the service offered, such as the scope of the service, the pricing, and how it will benefit the customer.

The author also uses too many examples and not giving a clear point of what they are trying to convey. The text also repeats the same point multiple times, and uses a lot of words to convey a simple idea. To make it more concise, the author could have been more direct and to the point, providing specific information about the service and benefits, rather than repeating similar ideas.

In a more concise text, the author could have summarized the main points in less sentences and give clear examples of the services and benefits of the service.

Wahrscheinlich hat es recht. Da ich wie gesagt kein sonderlicher Experte auf dem Gebiet bin, nehme ich diese Aussage so hin. Also wollte ich nun einfach wissen, wie ChatGPT den Nutzen und Vorteil einer solchen Dienstleistung der Zielgruppe beschreiben würde.

Nutzen und Vorteile der neuen Position

Nachdem wir nun also besprochen haben, was unseren Servie auszeichnet, interessiert mich der Kundennutzen, den ChatGPT in der beschriebenen Leistung sieht. ChatGPT sollte eine Liste mit Nutzen erstellen. Inhaltlich hat mich das Ergebnis diesmal gar nicht überzeugt. Aufgelistet wurden Marktforschung, Produktentwicklung, Marketingstrategie, rechtlicher Schutz und Umsetzung. Klingt nicht wirklich unverwechselbar. Klingt nach plumper Strategieberatung. Aber: Das muss ja nicht heißen, dass ChatGPT falsch liegt. Meine beschriebe Dienstleistung könnte ja auch einfach nicht einzigartig genug sein. Entweder macht meine Beschreibung nicht klar, worin das Alleinstellungsmerkmal liegt oder ChatGPT kann nicht wirklich abstrahieren. Das ist also zu untersuchen.

Ich bin weiter mit ChatGPT auf Innovation grundsätzlich eingegangen. Kennt ChatGPT das Konzept der Strategieberatung einerseits. Und andererseits, was beispielsweise Eric Ries (Autor des Buchs „Lean Startup“) tut. Ich habe weiter gefragt, was Strategieberatung ist und separat wer Eric Ries ist. Welche Beratungsleistung Ries anbietet. ChatGPT beschrieb den Nutzen von Eric Ries‘ Leistung in vier Punkten:

  • Erhöhung der Einführungsgeschwindigkeit von Produkten oder Dienstleistungen
  • Steigerung der Erfolgsquote von Produktlancierungen
  • Verringerung der Entwicklungskosten für neue Produkte oder Dienstleistungen
  • Verbesserung der Kundenbindung durch die Entwicklung von Produkten oder Dienstleistungen, die die Bedürfnisse der Kunden besser erfüllen

Offensicht kennt ChatGPT das Konzept. Zu zeigen wäre noch, dass es Beides auch unterscheiden kann und die Schnittmenge dann wieder neu kombinieren kann. Denn es müsste nun seine sehr platte Vorstellung davon, Innovationsberatung sei im Grunde Strategieberatung, überdenken. Das scheint ihm allerdings nicht zu gelingen.

Wichtig ist insgesamt, dass wir eine Liste bekommen haben, mit der wir arbeiten können.

Der Werbetext

Doch wie gut ist nun der ChatGPT Werbetext? Der beste Text, den ChatGPT im Laufe weiterer Unterhaltung erarbeiten konnte, war der Folgende:

„Die Einführung von wirklichen Innovationen in den Markt kann ein komplexer Prozess sein. Unser Service bietet spezialisierte Unterstützung, um Ihre Ideen in echte, branchenverändernde Innovationen umzuwandeln. Von der Identifizierung unerfüllter Kundenbedürfnisse, der Entwicklung einzigartiger Lösungen, der Umsetzung effektiver Strategien und dem Schutz Ihres geistigen Eigentums, wir haben die Kompetenz, Sie in jedem Schritt des Weges zu begleiten. Lassen Sie uns Ihnen helfen, Ihre Ideen vom Konzept zur Realität zu bringen, indem wir für Ihre Kunden echten Mehrwert schaffen und Ihnen einen Wettbewerbsvorteil am Markt geben.“

Ich würde sagen: Aufgabenstellung verstanden und grundsätzlich erfüllt. Wir haben einen ChatGPT Werbetext. Eine Eins mit Strenchen gibt es aber nicht.

Fazit: Guter Helfer für erste Skizzen und MVPs

ChatGPT hat schon geholfen, das Nutzenversprechen dieses konkreten Dienstleistungsansatzes weiter zu differenzieren. Ich konnte besser verstehen, wie man ihn gegen andere Beratungsdienstleistungen abgrenzen müsste. Es könnte sogar sein, dass ich nach einem menschlichen Kommunikationsberater oder Werbetexte ewig suchen müsste, der selbst überhaupt versteht, was Innovationsberatung sein könnte. Dass die Nische erklärungsbedürftig ist, war auch vorher klar. Erkannt zu haben, dass es wahrscheinlich mehr Erklärung braucht, als gedacht, ist vielleicht der größte Erfolg dieser Unterhaltung mit ChatGPT.

Zusammengefasst: Softwareentwicklung nach Robert C. Martin

Schreibe eine Antwort

Ich stelle immer wieder fest, dass Projektleiter von Softwareprojekten dem Irrtum zum Opfer fallen, man könne einfach einen Softwareentwickler ins Projektteam packen und dann kommt Software heraus, die funktioniert, robust, erweiterbar ist und wartbar bleibt. Das ist nicht so. Robert C. Martin erklärt in verschiedenen Büchern, wieso das so ist.

Robert C. Martin, auch bekannt als „Uncle Bob“, ist ein bekannter Softwareentwickler und Autor, der vor allem durch sein Buch „Clean Code“ bekannt geworden ist. Martin hat eine klare Vorstellung davon, was er unter Softwareentwicklung versteht und wie sie richtig durchgeführt werden sollte.

Für Martin ist Softwareentwicklung der Prozess, bei dem wir Anforderungen an ein System in Form von Code umsetzen. Dieser Code sollte dann in der Lage sein, die Anforderungen des Systems zu erfüllen und zu einem späteren Zeitpunkt leicht wartbar und erweiterbar sein.

Martin betont die Bedeutung von Qualität in der Softwareentwicklung. Für ihn bedeutet dies, dass der Code einfach zu lesen und zu verstehen ist, gut strukturiert und modular aufgebaut ist und frei von Fehlern und Inkonsistenzen ist. Er glaubt, dass die Qualität des Codes direkt proportional zur Qualität und zur Wartbarkeit des Systems ist.

Ein wichtiger Aspekt der Softwareentwicklung, den Martin betont, ist die Kommunikation. Er betont die Bedeutung von klaren und präzisen Anforderungen und glaubt, dass effektive Kommunikation zwischen Entwicklern, Kunden und anderen Stakeholdern entscheidend für den Erfolg eines Projekts ist.

Martin ist auch ein Verfechter von professionellem Softwareengineering und glaubt, dass Softwareentwickler professionell ausgebildet und zertifiziert werden sollten. Er betont die Bedeutung von Prozessen und Methoden wie agile Methoden und Code-Reviews, die dazu beitragen, die Qualität des Codes zu verbessern und Fehler zu minimieren.

Schließlich betont Martin die Bedeutung von Weiterbildung und Lernen in der Softwareentwicklung. Er glaubt, dass es wichtig ist, sich ständig weiterzubilden und sich über neue Technologien und Entwicklungen auf dem Laufenden zu halten, um am Puls der Zeit zu bleiben und die bestmögliche Arbeit zu leisten.

Insgesamt versteht Martin unter Softwareentwicklung einen Prozess, der auf Qualität, Kommunikation, professionellem Softwareengineering und ständigem Lernen ausgerichtet ist. Er glaubt, dass diese Aspekte entscheidend sind, um erfolgreich Software zu entwickeln, die zuverlässig, wartbar und erweiterbar ist.

4 bewährte Verfahren für Sprint Plannings

Eine Antwort

In diesem Artikel gehen wir vier Grundsätze der Sprintplanung durch, die wir für besonders hilfreich halten.

Die agile Zeremonie des sogenannten Sprintplannings oder schlicht „Plannings“ dient in jedem Sprint dazu, die Ausführung neu zu fokussieren, Überraschungen zu minimieren und eine insgesamt höhere Codequalität zu garantieren.

Überprüfen Sie Ihre Roadmaps, bevor Sie sich treffen

Die Zeit vergeht schneller als wir denken. Daher ist es eine gute Idee, die Roadmap Ihres Projekts in den ersten zwei Wochen des neuen Jahres zu überprüfen. Die Roadmap bildet den Kontext für zwei wichtige agile Konzepte: Epics und Versionen, die das Rückgrat für die agile Programmplanung bilden und dabei helfen, die Lieferung längerfristiger Arbeit zu verfolgen. Vergewissern Sie sich, dass die Roadmap aktuell und für das gesamte Team sichtbar ist und dass Epics und Versionen vor dem Sprint Planning Meeting korrekt in Jira aufgelistet sind.

Halten Sie eine Besprechung vor der Besprechung ab

Die Sprintplanung umfasst zwei wichtige Aufgaben: die Pflege des Backlogs und die Entscheidung, welche Arbeiten im kommenden Sprint abgeschlossen werden sollen. Bei Atlassian haben wir die Erfahrung gemacht, dass das Backlog Grooming am besten in einem separaten Meeting mit dem Product Owner und dem Scrum Master vor dem eigentlichen Sprint Planning Meeting stattfindet. Für das gesamte Entwicklungsteam ist diese Vorbesprechung optional.

Was ist Backlog Grooming?

Backlog Grooming stellt sicher, dass das Backlog gesund ist. Wie sieht das aus? Gut, dass Sie fragen. Ein gesundes Backlog:

  • priorisiert jedes Arbeitselement, wobei die wichtigste Arbeit an erster Stelle steht
  • enthält vollständig ausgearbeitete User Stories, mit deren Umsetzung das Entwicklungsteam beginnen kann
  • Enthält eine aktuelle Schätzung für jedes Arbeitselement

Die Teams bei Atlassian halten einige Tage vor der Sprintplanung kurze Backlog Grooming Meetings ab. Planen Sie 30 Minuten für dieses Meeting ein, um die Aufgaben zu sichten, die Sie in den nächsten zwei Sprints am ehesten angehen werden. Manchmal werden Sie Punkte finden, die nicht detailliert genug sind, um ausgeführt zu werden, oder die mehr kontextbezogene Informationen vom Product Owner benötigen. Das ist das Schöne an der Erstellung des Backlogs im Voraus. Diese Lücken können zwischen den Meetings gefüllt werden, so dass sie während der eigentlichen Sprint-Planung keine Hindernisse (oder Zeitfresser) darstellen. Durch die Erstellung des Backlogs im Vorfeld hat das Team während der Sprintplanung mehr Zeit, seine Optionen für den Sprint zu prüfen und bei Bedarf Elemente für den nächsten Sprint zu markieren.

Team-Aktivität: Manche Teams haben Probleme mit der Schätzung. Story Points bieten einen soliden Rahmen für die Schätzung der Arbeit. Binden Sie das Team in eine Aktivität namens stille Schätzung ein. Legen Sie zu Beginn der Übung die Story-Point-Werte (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) in Spalten auf eine weiße Tafel. Bitten Sie dann das Team, die Benutzergeschichten in der Spalte zu platzieren, die sie für am genauesten halten. Die meisten Geschichten werden sich auf eine Zahl konzentrieren, und wenn es Unstimmigkeiten über den Punktwert der Geschichte gibt, ist es an der Zeit, eine Diskussion darüber zu eröffnen, warum. (Siehe auch unseren Artikel zu: Die 6 besten Planning Poker Tools zur freien Verfügung)

Informieren Sie die Sprintplanung mit Daten

Der Schwerpunkt des Sprint Planning Meetings liegt auf der Festlegung und Vereinbarung des Sprint-Ziels – der Menge an Arbeit, die das Team glaubt, während des Sprints erledigen zu können. Der Product Owner, der Scrum Master und das gesamte Entwicklungsteam müssen dabei anwesend sein. Wir bei Atlassian empfehlen ein Minimum von einer Stunde für jede Woche des Sprints, die Sie in der Besprechung abdecken wollen. Beginnen Sie beispielsweise mit einem zweistündigen Sprint Planning Meeting, um einen zweiwöchigen Sprint abzudecken. Idealerweise sollten Sie die Sprintplanung zu Beginn der Woche ansetzen. Dann werden der Kontext und der Arbeitsfluss des Teams weniger durch das Wochenende gestört.

Tipp: Planen Sie die Sprint-Retrospektive und das Sprint-Planning-Meeting nicht zusammen. Geben Sie dem Team genügend Zeit, um die Retrospektive zu verdauen und effektiv zur Sprintplanung beizutragen – vielleicht indem Sie dazwischen ein Teamessen einschieben.

Aus Erfahrung

Zu Beginn der Besprechung stellt der Scrum Master alle relevanten Aktionspunkte aus der Retrospektive des Teams vor. Als Nächstes gibt der Product Owner Produkt- oder Markt-Updates, damit alle auf dem gleichen Stand sind und den breiteren Kontext noch im Kopf haben.

Nach der Nachbesprechung ist es Aufgabe des Product Owners, das eigentliche Planungsgespräch zu beginnen. Zu Beginn verwendet der Product Owner die durchschnittliche Geschwindigkeit des Teams (die Menge an Arbeit, die typischerweise in einem Sprint abgeschlossen wird), um einen Vorschlag für eine Reihe von Storys für den Sprint, den so genannten „Sprint Forecast“, zusammenzustellen, der den Wert für den Kunden maximiert. Der Product Owner sollte auch diese drei Faktoren berücksichtigen:

  • Feiertage, persönlicher Urlaub und teamweite Ereignisse
  • Priorität der Stories im Backlog (idealerweise schlagen sie die am höchsten eingestuften Elemente vor)
  • Wie (und ob) diese Arbeit das Produkt seinem Endziel näher bringen wird

Tipp: Product Owner können den Sprint Marker verwenden, um die Velocity zu berechnen.

Wenn das Team neu ist und keine etablierte Geschwindigkeit hat, sollte der Product Owner keine Sprintprognose vorschlagen. Stattdessen sollte dies eine Übung für das gesamte Team sein, da es wichtig ist, dass jedes Mitglied zustimmt. Zunächst wird das Team die Vorhersage nach bestem Wissen und Gewissen treffen und ein paar Sprints nach dem Prinzip „Versuch und Irrtum“ durcharbeiten. Sobald die Geschwindigkeit des Teams – die durch das Velocitydiagramm in Jira sehr schön veranschaulicht wird – numerisch festgelegt ist, verwenden Sie diese Metrik, um die Sprint-Prognose zu erstellen.

Sobald der Product Owner seine Ideen für den Sprint Forecast vorgestellt hat, kann das Team diesen validieren (und/oder anpassen) und sich auf einen Aktionsplan für den Sprint einigen.

Tipp: Das Team sollte bei jedem Sprint darüber nachdenken, wie die technischen Schulden reduziert werden können. Die Erstellung eines Schnellfilters, der Bugs im Backlog des Teams hervorhebt, ist eine einfache Möglichkeit, wichtige Bugs zu markieren, die in den Sprint aufgenommen werden sollen, während das Team an User Stories in verschiedenen Bereichen der Codebasis arbeitet. Der Schnellfilter „tech debt“ verwendet die JQL-Abfrage „type in (bug)“, um die Ansicht auf Bugs zu beschränken. Erweitern Sie einfach die JQL-Abfrage, um bei Bedarf weitere Fehlertypen einzubeziehen.

Der nächste Schritt in der Sprint-Planung besteht darin, die Stories durchzugehen und zu beschreiben, welche Arbeiten zur Fertigstellung jeder Story erforderlich sind. Während das Team plant, sollten Sie sicherstellen, dass jemand die wichtigsten Punkte in jedem Jira-Ticket festhält. Auf diese Weise sind sowohl die Entscheidung als auch die Begründung später leicht zu erkennen. Das Team sollte sich Fragen stellen wie…

  • Hat sich die Definition der Story geändert, seit sie geschrieben wurde? Gibt es neue kontextbezogene Informationen, die das Team berücksichtigen muss?
  • Ist die Schätzung für die Story noch gültig? Ist das gesamte Team mit der Schätzung einverstanden? Wenn nicht, sollte der Scrum Master das Team bei der Neuschätzung anleiten.
  • Welche Aufgaben sind für die Fertigstellung dieser Story erforderlich? Verwenden Sie Teilaufgaben, um die Arbeit zu parallelisieren und den Ablauf zu optimieren. Wenn das Team bei der Aufteilung der Arbeit auf einzigartige Stories stößt, sollten diese Aufgaben zu völlig unabhängigen Stories erhoben werden.
  • Welche Auswirkungen hat das Testen auf diese Story? Wie können wir das Testen automatisieren? (Denken Sie daran, dass manuelle Testskripte im Wesentlichen technische Schulden sind).
  • Sind spezielle Fähigkeiten erforderlich? Wie können wir die Zeit des Spezialisten optimieren, ohne den Rest des Teams zu behindern?
  • Wie wirkt sich diese Geschichte auf die Architektur des Produkts aus? Gibt es bestimmte Personen, die das Team in den Entwurf und die Codeüberprüfung einbeziehen muss?
  • Gibt es Abhängigkeiten zwischen den Stories? Können wir angesichts dieser Abhängigkeiten die gesamte Arbeit während des Sprints abschließen?

Die Versuchung ist groß, diese detaillierte Übung überstürzt durchzuführen. Aber eine gute Planung zahlt sich aus, sobald der Sprint beginnt. Hier geht es vor allem darum, zu verstehen, wie die Arbeit erledigt werden soll, wobei der Scrum Master die Diskussion im Team fördert. Es ist wichtig, dass jeder gehört wird, damit sich das Team verantwortlich fühlt, sobald der Plan steht.

Tipp: Während der Sprint-Planung ist es einfach, Stories in den Sprint hinein- und wieder herauszuschieben, während das Team seine Sprint-Prognose erstellt. Klicken Sie einfach mit der rechten Maustaste auf ein Issue, um es in den oder aus dem Sprint zu verschieben.

Auf die Plätze, fertig, Sprint!

An diesem Punkt des Meetings sollte das Team mit dem Sprint Forecast zufrieden sein. Am Ende der Sprintplanung empfiehlt es sich, von allen Anwesenden mündlich zu bestätigen, was das Team am Ende des Sprints tatsächlich ausliefern wird. Stellen Sie außerdem sicher, dass jedes Teammitglied mindestens eine Aufgabe hat, mit der es beginnen kann, und dass niemand doppelte Arbeit leistet.

Das Engagement und die Moral des Teams schwanken natürlich von Sprint zu Sprint. Diese Schwankungen zeigen sich oft während der Sprint-Planung, aber widerstehen Sie der Versuchung, sich sofort damit zu befassen. Nutzen Sie stattdessen die Retrospektive des Teams, um alle Probleme zu verstehen, die sich auf die Moral auswirken. Teams, die schnell auf Kultur- und Entwicklungsprobleme reagieren, sind zufriedener, produktiver und schreiben besseren Code.

Überblick: Voraussetzungen für skalierbare Softwaresysteme

Schreibe eine Antwort

Die Skalierbarkeit von Software ist ein wichtiges Thema, da sie dafür sorgt, dass ein System in der Lage ist, sich an die wachsenden Anforderungen anzupassen und auch bei hoher Nutzung stabil zu bleiben. Es gibt verschiedene Techniken und Best Practices, die man beachten kann, um sicherzustellen, dass ein Softwaresystem skalierbar bleibt.

Eine der wichtigsten Maßnahmen ist die Verwendung von modularen und wiederverwendbaren Komponenten. Indem man das System in kleine, wiederverwendbare Bausteine unterteilt, kann man es leichter warten und erweitern. Zudem ermöglicht es die Verwendung von Komponenten, das System leichter zu testen und zu debuggen.

Eine weitere wichtige Maßnahme ist die Verwendung von Caching. Caching beschleunigt das System, indem es häufig verwendete Daten und Ergebnisse zwischenspeichert, anstatt sie jedes Mal neu zu berechnen. Auf diese Weise kann das System schneller auf Anfragen reagieren und weniger Ressourcen verbrauchen.

Eine weitere Möglichkeit, das System skalierbar zu halten, ist die Verwendung von Microservices. Bei Microservices wird das System in kleine, unabhängige Dienste unterteilt, die einzeln entwickelt, getestet und bereitgestellt werden können. Dies ermöglicht es, das System leichter zu warten und zu erweitern, da man sich auf einen kleineren Teil des Systems konzentrieren kann.

Eine weitere Technik, die bei der Schaffung skalierbarer Systeme hilfreich sein kann, ist das Load Balancing. Beim Load Balancing werden Anfragen auf mehrere Server verteilt, um die Belastung zu verringern und die Verfügbarkeit zu erhöhen. Es gibt verschiedene Möglichkeiten, wie man Load Balancing einsetzen kann, wie zum Beispiel das Round-Robin-Verfahren oder das Least-Connection-Verfahren.

Eine weitere Technik, die bei der Schaffung skalierbarer Systeme hilfreich sein kann, ist die Verwendung von Datenbank-Sharding. Bei Datenbank-Sharding werden die Daten auf mehrere Datenbanken verteilt, um die Belastung zu verringern und die Verfügbarkeit zu erhöhen. Es gibt verschiedene Möglichkeiten, wie man Datenbank-Sharding einsetzen kann, wie zum Beispiel das Horizontal-Sharding, bei dem Daten nach bestimmten Schlüsselwerten auf verschiedene Datenbanken verteilt werden, oder das Vertical-Sharding, bei dem bestimmte Spalten auf verschiedene Datenbanken verteilt werden.

Eine weitere wichtige Maßnahme ist die Verwendung von geeigneten Tools und Technologien. Es ist wichtig, dass man für das System geeignete Tools und Technologien auswählt, die gut skalierbar sind und den Anforderungen des Systems entsprechen. Dies kann beispielsweise die Wahl eines geeigneten Datenbanksystems oder eines geeigneten Load Balancers sein.

Abschließend ist es wichtig, das System regelmäßig zu überwachen und zu optimieren. Durch die Überwachung des Systems kann man frühzeitig mögliche Probleme erkennen und entsprechend reagieren. Zudem kann man durch die regelmäßige Optimierung sicherstellen, dass das System stets auf dem neuesten Stand bleibt und gut skalierbar bleibt.

In Zusammenfassung gibt es verschiedene Techniken und Best Practices, die man beachten kann, um sicherzustellen, dass ein Softwaresystem skalierbar bleibt. Dazu gehören die Verwendung von modularen und wiederverwendbaren Komponenten, Caching, Microservices, Load Balancing, Datenbank-Sharding und die Verwendung von geeigneten Tools und Technologien. Auch die regelmäßige Überwachung und Optimierung des Systems sind wichtig, um sicherzustellen, dass das System gut skalierbar bleibt.

Serverless: Vorteile für IT-Projekte

Schreibe eine Antwort

Warum sollten IT-Projekte auf Serverless setzen? Für Teams, die bereits auf eine Cloud-Infrastruktur (AWS, Azure, IBM etc.) setzen, ist die Argumentation im Grunde ein No-Brainer: Wer bereits den Cloudgedanken akzeptiert hat, also dass der Cloudanbieter die Virtualisierung, die Serverfarmen, die Skalierung und anderes übernimmt, so gilt die gleiche Argumentation für Serverless. Serverless folgt daher dem Servicegedanken und wir nennen es auch (FaaS = Function as a Service).

Wie kommen wir von der Cloud zu finanziellen Vorteilen?

Ganz einfach: Für gewöhnlich kümmert sich ein weiterer Infrastrukturdienstleister oder spezielle Leute im Team darum, auf dem Cloudservice z.B. Container zu betreiben, die letztlich die Anwendungen ausführen, also bereitstellen. Das Gleiche gilt für die Veröffentlichung der Software: Jemand kümmert sich darum.

Doch durch den Servicegedanken IaaS und PaaS (Infrastructure as a Service und Platform as a Service) ist uns bereits das Konzept klar, solche Low-Level-Aufgaben als Standardpaket zu nutzen.

Wir setzen also Cloudservices ein, weil dies zu mehr Standardisierung, zu mehr Skalierbarkeit, zu effizienteren Abrechnungsmodellen führt. Damit erhöhen wir die Zuverlässigkeit unserer Softwareprodukte, die Planungssicherheit und erzielen daraus letztlich finanzielle Vorteile.

Geringere Time-to-Market

Function as a Service (FaaS = Serverless) minimiert die Time-to-Market weiter. Container müssen nicht explizit auf Funktion getestet werden. Die Containerisierung schlägt nicht fehl. Wir haben weniger Risiken. Eine Softwarelieferung (ein Release) wird daher einfacher bzw. zuverlässiger. Weniger manuelle Aufwände und Zwischenfälle bei Inbetriebnahmen führen zu kürzerer Iteration bzw. Features können schneller ausgeliefert werden.

Kosteneffizienz durch Skalierbarkeit

Schon bei Evolutionsschritten in die Cloud haben wir verstanden, dass wir die Ressourcen an unseren tatsächlichen Bedarf anpassen können. Diese Effekte und Vorteile der Cloud sind bekannt. Konkret gesprochen: Unsere IT muss nicht erst neue Server bestellen, anliefern, montieren lassen und so weiter, damit mehr Last, mehr User, höherer Bedarf unserer Kunden gedeckt werden kann. Mit wenigen Klicks in den Konsolen des Cloudanbieters kann die IT nun Ressourcen loswerden, wenn diese nicht mehr benötigt werden, bzw. neue Ressourcen dazunehmen, sobald sich der Bedarf erhöht. Durch das sogenannte Auto-Scaling ist dies sogar automatisch möglich. Beispielsweise an verschiedenen Werktagen oder bei gewissen Ereignissen, wie Produktvorstellungen oder saisonalen Ereignissen.

Dieses Konzept lässt sich mit Serverless noch effizienter gestalten. Kosten fallen nun nur noch an, wenn gewisse Funktionen auch tatsächlich verwendet werden.

Angenommen Ihr Team betreibt einen Blog. In diesem Blog können Artikel auf Social Media Plattformen geteilt werden, Artikel gesucht, gelesen und kommentiert werden. Nach dem ursprünglichen Konzept fallen Kosten für einen bestimmten Server an, auf dem eine Software vorliegt (die Blog-Anwendung), die all diese Funktionen ermöglicht.

Egal ob 10.000 User oder 100 Ihren Blog pro Monat aufrufen und egal welche Funktionalität sie davon verwenden. Die Skalierbarkeit der Cloud ermöglicht es nun, dynamisch in einem Monat die Ressourcen für 10.000 Nutzer zur Verfügung zu stellen, während die Ressourcen im nächsten Monat so reduziert werden können, dass sie die 100 Nutzer bestmöglich versorgt, allerdings die Kosten der nicht benötigten Ressourcen einspart. Für Teams, die bereits auf die Cloud setzen, ist dies nichts Neues.

Was aber, wenn die in einem Monat, in dem 10.000 User ihren Blog verwenden, nur knapp 1.000 davon, ihre Artikel kommentieren, 9.000 von ihnen aber nicht? Sie bezahlen das Feature „Artikel kommentieren“ für 9.000 Nutzer, die es nicht nutzen.

Mit Serverless ist es nun möglich, ausschließlich für die Ausführung der reinen Funktionalität zu zahlen. Die 9.000 Nutzer im Beispiel oben würden demnach für das Kommentieren keine Kosten erzeugen, lediglich für andere Aktionen, wie Lesen und Teilen.

Der ROI (Return on Investment) ist an der Stelle natürlich erst mit konkreten Zahlen zu erreichen, die den Betrieb der Instanzen (also der Ressourcen, die eine Anwendung wie den Blog in unserem Beispiel) für 10.000 Nutzer in dem Monat pauschal verfügbar machen, den Kosten für die Nutzung der jeweiligen Features gegenüberstellen. Das ist vielleicht Stoff für einen weiteren Artikel. Kommentiert doch bitte, falls dies interessant wäre.

Mehr Uptime durch Skalierbarkeit

Wie im Beispiel oben, fallen natürlich nicht nur Kosten in ungenutzten Zeiten (Idle-Times) an, Server laufen, sind in Standby und verbrauchen währenddessen Ressourcen. Nicht bei Serverless. Die Technologie verteilt die Ausführung der Funktionalität optimal auf die entsprechende Infrastruktur, sodass die entsprechenden Funktionalitäten stets zur Verfügung stehen – bei jeder Bedarfssteigerung und Minderung.

Weniger Aufwand für das DevOps-Team

In Teams, die Container verwenden, braucht es Mitglieder im Team, die sich darum kümmern, dass die Anwendungen korrekt in Container verpackt werden, dass die Anwendungen der QS unterzogen werden, dass die Releases automatisiert funktionieren etc. Diese Aufgabe geht nicht auf Null, denn weiterhin müssen die allgemeinen Zyklen wie Planung, Entwicklung, Test, Release etc. automatisiert durchgeführt werden. Doch diese Themen werden schlanken. Es muss weiterhin entwickelt und getestet werden, soweit ist klar. Doch Container müssen nicht hergestellt, versioniert und verwahrt werden. Dadurch werden Routineaufgaben bzw. Wartungsaufgaben vermindert, weniger Fehler treten auf und es fallen weniger Lizenzgebühren an.

Fazit

Die Vorteile für IT-Projekte und Teams durch Serverless sind somit recht deutlich. Die feinere Skalierbarkeit auf der Ebene der Funktionalitäten und nicht auf Anwendungsebene ermöglicht eine weitere Steigerung von Verfügbarkeiten und geringere Kosten durch weniger Aufwand. Es gibt aus meiner Sicht keinen Grund, nicht auf Serverless setzen.

Planning-Poker: Pause, Stabilität, Mitspieler kicken und mehr

Eine Antwort

Oft nachgefragt: Abwesende Spieler soll man kicken können, also aus dem Raum entfernen. Ob diese Funktion wirklich gut für das Spielerlebnis ist, bleibt abzuwarten. Wir haben dieses und andere Features in die neue Version eingebaut.

Nach weiteren Sprints und somit Plannings und Schätzrunden im Home-Office konnten wir weitere Informationen über unser Planning-Poker-Tool sammeln (welches wir auch kostenlos zur Verfügung stellen). Teammitglieder wünschten sich weitere Features, Verbindungsprobleme fielen auf und es gab Ideen zur Verbesserung des User Interface. In der aktuellen Version haben wir ein paar Dinge davon realisiert.

Zurückkehren in den Raum

Nach längeren Diskussionen, nach der Mittagspause mussten einige Kollegen einen neuen Spielernamen wählen, wenn sie den Browser zwischenzeitlich geschlossen hatten. Entsprechend ist es jetzt möglich, den Link zum Raum einfach erneut aufzurufen und gleich wieder den eigenen Spieler einzunehmen.

Stabilität: Verbindungsproblem behoben

Die Verbindung brach teilweise ab, sodass neue Spielstände nicht aktualisiert wurden. Die Zweiwegekommunikation (WebSockets) zwischen Scrumpoker und Server war nicht stabil. Ein Update des Kommunikationsmoduls (Sock.js zu STOMP) ermöglicht nun über sogenannte Heartbeats, also regelmäßige Lebenszeichen, die Agile Casino und Server miteinander austauschen (Pings technisch gesehen), die Verbindung sofort neu aufzubauen, falls sie abbricht.

Feature: Pause und automatische Pause ☕️

In den meisten Kartensets für Planning-Poker gibt eine Karte mit dem Wert „Kaffeetasse“. Eher eine Scherzkarte. Natürlich kommt es in einer Remote-Session vor, dass jemand zeitweise nicht am Planning teilnimmt, weil z.B. in einen anderen Call muss oder einfach mal kurz zur Tür. Wir haben beides miteinander verbunden. Der Spielt kann die Kaffeetassenkarte spielen und zeigt so den anderen Spielern an, dass er bewusst nicht mitschätzt. Der Pausemodus wird auch für die Folgerunden automatisch beibehalten. Solange der Spieler keinen anderen Wert spielt, wird automatisch die Kaffeetasse gespielt.

Überigens: Spielt ein Spieler in einer Runde keinen Wert (weil er z.B. sträflich versäumte, die Kaffeetasse expliziet zu wählen), wird er automatisch in den Pausemodus versetzt und spielt für die nächsten Runden automatisch die Kaffeetasse (bis er etwas anderes spielt).

Feature: Mitspieler kicken 😧

Auch dieses Feature wurde desöfteren angefragt. Ich bin mir noch nicht sicher, ob es wirklich notwendig ist und ob alle Spieler verantungsvoll mit dieser Option umgehen können. Spieler haben die Möglichkeit, andere Spieler im Pausemodus aus dem Spiel zu entfernen. Fährt man in der Spielstandsanzeige mit der Maus über den Wert des Spielers, erhält man die Möglichkeit, den Spieler zu entfernen. Nutzt es weise.

Feature: Spielfeld „Pokertisch“ verschönert ♥️

Bisher lagen die gespielten Karten einfach so in der linken Bildschirmhälfte herum. Wir haben die Karten jetzt an einen angedeuteten Tisch plaziert. Das Spielgeschehen wirkt so aufgeräumter und gemeinschaftlicher. Auf sehr kleinen Geräten müssen wir diese Darstellung in Zukunft noch anpassen (z.B. den Tisch in die Vertikale drehen).

Ausblick in Zukünftige Features

Die im Artikel zum letzten Update bereits erdachten neuen Features erstmal noch hinter dieser aktuellen Iteration an. Für Min- und Maxwerte wurde bereits alles vorbereitet. Außerdem solle eine Jira-Integration geben, einen zwischen allen Spielern synchronisierten Timer und die Punktereihen (Fibonacci, T-Shirtgrößen, etc.) sollen anpassbar werden.

Unser Planning Poker findet ihr unter https://agilecasino.kehrwasser.com und könnt dort einfach kostenlos und ohne Registrierung einem Raum beitreten. Nutzt es gerne und vor allem sagt mir, was ihr davon haltet. Die Regeln für Planning-Poker haben wir hier nochmal zusammengefasst (auch als PDF zum Download).

Artikelbild - Frau hält Cheat Sheet als Poster in die Kamera

Planning Poker Regeln auf einer Seite erklärt [PDF]

3 Antworten

Die Planning Poker Regeln sind einfach. Planning Poker ist eine spielerische, aber durchaus ernstgemeinte Methode Aufwände in agilen Teams zu schätzen. Wir haben die Regeln mal zusammengefasst. Sechs einfache Phasen gibt es. Die Spielregln haben wir auf einer Seite zusammengefasst, zum Download. Auf einen Blick leicht verständlich. Daraus ist eine ganz nette Infografik, ein Cheat Sheet geworden, das sich gut im Team, bei der nächsten Remotesession teilen lässt. Auch ideal zum Ausdrucken und um es ins Office zu hängen.

Als Onlinetool für Planning Poker empfehlen wir das kostenfreie Agile Casino. Das online Planning Poker lässt sich ohne Registrierung in unbegrenzten Runden und mit mehr als 7 Spielern spielen.

Regeln für Schätzpoker

Schritt 1: Das Deck. Jeder Schätzer hält einen Stapel Planungspoker-Karten mit den Werten 0, 1, 2, 3, 5, 8, 13, 21 oder ? in der Hand, was der von uns empfohlenen Reihenfolge entspricht. Die Werte stehen für die Anzahl der Story Points, der idealen Tage oder anderer Einheiten, in denen das Team schätzt.

(Hier können natürlich andere Varianten bevorzugt werden. Zu erwähnen sind T-Shirtgrößen wie S, M, L, XL etc. oder „The Power of 2“, also 1, 2, 4, 16, etc.)

Schritt 2: Diskussion. Die Schätzer diskutieren ein Feature und stellen dem Product Owner bei Bedarf Fragen. Wenn die Funktion vollständig diskutiert wurde, wählt jeder Schätzer für sich eine Karte aus, die seine Schätzung darstellt.

Schritt 3: Aufdecken. Die Runde deckt alle Karten gleichzeitig auf.

Schritt 4: Fertig falls Konsens. Wenn alle Schätzer denselben Wert gewählt haben, wird dieser zum Schätzwert.

Schritt 5: Weiterdiskutieren. Wurde noch kein Konsens erzielt, diskutieren die Schätzer ihre Schätzungen. Insbesondere die Schätzer mit dem höchsten und dem niedrigsten Wert sollten ihre Gründe mitteilen. Nach einer weiteren Diskussion wählt jeder Schätzer erneut eine Schätzkarte aus und alle decken ihre Karten erneut gleichzeitig auf.

Schritt 6: Wiederholen: Der Prozess des Planning Poker wird so lange wiederholt, bis ein Konsens erreicht wurde. Ausnahme: Falls das Team zu der Einschätzung gelangt, über unzureichende Informationen zu Verfügen, kann es die Schätzung eines bestimmten Elements verschieben, bis zusätzliche Informationen vorliegen.

PDF zum kostenfreien Download

Kein Newsletterabo, keine Registrierung: Einfach so downloaden. Es wäre schön, wenn ihr das kostenfreie Scrum-Poker-Tool Agile Casino mal ausprobiert. Es gibt eine deutsche und eine englische Version. Schreibt gerne in die Kommentare, was ihr dazu denkt.

Vorschau Cheat Sheet Planning Poker
Vorschau des Cheat Sheets
scrum-poker-planning-infographic-cheat-sheet.pdf Download [EN-Version]
DE-scrum-poker-planning-infografik-cheat-sheet.pdf Download [DE-Version]

Artikelbild: Frau SRE-DevOps-Expertin angestrahlt mit Code

SRE oder DevOps: Rivalen oder Alliierte?

Schreibe eine Antwort

Die immer schneller werdende Geschäftswelt ist schon seit geraumer Zeit von dem Wort „Agilität“ besessen, wenn es um die Entwicklung von IT-Produkten geht. Und es ist nicht schwer zu verstehen, warum: Die Aussicht, die lang ersehnte Lösung zur Behebung von Problemen so schnell wie möglich zu erhalten, ist und bleibt verlockend.

Die COVID-19-Pandemie hat jedoch gezeigt, dass es nicht mehr ausreicht, einfach nur agil zu sein: Aus dem Transposit-Bericht geht hervor, dass die MTTR (mittlere Reparaturzeit) gestiegen ist (93,6 %), seit die Welt gezwungen ist, ein Remote-Arbeitsmodell einzuführen, wobei die Ausfallzeiten sogar um 68,4 % gestiegen sind!

Wie kann man nun sicherstellen, dass die Agilität nicht länger die Zuverlässigkeit beeinträchtigt? Das sind DevOps und Site Reliability Engineering (SRE). Diese Konzepte gibt es schon seit geraumer Zeit, und angesichts der Herausforderungen, die sich insbesondere im Zuge der Pandemie stellen, sind sie aktueller denn je.

DevOps und SRE wurden in den frühen 2000er Jahren entwickelt, um ein Gleichgewicht zwischen Entwicklungsagilität und Systemstabilität zu finden. Die Begriffe werden jedoch oft falsch verwendet: Manche denken, es handele sich um dasselbe, andere halten sie für konkurrierende Ideen. Die meisten glauben, dass sich ein Unternehmen immer zwischen beiden entscheiden muss. Gehen wir also der Frage auf den Grund, was DevOps und SRE sind und ob eine Debatte zwischen DevOps und SRE überhaupt Sinn macht.

DevOps ist im Kern eine Methodik, die Silos zwischen Entwicklungs-, Test-, Qualitätssicherungs- und Betriebsteams abbaut, um die Anwendungsentwicklung zu beschleunigen, die Softwarequalität zu verbessern, die Verfügbarkeit der Infrastruktur zu erhöhen, die Anwendungsleistung zu maximieren und die Kosten zu senken. All das klingt großartig. Allerdings gibt es ein Problem. DevOps ist im Grunde eine Reihe von abstrakten Prinzipien, von denen viele Unternehmen Schwierigkeiten haben, sie in die Praxis umzusetzen. Um diesen Kampf zu beenden, hat Google 2016 ein Buch mit dem Titel „Site Reliability Engineering“ veröffentlicht, das die internen DevOps-Praktiken beleuchtet, aber vor allem leicht verständliche praktische Ratschläge gibt, wie DevOps funktioniert.

Kurz gesagt: DevOps ist eine Philosophie, und SRE ist eine gute Möglichkeit, diese Philosophie umzusetzen.
Wie trägt SRE zur DevOps-Methodik bei?

Wenn Sie sich das DevOps-Manifest ansehen, werden Sie wahrscheinlich feststellen, dass es 5 Schlüsselkategorien gibt, in die DevOps unterteilt ist, die Mantras der Methodik, wenn Sie so wollen:

  • Beseitigung organisatorischer Silos
  • Akzeptieren von Fehlern als normal
  • Kleine inkrementelle Änderungen einführen
  • Nutzen von Werkzeugen und Automatisierung
  • Alles messen

All diese Punkte sind zweifellos für den Erfolg eines Teams bei der Suche nach einem ausgewogenen Verhältnis zwischen Agilität und Zuverlässigkeit von entscheidender Bedeutung, und wir werden gleich herausfinden, warum. Aber so schön sie auch klingen, sie sehen nicht wie konkrete Anweisungen aus („Alles messen“? Natürlich!). Gehen wir also diese Grundsätze nacheinander durch und sehen wir, wo der Unterschied zwischen DevOps und SRE wirklich liegt.
DevOps-Ideen und SRE-Implementierung
Aufhebung der organisatorischen Silos

DevOps-Idee: Die Kommunikation zwischen den Personen, die für die Programmierung zuständig sind (Entwickler), und den Personen, die die Wartungsdienste erbringen (Betreiber), muss nahtlos sein, um zu verhindern, dass schnelle Änderungen am Code die Infrastruktur beschädigen und die Stabilität des Systems ernsthaft gefährden. Ursprünglich sollte DevOps die Mauer zwischen Entwicklungs- und Betriebsteams durchbrechen, hat sich aber schnell über die Softwarebereitstellungspipeline hinaus auf Bereiche wie Sicherheit, Finanzen, HR, Marketing, Vertrieb usw. ausgebreitet, in denen eine Zusammenarbeit unerlässlich ist.

SRE-Implementierung: Sie müssen ein engmaschiges, funktionsübergreifendes Team aufbauen, indem Sie nicht nur Entwickler und Operatoren zusammenbringen, sondern auch synergiefördernde Praktiken auf die Bereiche Finanzen, Personalwesen, Führungsteams usw. ausweiten. Die Kultur der besseren Kommunikation und des Wissensaustauschs, die DevOps und SRE von Natur aus erfordern, kann durch häufige Stand-ups geschaffen werden, während Integration und Automatisierung mit speziellen Toolsets umgesetzt werden sollten.
Scheitern als normal akzeptieren

DevOps-Gedanke: Kein von Menschen geschaffenes System kann zu 100 % zuverlässig sein, daher sollte ein Ausfall des besagten Systems von keinem Unternehmen als Katastrophe empfunden werden, sondern als Normalität behandelt werden… solange daraus eine Lehre gezogen wird.

SRE-Implementierung: Sie müssen sich intern darauf einigen, wie viel Ausfallzeit unter den gegebenen Umständen akzeptabel ist, und darauf vorbereitet sein, Systemausfälle schnell zu bewältigen (da sie unvermeidlich sind und nicht überraschend kommen sollten); eine Möglichkeit, dies zu tun, ist die Durchführung so genannter „schuldloser Post-Mortems“, bei denen keine Zeit damit verschwendet wird, die Schuldigen für den Ausfall zu suchen. Stattdessen sucht das Team routinemäßig nach Möglichkeiten zur Verbesserung des Systems und konzentriert sich dabei auf die Zukunft, nicht auf die Vergangenheit.

DevOps-Idee: Häufige, aber kleine Änderungen am Code helfen, schneller auf Probleme zu reagieren und Fehler einfacher zu beheben. Und warum? Das ist ganz einfach. Die Suche nach einem Fehler in 100 Codezeilen ist viel einfacher als in 100.000 Codezeilen. Außerdem ist der Entwicklungsprozess dadurch generell viel flexibler und kann auf plötzliche Änderungen reagieren.

SRE-Implementierung: Sie müssen beachten, dass es nicht auf die tatsächliche Anzahl der Deployments pro Tag ankommt. Das Streben nach einer übermäßigen Anzahl von Deployments nur um der Deployments willen ist vergebliche Mühe. Sie sollten in der Tat häufig deployen, aber auch dafür sorgen, dass diese Deployments sinnvoll sind – je sinnvoller die Art des Deployments ist, desto einfacher ist es, einen potenziellen Fehler zu beheben, und desto geringer sind die Kosten für Fehlschläge.
Von Tools und Automatisierung profitieren

Die DevOps-Idee: Es liegt in der menschlichen Natur, dass wir monotone Aufgaben nicht effizient ausführen können. Genauso wie es viel Zeit und Energie kostet, wichtige Arbeitsabläufe manuell zu erledigen, können Unternehmen, die Tools und Automatisierung nutzen, diese Prozesse exponentiell verbessern.

SRE-Implementierung: Sie sollten sich überlegen, welche langfristigen Verbesserungen am System vorgenommen werden müssen, und die Aufgaben automatisieren, die in einem Jahr oder in ein paar Jahren regelmäßig anfallen werden (SRE nennt dies „die Arbeit von diesem Jahr weg automatisieren“). Auf diese Weise vermeiden Sie Investitionen in kurzfristige Gewinne und konzentrieren sich auf die langfristige Automatisierung.

DevOps-Idee: Konkrete Metriken, die verschiedene Aspekte Ihres Entwicklungsprozesses messen, helfen nicht nur dabei, festzustellen, ob das Unternehmen erfolgreich an einem bestimmten Projekt arbeitet, sondern liefern auch eine Rechtfertigung für diese oder jene Geschäftsentscheidung.

SRE-Implementierung: Sie sollten Service-Level-Agreements (SLA), Service-Level-Ziele (SLO) und Service-Level-Indikatoren (SLI) verwenden, die mittlere Zeit zwischen zwei Ausfällen (MTBF) und die mittlere Wiederherstellungszeit (MTTR) des Systems verfolgen und ein Fehlerbudget festlegen. So können Sie Ihr Projekt wesentlich effizienter gestalten.

Wir werden in Kürze näher darauf eingehen, was einige der Begriffe im obigen Absatz tatsächlich bedeuten, aber der Rest des Bildes sollte inzwischen mehr als deutlich sein. DevOps wurde geschaffen, um die IT-Entwicklung besser zu machen. In der Zwischenzeit sollte SRE zeigen, WIE genau wir das tun sollten. Wie viele SRE-Spezialisten zu sagen pflegen, „SRE implementiert DevOps“.

SRE als Konzept ist ohne Service-Level Agreement (SLA), Service-Level Objective (SLO), Service-Level Indicator (SLI) kaum vorstellbar. Wie bereits erwähnt, handelt es sich hierbei um die zentralen Begriffe, die sich in vielerlei Hinsicht auf die Messung des Erfolgs Ihrer SRE-Implementierung beziehen. Und genau wie die Namen dieser Konzepte sind auch ihre Eigenschaften einander sehr ähnlich, allerdings mit einigen entscheidenden Unterschieden:

  • SLA wird als Vereinbarung zwischen dem Service Provider und dem Kunden über Kennzahlen wie Betriebszeit, Ausfallzeit, Reaktionsfähigkeit, Verantwortlichkeiten usw. bezeichnet. Mit anderen Worten, es handelt sich um eine Reihe von Versprechen an den Kunden, die durch verschiedene Messgrößen dargestellt werden, sowie um eine Reihe von Konsequenzen, wenn diese Versprechen nicht eingehalten werden;
  • SLO wird wiederum als Vereinbarung innerhalb eines SLA über eine bestimmte Kennzahl bezeichnet, z. B. Betriebszeit oder Antwortzeit. Im Grunde ist ein SLO ein individuelles Versprechen an den Kunden. In dieser Hinsicht kann man ein SLA also als eine bestimmte Gruppe von SLOs betrachten;
  • Der SLI schließlich ist ein Indikator, der anzeigt, ob das System in Übereinstimmung mit diesem oder jenem SLO funktioniert.

Ein typisches Beispiel für das Zusammenspiel dieser drei Begriffe wäre etwas in dieser Art: Ein SLA, das Sie mit Ihrem Kunden abgeschlossen haben, besagt, dass das System 99,9 % der Zeit verfügbar sein wird (die so genannten „drei Neunen der Verfügbarkeit“), es würde also die SLO enthalten, die 99,9 % Betriebszeit bedeuten würde, und die SLI wäre die tatsächliche Messung der Betriebszeit des Systems.
Welche Arten von Unternehmen brauchen SRE und DevOps?

In Anbetracht der Tatsache, dass DevOps und SRE dazu da sind, Entwicklungsteams bei der Sicherstellung einer hohen Systemstabilität zu unterstützen und gleichzeitig sehr agil zu sein, kann man relativ sicher sagen, dass jedes Entwicklungsunternehmen bis zu einem gewissen Grad wissen sollte, was DevOps/SRE-Techniken sind und wie man sie implementiert. Sie sind das A und O der modernen Softwareentwicklung.

In unseren früheren Beiträgen haben wir uns bereits mit den Vorteilen von DevOps für große Produktionsunternehmen und den massiven Auswirkungen auf die Finanzdienstleistungsriesen befasst, aber die Genialität von DevOps und SRE liegt in ihrer universellen Anwendbarkeit – Ihr Unternehmen muss KEIN Softwareentwicklungsunternehmen sein, um von diesen Praktiken zu profitieren; solange Sie mit Update-Rollouts, Infrastrukturänderungen, Wachstum und Upscaling zu tun haben, können Sie sich mit dieser Philosophie beschäftigen.

Und tatsächlich ist kein Team zu klein für DevOps/SRE. Wenn Sie ein kleines Unternehmen sind, brauchen Sie nicht einmal einen speziellen SRE-Spezialisten. In diesem Fall kann es sich lohnen, eines Ihrer Teammitglieder in der Anwendung der SRE-Methode zu schulen, da die Lernkurve nicht so hoch ist.

Wenn man all dies berücksichtigt, kann man leicht zu dem Schluss kommen, dass die Ideen und Konzepte hinter DevOps und SRE für jedes Unternehmen interessant sind – ob Großunternehmen oder kleines StartUp, ob IT oder Nicht-IT, sie sind für jeden geeignet.

Bei dem Versuch, die Debatte zwischen Site Reliability Engineering und DevOps zu klären, können wir nun mit Sicherheit sagen, dass es keinen Sinn hat, entweder oder zu sagen. Wie können wir hier überhaupt von einer Debatte sprechen, wenn die beiden Dinge, die wir verzweifelt versuchen, einander gegenüberzustellen, praktisch dasselbe sind, wobei das eine ein wesentlicher Bestandteil des anderen ist?

Wenn Sie sagen, dass Sie DevOps gut machen können, ist es wahrscheinlich, dass Sie das mit Hilfe von SRE-Prinzipien tun.

Wenn Sie sagen, dass Sie SRE gut machen können, sollten Sie wissen, dass wir technisch gesehen über DevOps sprechen.

Es handelt sich also keineswegs um ein „rote Pille-blaue Pille“-Szenario. Sowohl DevOps als auch SRE sind zu begrüßen, und wir sind sehr gespannt, wie sich beide in den kommenden Jahren entwickeln werden.

Interessieren Sie sich für SRE und DevOps? Sprechen Sie mit unseren DevOps – Experten, um herauszufinden, wie DevOps und SRE Ihnen helfen können, neue Geschäftsmöglichkeiten zu erschließen.

Artikeltext: Ein Schloss als Symbol für Passwortsicherheit

Warum das Passwort noch nicht ganz tot ist

Schreibe eine Antwort

BRINGEN SIE IHRE VERWANDTEN DAZU, IHRE PASSWÖRTER ZU ÄNDERN –
Jeder hasst die alten Methoden der Authentifizierung. Doch der Wandel bringt auch Nachteile mit sich.

Es gibt bestimmte Science-Fiction-Versprechen, die die Zukunft bereithalten soll: Jetpacks, fliegende Autos, eine Marskolonie. Aber es gibt auch einige scheinbar leichter zu erreichende Ziele, die sich irgendwie immer nur am Horizont abzeichnen. Und eines der verlockendsten ist das Ende der Passwörter. Die gute Nachricht ist, dass die Infrastruktur – für alle wichtigen Betriebssysteme und Browser – weitgehend vorhanden ist, um die passwortlose Anmeldung zu unterstützen. Die weniger gute Nachricht? Sie geben immer noch jeden Tag Passwörter für mehrere Websites und Dienste ein, und das wird auch noch eine Weile so bleiben.

Es besteht kein Zweifel daran, dass Passwörter ein absoluter Sicherheitsalbtraum sind. Das Erstellen und Verwalten von Passwörtern ist lästig, daher werden sie oft wiederverwendet oder leicht zu erratende Logins gewählt – oder beides. Hacker machen sich das nur zu gern zunutze. Im Gegensatz dazu erfolgt die Authentifizierung bei passwortlosen Anmeldungen anhand von Merkmalen, die angeboren und schwerer zu stehlen sind, z. B. biometrischen Merkmalen. Keiner wird Ihren Daumenabdruck erraten.

Wahrscheinlich verwenden Sie bereits eine Version davon, wenn Sie Ihr Telefon entsperren, z. B. mit einem Scan Ihres Gesichts oder Ihres Fingers anstelle eines Passcodes. Diese Mechanismen funktionieren lokal auf Ihrem Telefon und machen es nicht erforderlich, dass Unternehmen einen großen Bestand an Benutzerpasswörtern – oder Ihre sensiblen biometrischen Daten – auf einem Server speichern, um Anmeldungen zu überprüfen. In bestimmten Fällen können Sie jetzt auch eigenständige physische Token verwenden, um sich drahtlos und ohne Passwort anzumelden. Die Idee ist, dass man das irgendwann für so ziemlich alles machen kann.

„Alle Bausteine haben einen Reifegrad erreicht, der es ermöglicht, dass sie von technikbegeisterten Early Adopters zum Mainstream übergehen“, sagt Mark Risher, Senior Director of Product Management für Identitäts- und Sicherheitsplattformen bei Google. „Sie haben eine starke Plattformunterstützung, sie funktionieren bei allen großen Anbietern und sie werden den Nutzern immer vertrauter. Früher wussten wir als Branche nicht einmal, wie man Passwörter loswerden kann. Jetzt wird es einige Zeit dauern, aber wir wissen, wie wir es machen.“

Ende Juni kündigte Microsoft mit Windows 11 eine tiefere Integration der passwortlosen Anmeldung an, insbesondere für die Anmeldung bei Geräten, die biometrische Daten oder eine PIN verwenden. In ähnlicher Weise kündigte Apple einige Wochen zuvor an, dass seine neuen Betriebssysteme iOS 15 und macOS Monterey eine neue Option namens Passkeys in den iCloud-Schlüsselbund integrieren werden, ein Schritt in Richtung der Verwendung von biometrischen Daten oder Geräte-PINs zur Anmeldung bei mehr Diensten. Und im Mai sprach Google über seine Bemühungen, eine sichere Passwortverwaltung zu fördern, während es gleichzeitig daran arbeitet, die Kunden von Passwörtern wegzubringen.

Trotz dieser und anderer Bemühungen der Branche, sowohl Entwickler als auch Nutzer für eine Welt ohne Passwörter zu gewinnen, bleiben jedoch zwei große Herausforderungen bestehen. Zum einen werden Passwörter zwar allgemein verachtet, sind aber auch sehr vertraut und in absurder Weise allgegenwärtig. Es ist nicht einfach, jahrzehntelang gewachsene Gewohnheiten zu durchbrechen.

„Es ist ein erlerntes Verhalten – das erste, was man tut, ist ein Passwort einzurichten“, sagt Andrew Shikiar, Geschäftsführer der FIDO Alliance, eines langjährigen Branchenverbands, der sich speziell mit sicherer Authentifizierung beschäftigt. „Das Problem ist also, dass wir von einer wirklich schlechten Grundlage abhängig sind. Was wir tun müssen, ist, diese Abhängigkeit zu durchbrechen.

Es war eine schmerzhafte Entgiftung. Eine FIDO-Arbeitsgruppe hat sich im vergangenen Jahr mit der Benutzererfahrung befasst, um Empfehlungen nicht nur für die passwortlose Technologie selbst, sondern auch für die Art und Weise zu geben, wie sie normalen Menschen präsentiert werden kann, damit sie die Sicherheitsvorteile besser verstehen. Die FIDO sagt, dass Organisationen, die ihre Standards für passwortlose Systeme umsetzen, Schwierigkeiten haben, die Benutzer dazu zu bringen, die Funktion tatsächlich anzunehmen. Daher hat die Allianz Richtlinien für die Benutzererfahrung veröffentlicht, die ihrer Meinung nach bei der Gestaltung und Präsentation helfen werden. „‚Wenn du es baust, werden sie kommen‘ ist nicht immer ausreichend“, schrieb Shikiar letzten Monat.

Die zweite Hürde ist noch schwieriger. Selbst wenn all diese Elemente vorhanden sind, funktionieren viele passwortlose Systeme nur auf neueren Geräten und erfordern den Besitz eines Smartphones und mindestens eines weiteren Geräts. In der Praxis ist das ein ziemlich begrenzter Anwendungsfall. Viele Menschen auf der ganzen Welt teilen sich Geräte und können sie nicht häufig aufrüsten, oder sie verwenden, wenn überhaupt, nur Funktionstelefone.

Und während passwortlose Implementierungen zunehmend standardisiert werden, gilt dies nicht für Optionen zur Wiederherstellung von Konten. Wenn Sicherheitsfragen oder eine PIN als Backup-Optionen dienen, verwenden Sie im Grunde immer noch Passwörter, nur in einem anderen Format. Daher bewegen sich passwortlose Systeme hin zu Systemen, bei denen ein Gerät, das Sie zuvor authentifiziert haben, ein neues als vertrauenswürdig einstufen kann.

„Nehmen wir an, Sie lassen Ihr Telefon im Taxi liegen, haben aber noch Ihren Laptop zu Hause“, sagt Risher von Google. „Sie besorgen sich ein neues Telefon und verwenden den Laptop, um das Telefon zu segnen, und können sich so gewissermaßen wieder aufbauen. Und wenn dann jemand Ihr verlorenes Telefon findet, ist es immer noch durch die lokale Gerätesperre geschützt. Wir wollen das Passwortproblem nicht einfach auf die Kontowiederherstellung abwälzen.

Es ist sicherlich einfacher, als die Codes für die Wiederherstellung von Sicherungskopien auf einem Zettel zu notieren, aber auch hier stellt sich die Frage, welche Optionen für Personen geschaffen werden sollen, die nicht mehrere persönliche Geräte verwalten wollen oder können.

Da sich die passwortlose Nutzung immer mehr durchsetzt, bleiben diese praktischen Fragen über den Übergang bestehen. Der Passwort-Manager 1Password, der natürlich ein geschäftliches Interesse daran hat, dass Passwörter weiterhin verwendet werden, sagt, dass er die passwortlose Authentifizierung überall dort, wo sie sinnvoll ist, gerne unterstützt. Auf Apples iOS und macOS können Sie beispielsweise Ihren 1Password-Tresor mit TouchID oder FaceID entsperren, anstatt Ihr Hauptpasswort einzugeben.

Es gibt jedoch einige feine Unterschiede zwischen dem Master-Passwort, das einen Passwortmanager sperrt, und den darin gespeicherten Passwörtern. Die vielen Passwörter im Tresor werden alle zur Authentifizierung bei Servern verwendet, die ebenfalls eine Kopie des Passworts speichern. Das Master-Kennwort, das Ihren Tresor verschließt, ist allein Ihr Geheimnis; 1Password selbst kennt es nicht.

Diese Unterscheidung macht die passwortlose Anmeldung, zumindest in ihrer aktuellen Form, für einige Szenarien besser geeignet als für andere, sagt Akshay Bhargava, Chief Product Officer von 1Password. Er weist auch darauf hin, dass einige seit langem bestehende Bedenken gegenüber Passwortalternativen bestehen bleiben. Zum Beispiel sind biometrische Daten in vielerlei Hinsicht ideal für die Authentifizierung, da sie buchstäblich Ihre einzigartige physische Präsenz vermitteln. Die breite Verwendung biometrischer Daten wirft jedoch die Frage auf, was passiert, wenn Daten über beispielsweise Ihre Fingerabdrücke oder Ihr Gesicht gestohlen werden und von Angreifern manipuliert werden können, um sich als Sie auszugeben. Und während Sie Ihr Passwort aus einer Laune heraus ändern können – ihre beste Eigenschaft als Authentifikatoren – sind Ihr Gesicht, Ihr Finger, Ihre Stimme oder Ihr Herzschlag unveränderlich.

Es wird Zeit und weitere Experimente brauchen, um ein passwortloses Ökosystem zu schaffen, das alle Funktionen von Passwörtern ersetzen kann, vor allem eines, das die Milliarden von Menschen, die kein Smartphone oder mehrere Geräte besitzen, nicht zurücklässt. In einer passwortlosen Welt ist es schwieriger, Konten mit vertrauenswürdigen Personen zu teilen, und alles an ein Gerät wie das Telefon zu binden, schafft noch mehr Anreize für Hacker, dieses Gerät zu kompromittieren.

Bis zur vollständigen Abschaffung von Passwörtern sollten Sie immer noch die Ratschläge befolgen, die WIRED seit Jahren gibt: Verwenden Sie starke, eindeutige Passwörter, einen Passwortmanager (es gibt viele gute Optionen) und eine Zwei-Faktor-Authentifizierung, wo immer Sie können. Wenn Sie jedoch die Möglichkeit sehen, bei einigen Ihrer sensibelsten Konten auf Passwörter zu verzichten, wie z. B. bei der Einrichtung von Windows 11, sollten Sie es ausprobieren. Vielleicht spüren Sie eine Erleichterung, von der Sie nicht einmal wussten, dass es sie gibt.

Low-Level: Configure Angular-Apps on different environments [How-To]

Schreibe eine Antwort

Disclaimer for german readers: Dieser Artikel beschäftigt sich mit technischen Details. Falls sie auf der Suche nach Heigh-Level-Erklärungen sind, werden Sie in andern Artikeln eher fündig.

It shouldn’t take a rebuild to reconfigure an app for a certain environment. It should be build once and in each deployed state (test, nightly, demo, pre-prod, staging, prod, etc) have the configuration that applies on the server, respectivly environment.

The most common way to configure an app in a certain environment is by using environment variables. You can easily set them through .env files in Docker, Vagrant, AWS and other service providers.

To archive that, let’s start at the server side: A JavaScript-application runs on a webserver. It consists out of plain text files. While running on a client’s browser, there is now way for the JavaScript to access server values such as environment variables during runtime.

We need to inject the values, that life inside our server into the text files of our JavaScript application.

First, prepare a file called env.template.js with the environment variables you expect.

(function (window) {
    window["env"] = window["env"] || {};

    // Environment variables TEMPLATE
    window["env"]["title"] = "${TITLE}"; 
})(this);

And again, there is no pre-existing mechanism. Here we can see, we prepare that file with placeholders ${XYZ} as strings. To inject the environment variables, that live on the server and thus can be differ from one environment to another.

To create a mechanism we need to run the following command on the server (this can be done during the deployment process to a certain environment, e.g. in an CI/CD-pipeline.

envsubst < /home/nonroot/htdocs/assets/env.template.js > /home/nonroot/htdocs/assets/env.js

What this does is, it takes all the environment variables, set to a certain value currently on the machine, and replaces all the placeholders ${XYZ} that match.

For example if there was an environment variable TITLE set to "This is a title", then any occurance of ${TITLE} inside the file would be replaced by „This is a title“ (without the quotes). After that the new resulting file is written into a new file, here 

/home/nonroot/htdocs/assets/env.js

The contents of the new file would look like the following snippet shows.

(function (window) {
    window["env"] = window["env"] || {};

    // Environment variables TEMPLATE
    window["env"]["title"] = "This is a title"; 
})(this);

That is what we wanted to have. We had no pre-existing mechanism, that lets us access the environment variables on the server inside a certain environment. Now we have injected them very clean into our application.

We have them available, how to process them in our application?

There is nothing wrong with simply including the env.js file in our index.html, right into the header (of course you can export and import it, which would be slightly cleaner).

Now, if the environemnt variable TITLE was declared on the machine the scripts are running on, window['env']['title'] should hold the value, in our case "This is a title" as string. Globaly, everywhere in our application (maybe some kind of anti-pattern, you have the force. Seal it with dependency injection and so on) Easy?

Use the environment variable inside the environment files

The environment file in angular are a bit misleading. The implay, that you should have one file for each environment. I just look at environment.ts and environment.prod.ts. In the latter we can use our window[„env“] variable now.

export const environment = {
  production: true,
  title: window['env']['title'] || 'A default value for a title',
};

That’s it. Comment if you like.