Archiv der Kategorie: Technologien

Überblick: Voraussetzungen für skalierbare Softwaresysteme

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.

Businesssoftware: Tausendsassa oder lieber Spezialsoftware?

Viele glauben, dass eine Businesssoftware nur dann lohnenswert und wirklich „gut“ ist, wenn sie alle Geschäfts- oder Aufgabenbereiche abdecken kann. Sicher, ein Komplettpaket ist schnell eingerichtet und hat alles an Bord, was Sie brauchen – aber das macht es nicht automatisch zur Ideallösung. Tatsächlich sind spezialisierte Cloudanwendungen oft sinnvoller und schlichtweg besser. Die Gründe dafür lesen Sie im Folgenden.  

1. Innovationen

Spezialisierung begünstigst Innovation. Ein Beispiel: Jira ist eine Projektmanagementanwendung aus dem Hause Atlassian, die ursprünglich zur Problembehandlung eingesetzt wurde. Mittlerweile hat sich die Spezialsoftware zu einer der erfolgreichsten Anwendungen auf dem Gebiet des Prozess- und Aufgabenmanagements entwickelt. Eine beliebte Alternative ist Microsoft Project, allerdings ist dieses an die Office Suite gebunden und damit weniger innovationsfreudig.

Wenn wir uns die globalen Google-Suchanfragen für Jira und MS Project in den letzten zwei Jahren ansehen, wird schnell ersichtlich, wer von den beiden buchstäblich gefragter ist:

2. Flexibilität

Eine Businesssoftware, die alles kann, klingt zunächst ja gar nicht so verkehrt. Die Frage ist aber: Wie flexibel sind Sie damit noch? Überlegen Sie sich gut, ob Sie sich dauerhaft an eine einzige Software binden möchten, denn dadurch machen Sie sich auch von deren Preisen und Leistungen abhängig.

Wieder das klassische Office-Beispiel: Wer sich die Office Suite von Microsoft zulegt, kauft automatisch auch Publisher und Access mit. Für diejenigen, die diese Tools gar nicht benötigen, lohnt sich der Kauf also nur teilweise. Ein anderes Problem ergibt sich, wenn Sie die Tools zwar nutzen, aber deren Funktionsumfang irgendwann nicht mehr ausreicht. Was passiert dann mit der Office Suite? Wenn Sie Word, Excel und Co weiterhin nutzen möchten, müssen Sie auch Access weiterzahlen – plus das Nachfolgertool.

Noch komplizierter wird die Angelegenheit, wenn die Software mehrere Geschäftsbereiche verknüpfen soll. Ohne Flexibilität werden Sie hier sehr schnell an finanzielle oder funktionelle Grenzen stoßen (ganz zu schweigen von dem Risiko, dass Sie all Ihre Prozesse von einem einzigen Anbieter abhängig machen).

Die Lösung? Nutzen Sie für jeden Bereich Ihrer Geschäftsplanung eine flexible Spezialsoftware. Anregungen und Beispiele wären:

3. KISS-Prinzip

Eine zentrale Philosophie aus der Softwareentwicklung ist die sogenannte KISS-Regel (engl. Keep it simple, stupid). Sie besagt, dass ein Problem immer so einfach wie möglich gelöst werden sollte, was im Kern der Aussage von Ockhams Rasiermesser ähnelt. Übertragen heißt das: Spezialisierte Cloudanwendungen werden Ihr Problem höchstwahrscheinlich einfacher lösen als eine komplette Suite für eintausend verschiedene Bereiche.

Investieren Sie lieber etwas Zeit in die richtige Wahl einer Spezialsoftware, als dass Sie sich einen Allrounder zulegen, dessen Funktionsumfang weit über das eigentliche Problem hinausgeht. Da Sie für all diese Funktionen bezahlen, ist eine Spezialsoftware (vor allem modular) in der Regel günstiger.

4. Benutzerfreundlichkeit

Unter Entwicklern und UX Designern gibt es eine Regel, die sich das „Prinzip der geringsten Überraschung“ nennt (engl. Rule of Least Surprise). Aus Nutzersicht ist damit gemeint, dass eine Software möglichst intuitiv gestaltet sein sollte und alle Buttons und Shortcuts genau das tun, was sie auch überall sonst tun.

