Eine kurze Geschichte der Anwendungsentwicklung

Das Schreiben von Anwendungen ist großartig. Wenn wir das nur tun könnten, anstatt uns mit dem ganzen Prozess der Inbetriebnahme herumzuschlagen, oder? Ich sage oft, dass Apps wie Flugzeuge sind: Wenn sie in der Luft sind, stehen die Chancen gut, dass sie reibungslos laufen, wenn man die App richtig gebaut hat. Beim Start und bei der Landung gibt es in der Regel Probleme - auch bekannt als Deployment.

In diesem Blog-Beitrag möchte ich einen kurzen Überblick über die Geschichte der Anwendungsbereitstellung geben und aufzeigen, was sich geändert hat, was gut funktioniert hat und was nicht so gut gelaufen ist.

Eine kurze Geschichte der Anwendungsbereitstellung

1. traditionelle Bereitstellung (Ende der 1990er bis Anfang der 2000er Jahre)

• Methode: manuelle FTP-Uploads (File Transfer Protocol) auf Server. Webmaster entwickelten die Anwendung lokal und übertrugen sie dann manuell auf einen Produktionsserver.
• Tools: Standard-FTP-Clients wie FileZilla oder WS_FTP, um nur einige zu nennen.

Heute wären Sie schockiert, wenn Sie wüssten, welch riesige Systeme auf diese Weise eingesetzt wurden, und Sie würden es wahrscheinlich für verrückt halten - aber es hat auch Spaß gemacht und war belebend! Sie hatten eine Sache zu ändern. Sie haben auf ein Symbol Ihres bevorzugten FTP-Clients (ja, wir haben Windows benutzt) doppelgeklickt. Sie navigierten zu einer Datei. Doppelklick. Etwas ändern. Speichern. Voilà, Änderung geliefert. Wir haben nicht so viele Frameworks verwendet. Die Wahrscheinlichkeit ist also groß, dass Sie irgendwo eine riesige PHP-Datei hatten. Und Ihre Änderung war lokalisiert. Und wenn sie nicht funktionierte? Nun, dann haben Sie erneut doppelgeklickt und das korrigiert. In Zeiten, in denen die Zykluszeiten Sekunden betragen, war das in Ordnung. Nun, bis es das nicht mehr war.

Oft genug lief Ihre Anwendung auf einem einzigen Server, der ausschließlich für diesen Zweck bestimmt war. Darauf lief die Datenbank, die Sie brauchten, oder, wenn Sie etwas Ressourcenintensiveres ausführten, hatten Sie wahrscheinlich einen separaten Server für die Datenbank - das, was wir Multi-Tier-Bereitstellungen nannten. Und normalerweise kümmerte sich jemand anderes darum (der Datenbankadministrator).

1998 gab es bei Apache so genannte virtuelle Hosts, die es ermöglichten, mehrere Sites auf demselben Rechner zu hosten, was dazu führte, dass man immer mehr Anwendungen auf denselben Server packte. Wenn Sie also eine Datei im falschen Verzeichnis änderten... nun ja.

Zu dieser Zeit haben Sie vielleicht schon mit echten Profis zusammengearbeitet und waren bei El Reg und Slashdot, so dass Sie bereits eine gewisse Trennung der Verantwortlichkeiten hatten. Wenn das so war, hattest du bereits einen Testserver und hast diese Sache auf dem Staging-Server gemacht. Und dann würde irgendein Systemadministrator das Kopieren in die Produktion übernehmen, was in Ordnung war - bis es nicht mehr so war.

2. die Einführung von Versionskontrollsystemen (VCS) (Anfang der 2000er Jahre)

• Methode: Entwickler begannen, VCS zur Verwaltung von Codeversionen einzusetzen. Die Bereitstellung beinhaltete manchmal das Auschecken des neuesten Codes direkt auf einem Produktionsserver.
• Werkzeuge: CVS und Subversion.

