Seien wir ehrlich. Angesichts der Vielzahl von Cloud-nativen Datenbanken für spezielle Zwecke, die wir in Produktion geben, malen wir uns in eine Ecke.

Dies ohne Rücksicht darauf, wie wir diese Datenbanken auf eine Weise verwenden sollten, die einen einfachen Zugriff und ein leichtes Verständnis der Daten ermöglicht. Heutzutage sind sie in der Regel an Anwendungen gekoppelt und verfolgen einen taktischen und keinen strategischen Zweck.

Dies ist nicht der Zweck von Daten und nicht das Versprechen der Cloud. Denken Sie daran, dass Daten in der Cloud in unseren Köpfen aufgebaut wurden, um den Zugriff auf und die Zentralisierung von Daten zu erleichtern. Schließlich könnten wir „wunderbare Dinge mit unseren Daten machen“.

Dies bedeutet nicht, dass die Beschaffung und der Betrieb von Daten und Datenbanken teuer geblieben sind. Das allein war ein großer Vorteil von Public Clouds.

Dank der wundervollen Welt der On-Demand-Cloud-Infrastruktur können Sie von „Datenbank benötigen“ zu „Datenbank haben“ innerhalb eines Tages oder weniger wechseln.

Die einfache Beschaffung von Cloud-nativen Datenbanken und damit der Aufbau neuer Datenbanken hat jedoch zu einem Problem mit der Datenkomplexität geführt, das einige wesentliche Nachteile mit sich bringt:

In der Regel gibt es kein gemeinsames Verständnis aller Unternehmensdaten und des Kontexts dieser Daten. Die Daten sind immer noch weitgehend isoliert, vielleicht sogar noch schlimmer als vor 10 Jahren, als unsere Reise in die öffentliche Cloud begann.
Jetzt sind wir mit unbeabsichtigten Konsequenzen konfrontiert, z. B. mangelndem Verständnis für den Umgang mit Sicherheit, Datenverwaltung oder sogar der Nutzung einer „einzigen Quelle der Wahrheit“.

Wir haben laufende Projekte, die sich mit dem Problem der Datenkomplexität befassen, wie die Linked Open Data Cloud. Die Linked Open Data Cloud bietet eine lose gekoppelte Sammlung von Daten, Informationen und Wissen, auf die jeder Mensch oder jede Maschine mit Zugang zum Internet zugreifen kann.

Ziel ist es, eine vom Web bereitgestellte Abstraktionsschicht zu erstellen. Es ermöglicht sowohl den einfachen als auch den anspruchsvollen Lookup-orientierten Zugriff mit der SPARQL-Abfragesprache oder mit SQL, um den Zugriff auf strukturierte und unstrukturierte Daten auf die gleiche Weise zu ermöglichen wie beim Zugriff auf Webseiten, um auf Bild- und Textseiten zuzugreifen, seit das Web gestartet wurde.

Natürlich bieten auch eine Reihe von Technologieanbietern Lösungen wie Stammdatenverwaltung, Datenvirtualisierung und andere Technologien an, mit denen Sie komplexe Daten auf verbesserte Weise verwalten können. Mit anderen Worten: Bereitstellung von Datensemantik und Metadatenverwaltung außerhalb der Datenbanken, Cloud oder nicht.

Ich verstehe jetzt, dass dieser Ansatz für die Verwaltung von Cloud-, Cross-Cloud- oder Hybrid-Cloud-Datenbanken nicht skalierbar oder altersgemäß ist. Bei der Betrachtung der aktuellen Anforderungen sowie in naher oder ferner Zukunft werden die Daten komplexer und technologisch vielfältiger, wenn man das rasante Innovationstempo berücksichtigt.

Der Versuch, die heute verwendeten Ansätze und Tools zu nutzen, wird die Komplexität erhöhen, bis die Systeme schließlich zusammenbrechen. Denken Sie nur an die Anzahl der Tools in Ihrem Rechenzentrum, die Sie heute dazu veranlassen, sich die Frage zu stellen: „Was haben sie gedacht?“ In der Tat haben sie ähnlich gedacht wie heute, einschließlich der Suche nach taktischen Lösungen, die letztendlich nicht das bieten Wert, den sie einmal hatten – und in einigen Fällen einen negativen Wert liefern.