Behalten Sie diese Regel im Hinterkopf, wenn Sie sich zwischen einer Business Suite und einer spezialisierten Anwendung entscheiden. Eine Suite ist grundsätzlich komplexer im Umfang und damit auch in der Bedienung. Erfahrungsgemäß ist die Lernkurve bei Spezialsoftware mäßiger, weil ihr Schwerpunkt auf einer guten Backend-Steuerung liegt.

Zusammenfassung

All-inclusive ist ein hervorragendes Konzept für den nächsten Urlaub, aber nicht beim Thema Businesssoftware. Bevor Sie sich also für eine Suite entscheiden, fragen Sie sich, ob Sie die Inhalte und Funktionen wirklich benötigen. Spezialisierte Cloudanwendungen sind schlanker, bedienungsfreundlicher und problemfokussierter, was sich letztendlich in einer besseren Preis-Leistung niederschlägt. Vor allem aber bleiben Sie damit flexibel – und das ist einer der wichtigsten Erfolgsfaktoren überhaupt.

Websites ohne Code: Was kann Elementor?

Websites lassen sich heutzutage ohne eine einzige Codezeile entwickeln. Treiber dieser Nocode-Revolution sind sogenannte Baukastensysteme, die es Anwendern ermöglichen, Webseiten visuell über vorgefertigte Bausteine zusammenzustellen. Marktführer in dieser Branche ist das WordPress-Plugin Elementor – ein mächtiger Page-Builder, der professionelle Websites in Nullkommanichts aus dem Boden stampft. Wir erklären Ihnen, was Elementor alles kann und warum er auch für Softwareentwickler hilfreich ist.

Elementor: Grundlagen, Funktionen, Einsatzzwecke

Webbaukästen wie Elementor enthalten bereits eine grafische Oberfläche (GUI) sowie eine Reihe an Elementen und Vorlagen, um eine Webseite nach dem WYSIWYG-Prinzip zu bauen. Sprich: Bausteine und Inhalte werden direkt auf der Seite bearbeitet statt im Quellcode („Live Editing“). Elementor bietet dafür eine praktische Drag & Drop-Funktionalität, mit der das Anordnen und Anpassen der einzelnen Elemente zu einem Kinderspiel wird.

Eine Besonderheit von Elementor ist, dass der Page-Builder nicht nur statische Seiten, sondern auch dynamische Templates erstellen kann. Das beginnt bei der aktuellen Jahreszahl im Copyright-Hinweis und endet bei spezifischen Popups, wenn jemand auf ein bestimmtes Feld klickt. Außerdem liefert das Plugin ein eingebautes „Responsive Editing“, mit dem Sie Ihre Seiten und Elemente für verschiedene Auflösungen steuern können.

Wie unterscheiden sich die Free- und die Pro-Version?

Für Elementor-Starter dürfte sich zunächst die Frage stellen, ob die kostenlose Basisversion für die eigenen Zwecke ausreicht oder ob der Griff zur Pro-Version (ab 49 Dollar/Jahr) sinnvoll ist. Wie nicht anders zu erwarten, ist die Auswahl an Funktionen und Vorlagen in der kostenlosen Variante stark begrenzt. Die folgenden Punkte erläutern die wichtigsten Unterschiede:

  • Templates: Templates sind Design-Vorlagen für einzelne Seiten (z.B. Landing Pages oder Beiträge). Eine große Auswahl kann Ihnen hier nur die Pro-Version bieten.
  • Widgets: Elementor Free liefert um die 40 Basis-Widgets für einfache Websites. In der Pro-Version erhalten Sie dutzende weitere, darunter auch Theme-Elemente (für Header, Footer, 404-Seiten usw.) und Widgets für WooCommerce.
  • Kits: Elementor Kits sind Layout-Packs mit mehreren Templates für eine komplette Website. In der Basisversion können Sie zwischen fünf Kits wählen, während die Pro-Version über 100 Kits bereitstellt.
  • Dynamische Inhalte: Die bereits angesprochenen dynamischen Inhalte und Tags sind nur für Pro-Nutzer verfügbar.
  • Builder-Tools: Den Drag & Drop Builder können Sie in beiden Versionen nutzen. Weitere Builder wie den Theme Builder, Popup Builder oder WooCommerce Builder gibt es ausschließlich bei Elementor Pro.