Inzwischen waren die Profis noch ernsthafter geworden, und sie wollten tatsächlich die Kontrolle über die Dinge haben, die sie bereitstellten. Außerdem begannen die Ingenieure, Ordner mit der Bezeichnung production_v12_final_final_backup_charles_final zu hassen.

Also begannen wir, SVN zu verwenden, und etwas in Produktion zu bringen, bedeutete in der Regel, SVN zu verwenden, was langsam und mühsam war und oft nicht funktionierte. Aber es war die seriöse Art, Dinge zu tun. Die schlauen Leute lernten, wie man Symlinks verwendet, zuerst SVN einrichtet und dann zum Web Root wechselt. Es war wie GitOps ohne Ops, und mit Pull statt Push.

Aber immer noch lief man auf einem Single-Base-System. Die Abhängigkeit hatte in dieser Zeit ihre besten Tage. Und normalerweise waren Staging und Produktion schon lange nicht mehr synchronisiert. In dieser Zeit wurde "es funktioniert auf meinem Rechner" zu einer Sache.

3. gemeinsames Hosting und Control Panels (2000er)

• Methode: Das Aufkommen des Shared Hosting erleichterte es Einzelpersonen und kleinen Unternehmen, Webanwendungen zu hosten. Control Panels wie cPanel ermöglichten es den Benutzern, Hosting-Einstellungen zu verwalten und Anwendungen bereitzustellen.
• Werkzeuge: cPanel, Plesk, DirectAdmin.

Sie werden erstaunt sein, wie viele Dinge immer noch auf diese Weise ablaufen - man geht auf eine Webseite und kann aus einer einsatzfähigen Vorlage eine Reihe von Anwendungen auswählen (meist PHP, aber später noch viel mehr). Und genau hier ist etwas Interessantes passiert. Die Anwendungsbereitstellung wurde so viel einfacher. Mit einem Mausklick.

Wie sich jedoch herausstellte, macht dies die Wartung der Anwendungen umso schwieriger. Wenn die Bereitstellung einfach, aber die Aktualisierung schwierig ist, ist das nicht gut. In der Regel erlaubten diese Tools nicht nur die Bearbeitung von Daten per FTP, sondern boten auch einen Web-Client, so dass man nicht wissen musste, wie man sich mit FTP verbindet.

4) Dedizierte Server und virtuelle private Server (VPS) (Mitte der 2000er)

• Methode: Da Webanwendungen immer komplexer wurden, ging man zu dedizierten Servern und VPS über, um mehr Kontrolle und Ressourcen zu erhalten. Dies ermöglichte es den Entwicklern, die Servereinstellungen an die Bedürfnisse ihrer Anwendung anzupassen.
• Werkzeuge: VMware, Xen und später auch KVM.

Die Virtualisierung hatte einen enormen Einfluss: Plötzlich konnten wir Anwendungen von der Hardware trennen. Jetzt konnte man tatsächlich ein Maschinen-Image erstellen und dieses anstelle der Anwendung bereitstellen.

Dieses Thema wird viel später in Form von Containern wiederkehren. Noch wichtiger ist, dass man verschiedene Basen haben kann. Aber das Erstellen von Images war eine komplexe Geschichte. Die Bereitstellung war eine langsame Angelegenheit. Einige nahmen die neuen Tools an, um neue Praktiken zu übernehmen. Andere behandelten die VM-basierten Maschinen weiterhin als etwas, das sie mit FTP verwendeten. Oder SVN. Mit den gleichen Ergebnissen.

5. automatisierte Bereitstellung und kontinuierliche Integration (CI) (Ende der 2000er bis Anfang der 2010er Jahre)

• Methode: Der Lebenszyklus der Softwareentwicklung sah die Einführung automatisierter Deployment-Tools, mit denen Code getestet und automatisch auf Produktionsservern bereitgestellt werden konnte.
• Werkzeuge: Jenkins, Bamboo, Capistrano und Fabric.

