Anatol's pages

background image
page logo

No code + DevOps = ClickOps

clickops de dev

Was ist in der Regel die Hauptquelle aller Fehler? Eine Menge Copy-Paste? Schlechtes Sehvermögen? Ablenkung? Die Hauptquelle für Fehler ist der Mensch. Und das Wichtigste ist, dass man aus solchen Fehlern nichts lernt, sondern dass sie dem Unternehmen eine Menge Nerven und Geld rauben. Es ist nur eine unzusammenhängende Reihe von Tippfehlern...

Errors

📖 Kein Code - keine Probleme

Wofür sind Sysadmins eigentlich immer da gewesen? Damit jemand hingeht und diese Fehler behebt. In bereits funktionierenden Systemen. D.h., irgendwo hat die Entwicklungsabteilung etwas produziert, und dann warten die "System"-Administratoren (Admins) in der Betriebsabteilung das Ganze.

Ein "System" ist alles, was eine programmierte Logik hat. Zum Beispiel muss ein defekter Drucker nach Fehlern ausgeschaltet und neu gebootet werden. Oder ein geografisch verteilter Cluster.

Worked fine in dev
Worked fine in dev

DevOps.

Nach und nach hörten die Drucker auf, so fehlerhaft zu sein, und die Mitarbeiter lernten, sie selbst neu zu starten. Und die Server wurden in die Cloud verlagert. Das heißt, es gibt einfach so viele von ihnen, dass sie sich selbst neu starten, wenn sie ausfallen, und niemand merkt es überhaupt.

Ein Mann mit einem Schraubenzieher im Büro ist nicht mehr nötig. Und nach 2020 begannen die Büros selbst zu verschwinden. Und die Systemadministratoren begannen allmählich zu lernen, mit Software und nicht mit Hardware zu arbeiten. Jetzt sind sie nicht nur Systembetreiber. Sie sind auch deren Entwickler. D.h., Dev+Ops.

Auch die Entwickler haben sich den Servern angenähert. Der Server ist jetzt genauso ein Programm mit einer API wie jedes andere System.

Die Grenze zwischen Hardware und Software ist fast verschwunden. AWS ermöglicht es uns, einen FPGA-Chip direkt in der Cloud zu flashen.

Systemadministratoren haben gelernt, wie man programmiert, und Programmierer haben gelernt, wie man verwaltet.

Jetzt sind alle Bugs endlich in den Code gewandert. Und jedes neue Stück Code ist ein neuer Text mit neuen Tippfehlern.

No Code und Low Code

📖 Der beste Code ist kein Code

Was ist, wenn der Code jetzt auch in die Cloud wandert? Er befindet sich schon lange in der Cloud. Aber hier sehen wir ihn gar nicht mehr. Wir haben bereits alle Codestücke, die wir uns vorstellen können. Wir müssen sie wie Legosteine finden und sie zu einem vollständigen Programm zusammensetzen. Dabei geht es nicht um den Code selbst, sondern nur um die Beschreibung.

Die Verwendung bereits vorbereiteter Elemente spart Entwicklungszeit und vor allem Testzeit.

Ein Beispiel: Sie müssen Ihrer Website ein einfaches Webformular hinzufügen. Die Antworten müssen in eine CRM-ähnliche Tabelle eingegeben werden. Und bei jedem neuen Ausfüllen möchten Sie eine E-Mail oder eine Nachricht in Slack erhalten. Dafür gibt es fertige Lösungen. Aber das ist nicht unser Weg. Wir wollen nicht gedankenlos eine fertige Lösung einbauen, sondern wir wollen diesen Builder selbst bauen - wir werden ihn brauchen:

Der [Airtable Proxy Cloudflare Worker] (https://github.com/portable-cto/airtable-proxy-worker) ist ein hervorragendes Beispiel für einen LowCode-Block. Diese einfache Sache verwandelt Ihre Tabelle/Basis in eine über eine Website zugängliche API, ohne dass Sie Ihren Airtable-Schlüssel der Welt preisgeben müssen. Ja, das ist Code. Und Sie müssen verstehen, was er tut. Wir können es einfach einen öffentlich getesteten Open-Source-Code oder eine Bibliothek nennen. In der modernen IT-Welt gibt es solche Bibliotheken, von Mikrowellen bis hin zu Raumschiffen. Die übliche Bezeichnung ist lib oder tool.

Beispiele für Tools sind:

Es ist, als würden wir Farbe in größeren Strichen auftragen. Und schon nimmt sie die Form an, die man auf der intelligenten Leinwand haben möchte.

CMS (Content Management System)

Aber diese sind nur für diejenigen, die Erfahrung in der Entwicklung haben. Für Leute ohne Programmiererfahrung gibt es fertige Lösungen wie Typeform. Das ist wirklich null Code, außer dass Sie ein Stück JS kopieren müssen.

Oder das weltweit beliebteste CMS (Content Management System) - WordPress. Etwa die Hälfte aller Websites auf der Welt basieren auf diesem oder ähnlichen Systemen. Und dort kann man alles ohne jeden Code machen. Zumindest so lange, bis man etwas ändern muss, was nicht in den Plugins steht. Oder bis Hacker und Botnets zum Angriff übergehen. Dann braucht man etwas Schlaueres als das quelloffene, nackte WordPress.

Die Nachteile von WordPress und Typeform sind Unflexibilität und Komplexität. Es sind alles ziemlich große und schwere Lösungen. Sie sind in der Regel teuer und nicht sehr sicher. Sie sind keine Legosteine, sondern ein bereits zusammengebauter "Todesstern".

Obwohl einige ziemlich große No-Code-Lösungen bereits so sehr in unser Leben integriert sind, will niemand sie über viele Jahre hinweg entwickeln. Zum Beispiel erstellt niemand ein Webformular für die Annahme von Zahlungen oder einen Website-Besucherzähler selbst.

Software as a Service (Saas)

Man kann eine weitere Abstraktionsebene erreichen. Aus all diesen Mikro-Programmen kann man etwas noch Leistungsfähigeres bauen. Und eine Lösung für die Aufgabe haben, ohne eine Zeile Code zu schreiben. Das sogenannte SaaS - Software as a Service. Heute ist wahrscheinlich alles, was einmal ein Programm war, zu SaaS geworden. Einfach deshalb, weil man für ein Abonnement bezahlen kann, und weil diese Dienste auf einmal aktualisiert werden können, weil sie in einem Browser funktionieren und man sie nicht herunterladen muss. Ich denke, jeder kennt die Beispiele:

ServerLess und Function as a service

📖 kein Code für DevOps; es ist wie kein DevOps für Coder

Auch bekannt als BackendLess oder ServerLess. Oder allgemein alles-as-a-Service. Soft-aaS oder Infra-aaS oder Platform-aaS oder Backend-aaS. Jedes Programm kann zu einem Service-as-a-Service gemacht werden, indem man es in die Cloud verlagert und eine Benutzeroberfläche mit Bezahlung und Support erstellt.

Programmierer mögen oft nicht alles, was mit der Umsetzung ihrer Produkte in die Produktion verbunden ist. Und hier können sie verstanden werden. Ein Mensch wird dafür bezahlt, dass er programmiert. Das heißt, er löst die Geschäftsaufgabe des Unternehmens. Alles, was darüber hinausgeht, ist für ihn Routine. Als Ergebnis haben wir FaaS-Systeme. Das sind solche Nano-Services. Solche Systeme ermöglichen es Ihnen, ein kleines Programm als einfache Funktion auszuführen, die das Ergebnis von 2 +2 auf einer separaten API-URL zurückgibt. Zum Beispiel

Dev ops-Zyklus
Dev ops-Zyklus

Click Ops

📖 Null Code ≠ Null Erfahrung

Faulheit ist der Motor des Fortschritts. Und DevOps-Faulheit ist der Fortschritt von IaaS (Infrastructure as a Service). Sie können also nicht nur den Schraubenzieher und die Raspel beiseite legen, sondern auch die Tastatur! Ein DevOps, der nur mit einer Maus bewaffnet ist, kann das Gleiche tun wie ein DevOps mit einer Tastatur. Mit anderen Worten - Click Ops.

Und daran ist nichts auszusetzen. Es wurde alles schon einmal gemacht. Erfahrene Microsoft-Programmierer können das bestätigen. Viele Dinge wurden mit der Maus erstellt.

Warum sollte man die Infrastruktur programmieren, wenn man sie sich ausdenken und zeichnen kann? So haben sich Netzwerke, Firewalls, Server und VPNs selbst geschaffen.

AWS begleitet uns schon sehr lange, und es ist unvorstellbar, wie wir davor gelebt haben. Aber ehrlich gesagt, es sind Low-Code-Lösungen wie Cloudformatin-Diagramme und andere. Sie sind einfach überflüssig. Sie sind umständlich und schwer zu erlernen. Das Erlernen einer komplexen Lösung, selbst wenn es überhaupt keinen Code, sondern nur Schaltflächen gibt, ist dasselbe wie das Schreiben eigener Skripte oder die Verwendung von Open-Source-Standardlösungen wie Terraform/Ansible.

Seit dem 20. Jahrhundert kann ein angehender IT-Fachmann sein eigenes Blog auf seiner Domain mit SSL-DNS-DDoS-Schutz mit einem Knopfdruck erstellen. Und das alles kostet so viel wie ein Kaffee. Beispiele für einige IaaS-Lösungen von der Stange:

Mit ein paar Klicks können wir: unseren eigenen Server in der Cloud erstellen, öffentlich mit unserer eigenen HTTPS-URL darauf zugreifen, helm oder docker-compose dort ausführen, alles testen, dem Team zeigen und sehen, ob wir das Produkt brauchen. Und vielleicht sogar anfangen, es zu benutzen.

Dazu muss man natürlich wissen, wie all diese Systeme unter der Haube funktionieren. Denn dann muss man das alles optimieren, im Auge behalten und vielleicht noch einmal optimieren. Dann müssen Sie den Code schreiben.

Beschränkungen

Es spricht nichts dagegen, Ihre eigene gehostete Lösung oder Ihr eigenes Produkt durch ein Cloud-basiertes Produkt zu ersetzen, wenn dieses Produkt auf einem offenen Standardprotokoll oder einer API läuft. Dann erhalten wir die Zuverlässigkeit der Cloud, ohne dass sich der Anbieter einmischt!

Große Produkte von der Stange sind leider nicht immer anwendbar:

  1. Das ist alles gut für ein kleines Team für ein erstes Projekt. Proof of Concept oder MVP (Minimal Valuable Prototype). Wenn sich das System weiterentwickelt, müssen Sie echte Hardcore-Programmierer und DevOps einstellen. Aber wird das Startup die Phase überleben, in der es wirklich skalieren muss? Wenn ja, dann ist es bereits ein Erfolg. Nicht mehr als 1-10 % solcher Startups, je nachdem, wie man zählt. Und sie gehen bereits in die zweite Investitionsrunde, wo sie in die Millionen gehen. Die Einstellung von 5 Entwicklern und 20 Programmierern für sie wird das Budget nicht so stark belasten.

  2. Plattformspezifisch (Vendor Lock). Sie müssen solche Lösungen sehr sorgfältig auswählen. Idealerweise sollte es viele solcher Dienste mit ungefähr der gleichen API geben. Das heißt, wenn wir DB als Dienst auswählen, sollte es sich beispielsweise um eine Cloud-Datenbank wie Aurora handeln, die mit Open-Source-MySQL kompatibel ist. Oder DocumentDB/MongoCloud, die auf dem MongoDB-Protokoll läuft.

  3. Komplexität (Lernkurve). Manchmal braucht man mehr Zeit, um die nächste AWS-Lösung zu finden, die einem das Leben erleichtern soll, als eine kleine Speziallösung zu entwickeln.

Die Idee von Low Code ist für diejenigen, die schnell und kostengünstig einen Prototyp erstellen müssen. Und hier sind keine schweren Produkte angebracht.

Text zu Code

Ich glaube nicht, dass es notwendig ist, ohne Text zu leben. Die Überfrachtung mit Videoinformationen führt in der Regel dazu, dass es langweilig wird, und die Leute kehren zur alten Art der Kommunikation zurück - Schreiben und Text. Die Standard-Chat-Räume waren die gleichen wie die Briefe und IRC/ICQ der 90er und 00er Jahre, als dies die einzige Möglichkeit war, mit der Welt zu kommunizieren.

Chats haben erfolgreich eine Reihe von UI-Lösungen ersetzt. Zum Beispiel der Austausch von Kryptowährungen. Es besteht keine Notwendigkeit, das Hosting mit einem anderen JS/CSS-Framework zu zeichnen und zu erhöhen, wenn es bereits eine Schnittstelle in Telegram gibt.

Der Text wird uns also immer begleiten.

Im Allgemeinen ist der Text jetzt alles, von der Kunst bis zur Mikrowellen-Firmware. Um ein Bild zu erstellen, muss man nur noch die richtige Anfrage an die KI stellen. Dafür gibt es bereits eine neue Spezialität namens: Prompt Engineer.

Seit kurzem hat jeder Zugang zum GitHub Copilot. Wovon die meisten Leute einfach nur schockiert sind. Er verwandelt Ihren Kommentar in buchstäblich fertigen Code:

GitHub Copilot
GitHub Copilot

Was kommt als Nächstes.

Ich denke, der Zyklus wird sich wiederholen, und das Pendel der Geschichte wird zum Text zurückschwingen. Aber zu einem Text auf einer anderen Ebene. Alltagssprache mit Fehlern und Tippfehlern, aus der die KI aber einen fertigen Prototyp erstellt.

Und der Anfragetext selbst ist eine Kunstform. Man muss die Hälfte der Antwort wissen, um Google die richtige Frage zu stellen. Und das ist es, was einen erfahrenen Entwickler auszeichnet: Er weiß einfach, was er in die Suchmaschine eingeben muss.

Wir alle sind also schon seit langem Prompt-Ingenieure und Codesucher. Copilot hilft Ihnen dabei, dies einen Klick schneller zu tun.


Home | Translation EN | Перевод RU