Zusammenfassend lässt sich sagen: Für einfache, statische Seiten wird Ihnen die kostenlose Version genügen. Falls Sie jedoch komplexere Inhalte benötigen oder sogar ein Shopsystem mit WooCommerce planen, kommen Sie um die Pro-Version nicht herum.

Vorteile von Elementor in der Softwareentwicklung

Elementor oder Page Builder im Generellen sind in erster Linie für Personen gedacht, die keine oder wenige Programmierkenntnisse mitbringen. Doch selbst für versierte Web Developer bieten Nocode-Entwicklungsumgebungen große Vorteile, da sie den Webentwicklungsprozess deutlich beschleunigen. Vorgefertigte Bausteine sind schnell anpassbar und in der Anwendung oft sicherer und stabiler als neu programmierter Code. Da Elementor open source ist, können Sie das Plugin mit individuellen Add-ons erweitern, ohne den Aufwand einer kompletten Websiteerstellung zu haben oder andere Plugins hinzuziehen zu müssen. Die Vorteile von Elementor auf einen Blick:

  • Intuitive Bedienung dank des visuellen Frontend Editings (auch für Neulinge)
  • Erweiterbarkeit für Developer mithilfe des Theme Builders
  • Sehr viele Designeinstellungen und einfachste Bearbeitungsoptionen
  • Globale Widgets, die über mehrere Websites hinweg verwendet werden können
  • E-Commerce Integration sowie eingebaute Marketing-Tools
  • Große Developer-Community für zusätzliche Seitenvorlagen oder Add-ons

Zusammenfassung

Elementor ist ein hochfunktionaler Page-Builder für WordPress-Seiten, der mit rein visuellen Elementen statt Quellcode-Programmierung arbeitet. Für Entwickler bietet diese Nocode-Lösung erhebliche Zeit- und Ressourcenvorteile, da im Grunde nur noch die Feinheiten angepasst werden müssen – und selbst diese erfordern nur marginale bis gar keine Code-Skills.

Wer glaubt, dass sich damit nur einfachste Seiten bauen lassen, hat sich getäuscht: Elementor Pro liefert auch komplexe Webfunktionalitäten, sei es das Erstellen dynamischer Templates oder die Integration von WooCommerce-Elementen. Diese extrem hohe Flexibilität ist einer der Gründe, warum Elementor zu Recht der erfolgreichste und am häufigsten genutzte Page-Builder für WordPress ist.

Plattformen: Geschäftsmodell in unter 100 Wörtern erklärt

Plattformen sind das Herzstück der Digitalisierung. Tagtäglich kommen wir als Nutzer mit ihnen in Verbindung: Marktplätze wie eBay und Amazon, Suchmaschinen wie Google, soziale Netzwerke wie Facebook. Zwar sieht die Plattformlandschaft in den USA etwas anders als in Deutschland, aber auch bei uns floriert das Platform Business – besonders im B2B. Wir bringen auf den Punkt, was das Geschäftsmodell so erfolgreich macht.

Die Definition eines Plattformgeschäfts

Ein Plattformunternehmen ist ein Geschäftsmodell, das Interaktionen zwischen einer Vielzahl von Teilnehmern erleichtert. Bei diesen Interaktionen kann es sich sowohl um kurzfristige Verbindungen (v.a. im Customerbereich) als auch um den Aufbau langfristiger Beziehungen bzw. Kooperationen handeln. Die Aufgabe des Plattformunternehmens besteht darin, eine Governance-Struktur und eine Reihe von Standards und Protokollen bereitzustellen, um Anbieter, Kunden und Tools zusammenzubringen. Das heißt: Ein Plattformgeschäft bietet in der Regel keine eigenen Produkte oder Dienstleistungen an, sondern stellt lediglich eine Schnittstelle – die Plattform – für die Marktteilnehmer zur Verfügung. Aus dem komplexen Zusammenspiel von Anbietern und Kunden ergeben sich letztlich sogenannte Netzwerkeffekte.