Irgendwann waren Softwareentwickler wie ich des Austauschs mit Systemadministratoren sehr müde. Wir wurden schlecht behandelt. Und wir konnten programmieren.

Also beschlossen wir, das Problem zu programmieren. Das ist es, was wir heute DevOps nennen. Davon gab es hauptsächlich zwei Versionen:

1. Code, der auf dem eigenen Rechner lief und die zuvor manuell ausgeführten Aktionen automatisierte (z. B. FTP, SVN-Update oder das Umschalten eines Symlinks).
2. Code, der auf den Servern lief und im Grunde die gleichen Dinge tat.

Die Server befanden sich immer noch im Besitz von Systemadministratoren, aber 2006 war EC2 zu einer festen Größe geworden. Man konnte als Entwickler tatsächlich Zugriff auf einen laufenden Rechner erhalten, ohne um Erlaubnis zu fragen. Aber die Denkweise hatte sich noch nicht geändert. Und Entwickler mit wenig Sicherheitstraining wurden in den meisten Fällen schnell (P)owned.

Wenn die damaligen Systemadministratoren jedoch modern genug waren, erlaubten sie Ihnen die direkte Bereitstellung. Zumindest im Staging. Denn dies waren auch die Jahre des Dreiklangs: dev-staging-prod. Wir waren automatisiert genug, um (unter Schmerzen) alle drei zu pflegen. Das war besser als staging-prod. Dennoch driftete Staging ab, und Dev war fast immer in verschiedenen Stadien des Scheiterns.

6 Plattform-as-a-Service (PaaS) (Anfang der 2010er Jahre)

• Methode: Plattformen, die die Infrastruktur abstrahieren und es den Entwicklern ermöglichen, sich auf den Code zu konzentrieren. Anwendungen konnten auf diese Plattformen verlagert werden, die die Servereinrichtung, Skalierung und Bereitstellung übernahmen.
• Tools: Heroku, Google App Engine, Microsoft Azure App Service, undPlatform.sh.

Dies ist die Phase, über die wir am liebsten sprechen würden, weil wir ein PaaSsind . Und obwohl wir gerne über uns selbst sprechen würden, müssen wir unsere Älteren respektieren.

Zu diesem Zeitpunkt hatten wir die Freiheit des direkten Deployments und die Mühsal der kontinuierlichen Integration kennengelernt. Die meisten von uns, die sich daran gewöhnt hatten, dass Computer hässlich sind und dass jede Software fehlerhaft ist, akzeptierten dies als Teil der Geschäftskosten. Aber in diesen Jahren geschah noch etwas anderes: Ruby und Ruby on Rails. Eine bahnbrechende Neuerung mit einem ganz eigenen Sinn für Ästhetik. Ruby-Leute waren mehr auf Schönheit und Einfachheit bedacht als auf alles andere.

Zu dieser Zeit befanden wir uns im Paroxysmus des Mooreschen Gesetzes. Die Computer wurden immer schneller und Ihr langsamer Code würde mit der Zeit schneller werden, warum also nicht auf seine Lesbarkeit und Schönheit achten?

In der Ruby-Welt wurden Tests nicht als "Kosten für die Arbeit, weil die Sprache ein unsicheres Durcheinander ist" betrachtet, sondern als Beweis dafür, dass man das System mit einfachen Worten betrachten kann. Um es mit den Worten des französischen Dichters Boileau zu sagen: "Was wir uns gut vorstellen, drückt sich klar aus, und die Worte, um es zu sagen, kommen leicht".

Ein weiteres wichtiges Element war Git, das schnell genug kam und SVN verdrängte.

