Pet, Cattle, Herd

“I don’t know if you know, sort of the metaphor of, you know, pets vs. cattle? Yeah, servers are like pets. You give them a name. If they get ill, you nurture them back to health. VMs, cloud is like cattle, you know? You number them. If some fall ill, you put them out to pasture and you get a new one. You dont care about that. But in reality, that’s still, if you run in a VM world. In this new world of serverless, there is not even cattle anymore. There is only the herd. Only the kind of things that you want to build — the application you want to build and we’ll take care of the management of all the individual pieces underneath that.” sagte Werner Vogels auf dem AWS Summit 2016 über die neue Generation von Services.

Folie vom AWS Summit 2016 (https://youtu.be/b7yqd7z1RBQ?t=1h15m30s)

Mein Freund Soenke Ruempler, selbst ein leidenschaftlicher Serverless-Entwickler, analysierte für einen Vortrag, warum er glaubt, dass AWS Lambda (eine verwaltete Function-as-a-Service Implementierung von AWS) für ihn die richtige Wahl für zukünftige Projekte ist.

If you believe in the mantra, that “anything, that is not core value to your business, you should not do.”, herd services might be the right choice for you to build your digital service upon.

Soenke hat eine Reihe von Folien erstellt, mit einer umfassenden Liste der betrieblichen Aufgaben, die man übernehmen müsste, wenn man eine API selbst in der “alten Welt” der Hardware-Server aufbauen würde. Von dort aus geht er auf alle verfügbaren Arten von Diensten ein (hauptsächlich im AWS-Ökosystem) und zeigt auf, wie sie den Problembereich auflösen, um den man sich anfänglich hätte kümmern müssen. Aus Soenke Ruemplers Vortrag “Serverless (Web)Apps with AWS API Gateway and Lambda https://slidr.io/s0enke/serverless-web-apps-with-aws-api-gateway-and-lambda

Die Idee der “Herd”-Services selbst ist nicht ganz neu, da SQS oder S3 bereits vor 10 Jahren das Licht der Welt erblickten. Allerdings sehen wir erst jetzt, 10 Jahre später, dass mehr Services den Mustern folgen, die SQS und S3 so erfolgreich gemacht haben.

Ich glaube fest daran, dass die Art und Weise, wie wir digitale Dienste betreiben, sich erneut verändert - weg vom Betreiben und Entwickeln von Apps für Cloud Computing in einer “Cattle”-Style-Umgebung, hin zum Entwickeln von Apps für z.B. “Function as a Service” - “Herd”-Style-Umgebungen. Da mit dem Betrieb virtueller Maschinen noch immer gewisse Kostenfaktoren verbunden sind, wie der Betrieb und die Wartung eines Betriebssystems oder auch nur die Sicherstellung, dass den Instanzen, die Ihre Docker-Container ausführen, nicht der Festplattenspeicher ausgeht, entstehen gewisse Kostenfaktoren für Ihr Unternehmen und noch mehr Kosten für Experimente.

Die meisten “Herd”-Style-Services kommen mit mehr Vorteilen - von denen Skalierung und bedarfsgerechte Abrechnung für mich besonders hervorstechen. Letzteres senkt wirklich Ihre Experimentierkosten, da die kleinste abrechenbare Einheit sich von einer (1) Instanzstunde zu einem (1) Funktionsaufruf oder einem (1) GET zu Ihrer DB verschiebt. Dies ermöglicht Ihnen, in dieser neuen Ära der echten mandantenfähigen On-Demand-Managed-Services mehr Experimente in kürzerer Zeit bei geringeren Kosten durchzuführen.