Welche Arten von digitalen Plattformen gibt es?

Der erste Schritt in der Beratung von Plattformgeschäften ist, herauszufinden, welche Art Plattform die eigenen Anforderungen am besten erfüllt. Dazu ein grober Überblick:

Transaktionszentrierte Plattformen

Bei diesen Plattformen geht es um die reine Transaktion (Kauf, Tausch, Angebot). Sie führen ein breites Spektrum relevanter Ressourcen zusammen und vereinfachen den Austausch und Handel zwischen allen beteiligten Akteuren. Beispiele sind digitale B2C- und B2B-Marktplätze sowie On-Demand-Services wie Uber oder Paypal.

Soziale Plattformen

Im Mittelpunkt von sozialen Plattformen – etwa Facebook oder Wikipedia – steht nicht die Abwicklung einer Transaktion, sondern die Interaktion zwischen Interessengruppen. Bei dieser Art Plattform können die Rollen der Teilnehmer überlappen oder wechseln: Anbieter sind auch Kunden, Kunden sind auch Anbieter (Multi-Side-Effekt).

Datenzentrierte Plattformen

Charakteristisch für diese Plattformen ist eine datenbasierte Vernetzung. Man unterscheidet dabei zwischen Aggregatoren- und Technologie-Plattformen. Erstere sammeln Daten oder nutzen eigene Datenbestände, um daraus neue Angebote zu erstellen, wie es beispielsweise Amazon oder Google tun. Zweitere bieten Infrastrukturen für einen systemübergreifenden Datenaustausch. Beispiele für solche IoT- oder Utility-Plattformen sind Siemens Mindsphere oder Bosch IoT Suite.

Welche Vorteile haben digitale Plattformen?

Klassische „Pipeline“-Geschäftsmodelle basieren auf einer linearen Wertschöpfungskette: Aus einem Rohstoff wird ein Produkt, das wir am Markt an den Kunden verkaufen. Das Problem an diesen Systemen ist, dass sie schwer zu skalieren sind. Wachstum lässt sich nur mit einem überproportional großen Mehraufwand und auch nur bis zu einer gewissen Grenze erzeugen, während das Prozessmanagement immer komplexer wird.

Plattformökosysteme haben diese Einschränkungen nicht. Darüber hinaus bieten sie zahlreiche Vorteile, die in der heutigen digitalen Geschäftswelt immer unerlässlicher werden:

  • Niedrige Transaktionskosten: Kennzeichnend für digitale Plattformen sind zwar relativ hohe Fixkosten, aber nur geringe marginale Kosten für zusätzliche Kunden.
  • Hohe Skalierbarkeit: Eine virtuelle Plattform, die selbst nur als Intermediär agiert und feste Kostenstrukturen besitzt, kann nahezu beliebig skaliert werden.
  • Nachhaltigkeit: Innovative Plattformgeschäfte sind für Unternehmen zukunftsweisend. Sie schaffen Handlungsspielraum, steigern die Effizienz und stärken die Wettbewerbsfähigkeit. 
  • Netzwerkeffekte: Plattformen schaffen (Mehr-)Werte durch die vielseitigen Verbindungen von Anbietern, Kunden und Ressourcen. Je mehr Anbieter eine Plattform nutzen, desto attraktiver wird sie auch für Kunden, weil das Angebot steigt. Umgekehrt steigt die Lukrativität einer Plattform, je mehr Kunden sich darauf befinden. Diese Gegenseitigkeit bezeichnet man als Netzwerkeffekt, der zu exponentiellen Wachstumssteigerungen führen kann.

Bevor Sie sich nun in wilde Überlegungen stürzen, wie Sie Ihr eigenes Platform Business aufbauen: Halt! Bedenken Sie, dass eine Plattform nicht für jedes Unternehmen geeignet ist – oft kann es zum Beispiel sinnvoller sein, sich als Partner an bereits vorhandenen Plattformen zu beteiligen. Im Consulting wird dieser Punkt ausführlich geklärt und analysiert.

Zusammenfassung