Es gibt einen großen Unterschied in der Intentionalität zwischen `svn up` und `git push`. Aber die Hauptsache war, dass Git Zweige billig und schnell machte. Die Heroku-Leute mit ihrer Liebe zur Einfachheit und Ruby-Ästhetik haben im Grunde gesagt, dass Server und Cloud-Server jetzt Vieh sind. Was Systemadministratoren für uns tun, kann und sollte automatisiert werden. Wir werden alles vereinfachen und euch eine einzige Laufzeitumgebung und eine einzige Datenbank zur Verfügung stellen. Immer das Gleiche; kein Malen außerhalb der Linien. Auf diese Weise können Sie `git push` und Ihr Code wird auf einem öffentlich zugänglichen Server laufen.

Es hätte das Ende der Fahnenstange sein können, das letzte Wort der Geschichte, aber Heroku wurde schon früh von Salesforce gekauft. Das soll nicht heißen, dass Salesforce ein schlechter Verwalter war, sie fügten sogar ein paar Laufzeiten hinzu, aber der Dienst blieb größtenteils, was er war, und ignorierte alles, was in den nächsten 15 Jahren um ihn herum passieren würde. Und das Versagen von Heroku, mit der Zeit zu gehen, machte die Leute misstrauisch gegenüber dieser Idee.

PaaS hätte Entwicklern die Freiheit geben können, sich ohne unnötige Zeremonien und Bürokratie auszudrücken, aber innerhalb der Linien zu malen, fühlt sich nicht so an.

Aber selbst wenn man sich an die Vorgaben gehalten hätte, hätten Heroku und seine Nachahmer von Google und AWS (AppEngine und Beanstalk) den Entwicklern (und jetzt auch den DevOps-Teams) einen Großteil der Arbeit überlassen. Es konnte zwar die Produktion bewältigen, aber kontinuierliche Integration, Staging für die Entwicklung und alles andere als die einzige Laufzeitumgebung und die angeschlossene verwaltete Datenbank waren nur ein nachträglicher Gedanke. Die meisten Dinge, die eine ausgereifte Software-Organisation benötigt, waren jedoch vorhanden.

Wir kommen darauf zurück, wenn wir über Upsun sprechen, aber das ist im Wesentlichen die Wette, die wir eingegangen sind. Dass man den gesamten Prozess in einem einzigen Schritt abwickeln kann, da eine echte Platform-as-a-Service eine Plattform für den gesamten kontinuierlichen Lieferzyklus sein muss.

7 Containerisierung und Microservices (Mitte der 2010er Jahre)

• Methode: Anwendungen wurden als Sammlungen von lose gekoppelten Microservices entwickelt. Container kapselten diese Dienste und stellten sicher, dass sie über alle Abhängigkeiten verfügten, die sie zur Ausführung benötigten.
• Tools: Docker, Kubernetes, Docker Swarm und Platform.sh.

Um beim Thema PaaS zu bleiben: Zwei der Probleme, die das frühe PaaS-System nicht lösen konnte, waren die lokale Ausführung von Software und die Ausführung von Microservices. Microservices konnten nicht lokal ausgeführt werden, da dies zu dieser Zeit praktisch unmöglich war.

Bei den frühen PaaS-Systemen ging es um Vereinfachung, und wie wir bereits sagten, konzentrierten sie sich auf den spezifischen Anwendungsfall eines einzelnen Monolithen mit einer einzigen verwalteten Datenbank.

8 Infrastructure-as-Code (IaC) und Serverless (Ende der 2010er Jahre)

• Methode:
  • IaC: Infrastruktur-Setup und Konfigurationen wurden als Code behandelt, was konsistente und replizierbare Umgebungen ermöglichte.
  • Serverless: Entwickler schreiben Funktionen, die als Reaktion auf Ereignisse ausgeführt werden, ohne sich um die zugrunde liegenden Server zu kümmern.
• Tools: AWS Lambda, Google Cloud Functions, Azure Functions, Terraform, Ansible, oh und Platform.sh.

9 Progressive Webanwendungen (PWAs) und JAMstack (Ende der 2010er bis Anfang der 2020er Jahre)