Ich habe einen langen Weg zurückgelegt, um Ihnen eine Antwort zu geben, aber während ich darüber nachdenke, wie wir dieses Problem lösen, scheint ein Ansatz immer wieder als die wahrscheinlichste Lösung aufzutauchen. In der Tat wurde es in verschiedenen akademischen Kreisen herumgetrampelt. Es ist der Begriff der Selbstidentifizierung von Daten.

Heutzutage gibt es zwei Hauptkategorien von Cloud-Leistungstools auf dem Markt: Aktiv und Passiv.

Passive Cloud-Verwaltungstools

Die meisten Cloud-Computing-Verwaltungstools sind passiv.

Passive Tools bieten Informationen zu Problemen innerhalb des Clusters von Cloud-Systemen und empfehlen möglicherweise sogar eine Vorgehensweise, ergreifen jedoch keine Korrekturmaßnahmen.

Die Idee hinter passiven Tools ist, dass die Korrekturmaßnahmen so komplex sind, dass es keinen Sinn macht, Systemkorrekturen zu automatisieren. Dies ist für viele Unternehmen der richtige Ansatz.

Ihre Systeme stellen häufig Informationen bereit, die eine menschliche Interaktion erfordern, da die Informationen im Allgemeinen ereignisbasiert und nicht betriebsbasiert sind. Der passive Ansatz, der den Menschen in die Prozesse einbezieht, fühlt sich für Cloudops-Teams am angenehmsten an.

Aktive Cloud-Management-Tools

Aktive Cloud-Management-Tools scheinen das Ziel des Marktes zu sein, da wir uns von der Komplexität des Cloud-Managements lösen möchten. Wir nähern uns schnell einem Wendepunkt.

Eine moderne cloudbasierte Bereitstellung kann bis zu drei öffentliche Clouds, Hunderte verschiedener Datenbanken, Dutzende von Sicherheitsmodellen und 50 oder mehr Speichertypen umfassen, wobei die Komplexität bald zunimmt.

Wir haben nicht mehr genügend Ressourcen, um diese Systeme zu warten. Ohne Automatisierung und aktive Tools gibt es keinen Weg nach vorne.

Sie können aktive Werkzeuge in folgende Kategorien einteilen:

Analytics-orientierte aktive Tools ähneln analytics-orientierten passiven Tools, können jedoch Korrekturen oder temporäre Korrekturen vornehmen.

Ein Beispiel: Predictive Analytics und protokollierte Daten weisen auf eine hohe Anzahl von Netzwerkfehlern hin. Es hat sich gezeigt, dass ein Core-Router bald ausfallen wird. Menschen müssen über das Problem informiert werden, damit ein neuer Router ausgetauscht werden kann. Das Tool kann jedoch auch Daten um den defekten Router herumleiten, bevor Menschen überhaupt wissen, dass das Problem besteht.

Ereignisorientierte aktive Tools können einfache Ereignisse erfassen, genau wie ereignisorientierte passive Tools. Aktive Tools können jedoch automatische Korrekturmaßnahmen ergreifen. Dies sind in der Regel einfache Probleme, die offensichtlich, aber sehr effektiv behoben werden. Dies ist die Mehrheit der Systemprobleme, mit denen Cloudops-Ingenieure täglich konfrontiert sind.

Selbstkorrigierende oder selbstheilende Werkzeuge. Dieser austauschbare Begriff wird jetzt auf dem Markt herumgeworfen und ist sowohl für analytikorientierte als auch für ereignisorientierte Ansätze von zentraler Bedeutung. In der Tat ist es typischerweise das Subsystem, das die automatisierte Reparatur ausführt.

Es ist vernünftig anzunehmen, dass diese Kategorie von Werkzeugen an Bedeutung gewinnen wird, wenn man bedenkt, wie viel Arbeit erforderlich ist, um herauszufinden, wie Korrekturen automatisiert werden können.

Die Diagnosewerkzeuge könnten eine Seite des Marktes mit Korrekturwerkzeugen auf der anderen Seite besetzen. Korrekturwerkzeuge bieten möglicherweise praktikablere und skalierbarere Optionen, da diese Werkzeuge in eine bestimmte Cloud-native Technologie integriert werden müssen.

Erwarten Sie, dass aktive Cloud-Management-Tools die Zukunft sein werden. Sind Sie bereit?

We all made it: grab a cookie when Mama was not looking, drank a bit too much wine for dinner and left the car in a parking lot after the meter ran out.