Digitale Plattformen rücken immer weiter ins Zentrum von Marktstrukturen und verdrängen damit traditionelle, einseitig ausgelegte Märkte. Sie vereinfachen den Handel und Austausch zwischen Interessengruppen in einer einheitlichen virtuellen Umgebung, sind zudem hoch skalierbar und können für verschiedenste Branchen und Zwecke eingesetzt werden. Kurz und knapp: Wer langfristig im nationalen und globalen Wettbewerb mithalten will, kommt um das Plattformgeschäftsmodell nicht mehr herum.

Buzzwords: Was ist Zero Trust?

Im Zuge der digitalen Transformation ist es wichtiger denn je, wie zuverlässig Unternehmen und Dienste vor Cyberangriffen und Datenklau geschützt sind. Klassische, perimeterbasierte Sicherheitskonzepte zum Schutz von Unternehmensnetzwerken stoßen zunehmend an ihre Grenzen, weil sie davon ausgehen, dass interne Zugriffe keine Gefahr darstellen. Doch wem kann man noch vertrauen? Das Zero Trust-Konzept beantwortet diese Kernfrage schon im Wortlaut: niemandem.

„Vertraue niemandem, verifiziere jeden“

Bei Zero Trust handelt es sich um ein IT-Sicherheitsmodell, das grundsätzlich keinem Gerät und keinem Nutzer traut – weder innerhalb noch außerhalb des Netzwerks. Nach der Maxime „Never trust, always verify“ (zu Deutsch: „Vertraue niemandem, verifiziere jeden“) fordert es für jeden Zugriff und jeden Datenfluss eine Authentifizierung. Das heißt: Jede einzelne Anfrage muss neu verifiziert werden, bevor man Zugang zum System erhält.

Zum Vergleich: Bei traditionellen Sicherheitsarchitekturen genügt eine einmalige Verifizierung, um als vertrauenswürdig eingestuft zu werden. Das mag zwar eine komfortable Lösung sein, setzt aber voraus, dass Angreifer immer nur von außen und niemals von innen auftreten können – eine naive Annahme, die im heutigen digitalen Ökosystem keinen Bestand mehr hat. Zero Trust schiebt dem Ganzen einen Riegel vor und rückt den Schutz der Daten in den Mittelpunkt.

Die wichtigsten Grundsätze von Zero Trust

Wie jedes Konzept beruht auch Zero Trust auf einer Kombination verschiedener Prinzipien und Technologien zur umfassenden Abwehr von Cyberangriffen in digitalen Geschäftsumgebungen. Die wichtigsten davon sind:

  • Least Privilege: Das Least Privilege-Prinzip verlangt so wenige Zugriffsberechtigungen wie möglich. Menschliche als auch nicht menschliche Benutzer erhalten demnach nur so viele Privilegien und Informationen wie unbedingt nötig (Just-in-Time / Just-Enough-Access).
  • Datenzentrierung: Die Basis einer lückenlosen Sicherheit und Compliance bildet bei Zero Trust der Schutz der Daten und nicht des Perimeters. Daher liegt der Fokus des Ansatzes vorrangig auf der Sicherung, Verschlüsselung und Verwaltung der Daten sowie der Entwicklung von Datenklassifikationsschemata.
  • Zugriffskontrollen: Durch laufende Identitäts- und Datenprüfungen wird protokolliert, wer wann auf welche Ressourcen Zugriff hat, um interne und externe Bedrohungen rechtzeitig zu erkennen. Privilegierte Accounts gelten als besonders beliebtes Angriffsziel und müssen deshalb verstärkt geschützt und überwacht werden. Je mehr Datenpunkte (Identität, Standort, Datenklassifizierung, Workload etc.) in die Autorisierung einfließen, desto besser.
  • Mikrosegmentierung: Bei dieser Methode werden Sicherheitsperimeter in kleinere, voneinander getrennte Zonen aufgeteilt, die jeweils eigene Zugriffsautorisierungen erfordern. So soll sichergestellt werden, dass ein Benutzer oder ein Programm mit Zugriff auf eine der Zonen nicht automatisch auch auf alle anderen zugreifen kann. Sollte in einem der Segmente ein Angreifer entdeckt werden, lässt sich das kompromittierte Gerät sehr viel leichter unter Quarantäne stellen und vom Rest des Netzwerks trennen.
  • Multifaktor-Authentifizierung (MFA): Für den Zugriff auf geschäftskritische Ressourcen ist ein Passwort allein nicht ausreichend. Viele Online-Dienste und Plattformen nutzen daher eine MFA wie beispielsweise die 2-Faktor-Autorisierung (2FA), bei der Benutzer mehr als einen Identitätsnachweis angeben müssen. Nach der Eingabe des Passworts wird dazu ein Code an ein anderes Gerät versendet, der für die Zugriffsfreigabe erforderlich ist.