• Methode: Hinwendung zu clientseitig gerenderten Anwendungen und Verwendung von APIs für Backend-Operationen. Bei der Bereitstellung wurden meist statische Dateien an die Randknoten von Content Delivery Networks (CDN) übertragen.
• Werkzeuge: Netlify, Vercel, Cloudflare Pages und - Sie haben es erraten - Platform.sh.

10 Edge Computing (2020er Jahre)

• Methode: Verlagerung von Berechnungen und Datenspeicherung näher an den Ort, an dem sie benötigt werden, um Antwortzeiten zu verbessern und Bandbreite zu sparen.
• Tools: AWS Wavelength, Cloudflare Workers, Akamai Edge Workers und Upsun.

Rauszoomen: der Schritt zur Automatisierung

Im Laufe der Jahre hat sich der Trend zu mehr Automatisierung, besserer Abstraktion und verbesserter Entwicklererfahrung vollzogen. Da sich das Web und die damit verbundenen Technologien weiterentwickeln, werden sich auch die Bereitstellungsmethoden und -tools weiter verändern, um neuen Herausforderungen und Möglichkeiten gerecht zu werden.

In dieser Geschichte sind vor allem zwei Trends von Bedeutung, die sich auf das aktuelle Geschehen beziehen:

Der Aufstieg der Containerisierung

• Vor Kubernetes wurde die Bereitstellungslandschaft bereits durch Docker verändert, das die Containertechnologie populär machte. Container brachten eine konsistente Umgebung von der Entwicklung bis zur Produktion und sorgten dafür, dass die Ausrede "das funktioniert auf meinem Rechner" der Vergangenheit angehörte. Mit der zunehmenden Verbreitung von Containern wuchs jedoch auch der Bedarf, sie effizient zu verwalten, zu orchestrieren und zu skalieren, insbesondere für umfangreiche Anwendungen.

Das Aufkommen von Kubernetes (Mitte der 2010er Jahre)

• Kubernetes wurde 2014 von Google eingeführt und basierte auf den Erfahrungen mit Borg, einem internen Cluster-Management-System. Kubernetes befasste sich mit den Herausforderungen der Container-Orchestrierung, Skalierung und Verwaltung.
• Kubernetes war anfangs nicht der einzige Akteur. Es gab auch andere Tools und Plattformen wie Docker Swarm und Apache Mesos, die sich um das Rampenlicht im Bereich der Container-Orchestrierung stritten. Kubernetes gewann jedoch aufgrund seines robusten Funktionsumfangs, seiner aktiven Community und der Unterstützung durch Branchenriesen schnell an Popularität und wurde zum De-facto-Standard für die Container-Orchestrierung.

Kubernetes begann zwar als Tool zur Orchestrierung von Containern, sein Einfluss geht jedoch weit darüber hinaus und hat die Bereitstellungslandschaft umgestaltet. Es hat Mustern wie Microservices zum Erfolg verholfen, neue Paradigmen wie GitOps gefördert und ein riesiges Ökosystem von Tools und Erweiterungen hervorgebracht.

Wo Upsun passt

Upsun versucht, die ganze obige Geschichte zu nehmen und das, was funktioniert, in eine übersichtliche, selbstbedienbare Box zu destillieren:

1. die Vereinfachung und Abstraktion

• Einheitliches Toolset: Ein modernes PaaS abstrahiert die Komplexität der zugrundeliegenden Infrastruktur und ermöglicht es Entwicklern, sich auf das Schreiben von Code und die Bereitstellung von Anwendungen zu konzentrieren. Anstatt mit mehreren Tools für Container-Orchestrierung, Skalierung, Protokollierung, Überwachung usw. zu jonglieren, erhalten die Entwickler eine einheitliche Plattform, die diese Funktionen standardmäßigintegriert .
• Optimierte Arbeitsabläufe: Entwickler können die Infrastruktur und Dienste, die ihre Anwendung benötigt, mithilfe von Konfigurationsdateien definieren. Dieser Ansatz vereinfacht und kodifiziert den Bereitstellungsprozess.