We even walked around Deadman’s bend a bit too fast. And yes, we’ve all violated any number of key programming rules. Those who all agree are bad. And we secretly liked it.

We have come to terms with the rules of good programming, written code that is totally bad – and we have lived. There were no flashes from the programming gods. Our desktops have not exploded. Our code was compiled and shipped, and customers seemed satisfied.

This is because poor programming is not in the same league as licking an electric fence or pulling a tiger’s tail. Mostly it works. The rules are more common guidelines or stylistic suggestions, not directives that must be obeyed, or the code death will follow. Sure, your code could be ridiculed, possibly even public. The fact that you oppose conventions adds a little to the thrill, even if you accidentally undermine what (usually) corresponds to the social customs of a pleasant code.

Sometimes, for reasons of complexity, it is better to break the rules. (Shhhh!) The code comes out cleaner. It can even be faster and easier. The rules are usually a bit too broad, and a skilled programmer can improve the code by breaking it. Do not tell your boss, but sometimes it makes sense to code your own way.

What follows is a list of nine rules that some consider to be unassailable, but many of us break frequently, both with success and pleasure.

Bad Programming Habit # 1: Copy

It is wrong to do this at school. At work, the rules are not so clear. There are certainly some code blocks that should not be stolen. If it’s proprietary code, do not fold it into your stack, especially if it’s marked with a copyright notice. Write your own version. You will be paid for it.

The more difficult question comes when the original creator wants to share. Maybe it’s in one of these online program forums. Maybe it’s open source code with a license (BSD, MIT) that allows you to use one or three functions. There is no legal reason to stop you. And you are paid to solve problems and not reinvent the wheel.

Mostly the advantages of copying are convincing and the disadvantages can be limited with a little care. At least one train of thought has been applied to the code you receive from a reputable source.

The original author sought a solution and found something. The loop invariants and the data flow have been worked out.

The tricky questions are whether there are some undetected errors or other assumptions about the role or the underlying data.

Maybe your code mixes in null pointers, while the original code never checked them. If you can fix the issues, your boss seems to be supported by two programmers. It’s a couple programming without the chic desks.

Bad Programming Habit # 2: Non-working code

In den letzten zehn Jahren ist das Funktionsparadigma aufgestiegen.

Die Experten für die Erstellung Ihres Programms aus verschachtelten Funktionen zitieren gerne Studien, die zeigen, wie sicherer und fehlerfreier der Code ist als die älteren Variablen- und Schleifenstile, die auf jede Art und Weise aneinandergereiht sind, die den Programmierer glücklich machen.

Die Anhänger sprechen mit dem Eifer der wahren Gläubigen und verurteilen in Code-Überprüfungen und Pull-Anfragen nicht-funktionale Ansätze. Sie haben vielleicht sogar Recht mit den Vorteilen.

Aber manchmal muss man nur eine Rolle Klebeband herausholen. Wunderbar entwickelter und elegant geplanter Code braucht Zeit, nicht nur um sich etwas vorzustellen, sondern auch um ihn zu konstruieren und später zu navigieren. Alle diese Schichten erhöhen die Komplexität, und Komplexität ist teuer.

Entwickler von schönem funktionalem Code müssen vorausplanen und sicherstellen, dass alle Daten auf geeigneten Wegen weitergeleitet werden. Manchmal ist es einfacher, eine Variable zu erreichen und zu ändern.

Vielleicht schreibe einen Kommentar, um es zu erklären. Sogar das Hinzufügen einer langen, krassen Entschuldigung zu zukünftigen Generationen im Kommentar ist schneller als das Neuarchitekturen des gesamten Systems, um es richtig zu machen.

Schlechte Programmiergewohnheit Nr. 3: Nicht standardmäßiger Abstand

Die meisten Leerzeichen in der Software wirken sich nicht auf die Leistung des Programms aus.

Abgesehen von einigen Sprachen wie Python, die den Abstand zur Angabe von Codeblöcken verwenden, haben die meisten Leerzeichen keine Auswirkung auf das Verhalten des Programms.

Even so, there are obsessive programmers who count them and insist they are important. One of them once told my boss in the most serious tone that I write „Non Standard Code“ and he can see it immediately. My sin? ESLint Space Infix Ops Rule violations by not inserting spaces on either side of an equals sign.