Fazit: Zero Trust als Paradigmenwechsel in der IT-Security

Das Zero Trust-Modell ersetzt zum Großteil den traditionellen IT-Sicherheitsansatz, nach dem sämtliche Zugriffe innerhalb des Netzwerkperimeters legitim sind und nicht als Bedrohung für das Unternehmen gesehen werden. Gemäß seiner Maxime „Vertraue niemandem“ muss bei Zero Trust jeder Zugriff verifiziert und überwacht werden. Die Implementierung dieses Konzepts kann auf ganz unterschiedlichen Wegen erfolgen, da es nicht „die eine“ Zero Trust-Strategie gibt. Wirksame Technologien sind zum Beispiel Mikrosegmentierung, Multifaktor-Authentifizierung (MFA) oder Identity and Access Management (IAM), um einen kontrollierten Zugriff von Benutzern und Identitäten zu gewährleisten. Klar ist, dass Zero Trust weiter an Bedeutung gewinnen wird, da die zunehmende Komplexität unserer IT-Landschaft ein grundlegendes Sicherheitsumdenken erfordert. Nicht das Netzwerk als solches, sondern seine Daten und Ressourcen müssen ins Zentrum gerückt und geschützt werden.

Was bedeutet WebAssembly für IT-Projekte?

Eine der jüngsten Entwicklungen in der Weblandschaft ist WebAssembly – ein Binärformat, das unter Web- und App-Entwicklern längst in aller Munde ist. Völlig zu Recht, denn es zeichnet sich ab, dass WebAssembly über kurz oder lang neue Maßstäbe in der Softwareentwicklung setzen wird. Doch was bedeutet das für zukünftige IT-Projekte?

Basics first: Was kann WebAssembly?

WebAssembly (Wasm) ist eine Low Level Assemblersprache, die nativ in Webbrowsern kompiliert werden kann. Im Vergleich zu JavaScript liegt das Format sehr viel näher am Maschinencode und unterscheidet sich in seiner Leistung kaum von nativen Apps. Es läuft in allen großen Browsern – Chrome, Firefox, Safari und Edge – und ist vom W3C als offizieller Web Standard anerkannt. Das Besondere an WebAssembly ist, dass man in der Regel nicht direkt damit programmiert, sondern dass es als Kompilierziel für andere Sprachen fungiert. Da es bereits im Binärformat vorliegt, erfolgt das Parsing deutlich schneller als bei JavaScript.

Konkret heißt das: WebAssembly bietet die Möglichkeit, gängige Hochsprachen (z.B. C, C++, Java, Python) in ein ladezeitoptimiertes Format zu kompilieren, das crossbrowser und crossplatform Einsätze möglich macht. Jede Desktop Anwendung, die sich in WebAssembly kompilieren lässt, können Sie auf diese Weise ohne Leistungseinbußen im Browser ausführen. Damit dient WebAssembly als ideale Ergänzung zu JavaScript, um dessen Overheads auszubügeln und auch komplexe, rechenintensive Anwendungen im Browser auszuführen.

Was bedeutet das für IT-Projekte?

Seit WebAssembly ist JavaScript nicht mehr einzige Option, um Code für den Browser zu schreiben. Und das hat Folgen: Denn statt sich auf die bisherigen Objektprototypen von JavaScript zu beschränken, haben Entwickler zum ersten Mal eine Auswahl. Im Grunde können Sie jede Funktion Ihrer Anwendung in einer beliebigen Sprache programmieren und diese im Anschluss zu Wasm kompilieren. Voraussetzung ist natürlich, dass die gewählte Sprache über einen WebAssembly-Compiler verfügt.