2. zukünftige Belastbarkeit und Flexibilität

• Vermeiden Sie die Bindung an einen bestimmten Anbieter: Viele PaaS-Lösungen, darunter auch Upsun, sind so konzipiert, dass sie Cloud-unabhängig sind. Das bedeutet, dass Sie nicht an einen bestimmten Cloud-Anbieter gebunden sind und die Flexibilität haben, den Anbieter zu wechseln oder sogar mehrere Anbieter zu nutzen, ohne die Codebasis wesentlich zu verändern.
• Anpassung an Trends: Moderne PaaS-Lösungen können neue Tools schnell integrieren oder sich an veränderte Best Practices anpassen, so dass die Entwickler immer Zugang zu den neuesten Methoden und Technologien haben, ohne dass sie sich um die manuelle Integration kümmern müssen.

3) Konsistenz über verschiedene Umgebungen hinweg

Upsun beispielsweise ermöglicht es Entwicklern, ihre Produktionsumgebung für Entwicklung, Tests oder Staging zu klonen. Dadurch wird sichergestellt, dass sich die Anwendung in allen Phasen konsistent verhält, was das Risiko unerwarteter Verhaltensweisen in der Produktion aufgrund von Umgebungsunterschieden verringert.

4 Integriertes CI/CD

Viele moderne PaaS-Plattformen verfügen über integrierte Pipelines für kontinuierliche Integration und kontinuierliche Bereitstellung, die sicherstellen, dass der Code nahtlos getestet und bereitgestellt wird. Diese Integration reduziert den Bedarf an Tools von Drittanbietern und rationalisiert den Prozess von der Entwicklung bis zur Bereitstellung.

5. skalierbarkeit und leistung

Mit automatischen Skalierungsfunktionen können PaaS-Lösungen unterschiedliche Verkehrslasten ohne manuelle Eingriffe bewältigen. Sie können Ressourcen nach Bedarf zuweisen und so optimale Leistung und Kosteneffizienz gewährleisten.

6. sicherheit

Moderne PaaS-Lösungen verfügen häufig über integrierte Sicherheitsfunktionen, einschließlich automatischer Patches, sicherer Netzwerkkonfigurationen und Compliance-Zertifizierungen. Diese integrierte Sicherheit bedeutet weniger manuelle Konfiguration und weniger Tools von Drittanbietern, wodurch potenzielle Fehlerquellen reduziert werden.

7. wirtschaftliche Effizienz

Durch die Reduzierung des Bedarfs an mehreren Tools und Diensten kann PaaS zu Kosteneinsparungen führen. Unternehmen müssen nicht in Fachwissen für jedes einzelne Tool investieren, und die Betriebskosten können dank der Skaleneffizienz, die PaaS-Anbieter erzielen, gesenkt werden.

Zusammenfassend lässt sich sagen, dass eine Reihe von Tools die Art und Weise, wie wir über die Bereitstellung von Anwendungen und Infrastrukturen nachdenken, verändert hat, und jedes von ihnen bringt seine eigenen Komplexitäten mit sich. Moderne PaaS-Lösungen, wie Upsun, sind eine Antwort auf die Nachfrage nach einfacheren, einheitlichen und zukunftssicheren Bereitstellungsmethoden. Da sich die Technologie ständig weiterentwickelt, ist die Fähigkeit, mit minimalen Reibungsverlusten flexibel und anpassungsfähig zu bleiben, ein entscheidender Vorteil, der PaaS für viele Unternehmen zu einer attraktiven Wahl macht.

Möchten Sie es ausprobieren? Starten Sie noch heute Ihre kostenlose Testversion.

Sehen Sie sich dieses Video an