Ein weiterer Vorteil von WebAssembly: Sie können den Wasm Code wiederverwenden und damit eine Brücke zwischen C#-Backend (als Beispiel) und JS-Frontend bilden. Wenn Sie Ihre DLL mit WebAssembly als Ziel kompilieren, sparen Sie sich den Schritt sie in JavaScript zu implementieren – und das spart Entwicklungszeit.

IT-Projekte stehen damit vor ganz neuen Chancen, aber auch Herausforderungen. In Bereichen, in denen die Rechenleistung von JavaScript an ihre Grenzen stößt, kann zukünftig mit Wasm gearbeitet werden – zum Beispiel bei 3D Gaming, Image Editing oder Virtual Reality. Desktop und Mobile Apps, für die bisher keine webbasierte Variante geplant war, können mit Wasm problemlos im Browser kompiliert werden. Und ja, das betrifft auch Java Anwendungen und alle anderen „web-fernen“ Sprachen.

Wird zukünftig nur noch mit WebAssembly programmiert?

WebAssembly wurde mit dem primären Ziel entwickelt, leistungsstärkere Webanwendungen zu ermöglichen. Der Trend hin zu browserbasierten Applikationen wird dadurch natürlich verstärkt, denn der Vorteil ist: Web Apps haben ein breiteres Publikum. Gleichzeitig macht WebAssembly die Programmierung solcher Apps effizienter, schneller und günstiger. Da inzwischen alle großen Browser das Format unterstützen, ist es eigentlich nur eine Frage der Zeit, bis es sich komplett in der Webentwicklung etabliert hat – vor allem in jenen Bereichen, wo Performance eine große, wenn nicht sogar entscheidende Rolle spielt. Wiederum wird es JavaScript nicht ersetzen, allein schon deshalb, weil die Wasm Module mit JavaScript geladen werden. Es ist und bleibt daher eine Ergänzung, die die bisherigen bestehenden Grenzen in der Softwareentwicklung ein großes Stück aufbricht. 

Zusammenfassung

WebAssembly mag in erster Linie für Performancesteigerungen konzipiert worden sein, doch das Format kann weitaus mehr. Entwicklungsteams, die plattformübergreifend oder mit einer Client-Server-Aufteilung arbeiten, profitieren zum Beispiel von kürzeren Lieferzeiten und mehr Flexibilität beim Programmieren selbst. So ist man nicht mehr an die lose Typisierung von JavaScript gebunden, sondern kann jede Hochsprache, die in Wasm kompiliert werden kann, für die gewünschten Funktionen nutzen – von Rust und C bis hin zu Java. Das Web von morgen wird Apps der Desktop-Klasse mit nativer Leistung ausführen, und WebAssembly macht es möglich.

Dokumentation im Code – ja oder nein?

Programmcode wird zwar immer für Maschinen geschrieben, aber wirklich gut ist er erst, wenn ihn auch Menschen ohne Schwierigkeiten lesen können. Doch was heißt „ohne Schwierigkeiten“? Viele Entwickler setzen dazu auf eine mehr oder weniger detaillierte Dokumentation des Codes. Der Gedanke ist klar: Kommentare sollen helfen, den Code besser nachzuvollziehen und Nachfragen oder gar Missverständnisse zu vermeiden. Aber sollte ein guter Code nicht eigentlich selbsterklärend sein? Wir gehen der Frage nach.

Warum Code überhaupt dokumentiert wird

Kommentare zwischen den Codezeilen sind nicht per se schlecht. Sie haben ihre Daseinsberechtigung. Ein Beispiel: Sie möchten komplexe Funktionsabschnitte deklarieren. Oder Sie möchten erwähnen, warum Sie an einer bestimmten Stelle genau diese Parameter verwenden und keine anderen. Problematisch wird es dann, wenn Sie

  • mehr Augenmerk auf die Dokumentation legen als auf den Code selber, und
  • die Funktionalität des Codes statt seiner Intention kommentieren.

Hinter einer übereifrigen Dokumentation steckt oft die Angst, dass andere den Code falsch oder gar nicht verstehen könnten. Denken Sie umgekehrt: Wie lässt sich Code schreiben, damit er keiner weiteren Kommunikation bedarf? Denn dann kommen Sie schnell an den Punkt, an dem Ihnen klar wird, dass 99% aller Kommentare überflüssig sind.

Ein guter Code spricht für sich

Je weniger Sie kommentieren, desto stärker müssen Sie auf klare und strukturierte Anweisungen achten. Clean Code zwingt Sie gewissermaßen ganz von selbst dazu, möglichst simpel und effizient zu coden, weshalb dieses Prinzip in der Softwareentwicklung auch so hochgelobt ist. Versuchen Sie mit Ihren Codezeilen zu kommunizieren, statt sich in ausufernden Dokumentationen zu verlieren. Hier sind vier Gründe, warum Sie zukünftig weniger kommentieren sollten:

1.      Kommentare lenken ab

Ein perfekter Code hat immer einen gewissen Fluss, wenn Sie ihn durchgehen, so als würden Sie einen flüssigen Text lesen. Kommentare unterbrechen diesen Fluss ausnahmslos und erschweren so in vielen Fällen – paradoxerweise – das Verständnis des Codes. Das ist vor allem dann der Fall, wenn es sich um redundante Kommentare handelt, die keine neuen Informationen liefern.

2.      Kommentare kosten Zeit

Zeit ist die kostbarste Ressource in der Softwareentwicklung. Überschlagen Sie einmal in Gedanken, wie viel Zeit Ihnen das Verfassen der Kommentare kostet und wie viel Zeit andere damit verbringen, diese zu lesen und mit dem Code in Einklang zu bringen. Und wer pflegt und aktualisiert die Kommentare, wenn der Code zu einem späteren Zeitpunkt angepasst werden muss? Der Punkt ist: Dokumentieren geht immer zu Lasten der Produktivität. Wenn Sie dauerhaft schneller und effizienter arbeiten wollen, müssen Sie rigoros Kommentare einsparen.

3.      Schlechte Kommentare verwirren Ihre Kollegen

Vielleicht kennen Sie das Szenario selbst: Jemand kommentiert etwas völlig Offensichtliches und Sie fragen sich insgeheim: Warum wird das kommentiert? Steckt noch mehr dahinter? Lässt sich das auch anders interpretieren? Redundante oder irreführende Kommentare können eine ganze Menge Probleme verursachen, die völlig unnötig sind. Vertrauen Sie Ihren Programmierfertigkeiten und denen Ihrer Kollegen. So oder so werden Kommentare Ihren Code nicht besser machen.

4.      Kommentare überlagern die Neutralität des Codes

Programmiersprachen sind neutral, eigene Kommentare nicht. Denken Sie immer daran, dass Ihre Kommentare Teil des Quellcodes sind und von jedem, der damit arbeitet, eingesehen werden können. Besonders relevant ist dieser Punkt für jeden, der dazu neigt, Kommentare auch als eine Art Notizen zu verwenden. Gestern Nacht noch kurz etwas vermerkt, am nächsten Morgen längst vergessen – und Ihr Kollege amüsiert sich prächtig. Darum sollten Sie sich angewöhnen, so wenige Kommentare wie nur möglich zu hinterlassen.

Fazit: Gute Programmierer kommunizieren mit ihrem Code

Schreiben Sie Programmiercode so, dass man ihn auch ohne oder nur mit wenigen Kommentaren verstehen kann. Damit sparen Sie selbst und anderen eine Menge Zeit, arbeiten produktiver und fokussieren sich auf klare, einfache Strukturen. Erfahrungsgemäß lässt dies auch das Vertrauen in die eigenen Fähigkeiten wachsen, weil Sie lernen, ausschließlich mit Ihrem Code zu kommunizieren.

Serverless: Vorteile für IT-Projekte

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.

Artikelbild: Frau SRE-DevOps-Expertin angestrahlt mit Code

SRE oder DevOps: Rivalen oder Alliierte?

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 DevOpsExperten, 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

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.