Erkläre, wie neue Technologien wie LLMs und ChatGPT die Anwendungsprogrammierschnittstellen (APIs) in Zukunft revolutionieren können. Nenne ein Beispiel dafür, wie diese APIs funktionieren könnten.
Explain how new technologies, like LLMs and ChatGPT, may revolutionize Application Programming Interfaces (APIs) in the future. Provide an example of how these APIs might work.
As a kid, I loved watching the Jetsons. As I grew older and ended up writing software and creating & implementing architectures for systems, I thought I would never see the day when a Jetsons-like kitchen would be feasible.
GPT (ChatGPT, etc.) has changed my mind.

Contractual Obligations
As an architect, you kind of need to think like a lawyer. You define contracts (APIs) between systems or components. You monitor those APIs for abuse or misuse.

I would use Swagger editor to define those contracts, and I would write the APIs to match interactions implied in mock-ups. I would vet the design with the team, I would walk through scenarios to see if the API would fit the use case and would not introduce performance bottlenecks, and I would simulate and automate as much as I could along the journey.

I was very careful to get it right the first time. It was never perfect the first time, of course. So, I also had to consider how the API could evolve while minimizing costs/impact to the rest of the system. The API, once deployed, would become something I would guard, like an honest politician guards the #usconstitution. The team had to be careful with any change that impacted the API.

API Mesh... More like API mess!
APIs rely on APIs which rely on more APIs and libraries. Once a system gets large enough, that complexity becomes a bottleneck. Small changes can have a huge ripple effect. Some approaches (like federated #GraphQL) help manage this complexity nicely. But it still involves an API under which there can exist a lot of fragility. #Agile or not, developing a complicated web of APIs is complex, requires specialized skills, and is full of unforeseen challenges.

The Kitchen Conversation, ChatGPT-style
The Jetsons' kitchen involves a number of systems, each composed of various parts, sensors, hardware, inputs and outputs. Considering the complexity of interactions between independent systems in a kitchen, the fact that the Jetsons' kitchen components would come from various vendors or manufacturers, traditional API design would not be able to fulfill the vision. Not practical, at all.

Now, let's think about APIs and the Jetsons' kitchen, #chatgpt -style.

Let's keep it simple: pizza. You (or your robot) make a pizza from scratch.

The oven asks the refrigerator: "I see we have a pizza. Can you tell me if this is low-moisture mozzarella?"

Refrigerator: "That's not even mozzarella. This pizza must have Muenster cheese as that is all I had in me. And the human removed some of the contents 30 minutes ago, so the probability of Muenster cheese on that pizza is quite high."

A sensor from the kitchen who has eyes across the room chimes in at this point. Sensor: "Beware that the crust of this pizza is made of cauliflower. I agree with the video sensor's assessment regarding the type of cheese. No new cheese entered the kitchen recently."

Oven: "Anything else I should know?"

Sensor: "The temperature of the dough is 47F. This is cooler than the expert chef consensus of using room-temperature dough."

Oven: "Great. I know what to do. Since the dough is cool, I will start cooking with a temperature a little lower than the recipe specifies. Then I will increase the temp of bottom element so as to provide a nice crisp crust. I will keep a close eye on moisture and may use convection to mitigate any undesirable levels of moisture."

Where is the API that contractually binds the independent systems? APIs are not gone. For instance, the brain of the Oven will have myriad APIs (e.g. for interacting with temperature controllers and sensors, etc.). The key here is that the interface between systems is no longer a fixed, rigid API. No method signatures, no paths, no payload specifications. Instead, a conversation relating to senses and capabilities.

What "brain"?
Kence Anderson's book Designing Autonomous AI describes nicely how a complex system can be decomposed into a number of independent "brains." Each brain, in his book, can be independently developed and refined, with human guidance married with #datascience, #machinelearning and #dataengineering.

What's Cookin'?
I am excited for what the future holds. How architects rethink complex system design with regards to APIs is, in my opinion, something that is inevitable. And, as an amateur pizza maker, my taste buds are watering for the day I get some GPT help to make an even better #detroitpizza.
Als Kind habe ich gerne die Jetsons gesehen. Als ich älter wurde und schließlich Software schrieb und Architekturen für Systeme entwarf und implementierte, dachte ich, dass ich den Tag nie erleben würde, an dem eine Jetsons-ähnliche Küche machbar sein würde.
GPT (ChatGPT, etc.) hat meine Meinung geändert.

Vertragliche Verpflichtungen
Als Architekt musst du irgendwie wie ein Anwalt denken. Du definierst Verträge (APIs) zwischen Systemen oder Komponenten. Du überwachst diese APIs auf Missbrauch oder Fehlbedienung.

Ich würde den Swagger-Editor verwenden, um diese Verträge zu definieren, und ich würde die APIs so schreiben, dass sie den in den Mock-ups angedeuteten Interaktionen entsprechen. Ich überprüfte das Design mit dem Team, ging Szenarien durch, um zu sehen, ob die API für den Anwendungsfall geeignet ist und keine Leistungsengpässe verursacht, und ich simulierte und automatisierte so viel wie möglich auf diesem Weg.

Ich war sehr darauf bedacht, es gleich beim ersten Mal richtig zu machen. Natürlich war es nie beim ersten Mal perfekt. Deshalb musste ich auch überlegen, wie die API weiterentwickelt werden konnte, ohne die Kosten und Auswirkungen auf das übrige System zu erhöhen. Die API würde nach ihrer Einführung von mir gehütet werden, wie ein ehrlicher Politiker die #usconstitution bewacht. Das Team musste bei jeder Änderung, die sich auf die API auswirkte, vorsichtig sein.

API Mesh... Eher ein API-Durcheinander!
APIs beruhen auf APIs, die wiederum auf weiteren APIs und Bibliotheken beruhen. Sobald ein System groß genug ist, wird diese Komplexität zu einem Engpass. Kleine Änderungen können eine große Wirkung haben. Einige Ansätze (wie föderierte #GraphQL) helfen dabei, diese Komplexität in den Griff zu bekommen. Aber es handelt sich dabei immer noch um eine API, die sehr anfällig sein kann. Ob #Agile oder nicht, die Entwicklung eines komplizierten Netzes von APIs ist komplex, erfordert spezielle Fähigkeiten und birgt viele unvorhergesehene Herausforderungen.

Das Küchengespräch im ChatGPT-Stil
Die Küche der Jetsons besteht aus einer Reihe von Systemen, die jeweils aus verschiedenen Teilen, Sensoren, Hardware, Ein- und Ausgängen bestehen. In Anbetracht der Komplexität der Interaktionen zwischen unabhängigen Systemen in einer Küche und der Tatsache, dass die Komponenten der Jetsons-Küche von verschiedenen Anbietern oder Herstellern stammen würden, wäre das traditionelle API-Design nicht in der Lage, die Vision zu erfüllen. Überhaupt nicht praktikabel.

Lasst uns nun über APIs und die Küche der Jetsons nachdenken, im Stil von #chatgpt.

Halten wir es einfach: Pizza. Du (oder dein Roboter) machst eine Pizza von Grund auf.

Der Ofen fragt den Kühlschrank: "Ich sehe, wir haben eine Pizza. Kannst du mir sagen, ob das feuchtigkeitsarmer Mozzarella ist?"

Der Kühlschrank: "Das ist nicht einmal Mozzarella. Diese Pizza muss mit Münsterkäse belegt sein, denn das ist alles, was ich in mir hatte. Und der Mensch hat vor 30 Minuten einen Teil des Inhalts entnommen, also ist die Wahrscheinlichkeit ziemlich hoch, dass sich Münsterkäse auf dieser Pizza befindet."

An dieser Stelle meldet sich ein Sensor aus der Küche zu Wort, der den Raum beobachtet. Sensor: "Pass auf, dass die Kruste dieser Pizza aus Blumenkohl besteht. Ich stimme der Einschätzung des Videosensors bezüglich der Käsesorte zu. Es ist kein neuer Käse in die Küche gekommen."

Backofen: "Gibt es sonst noch etwas, das ich wissen sollte?"

Sensor: "Die Temperatur des Teigs beträgt 47 F. Das ist kühler als der Expertenkonsens, der besagt, dass der Teig Zimmertemperatur haben sollte."

Backofen: "Großartig. Ich weiß, was zu tun ist. Da der Teig kühl ist, beginne ich mit einer etwas niedrigeren Temperatur als im Rezept angegeben. Dann erhöhe ich die Temperatur des unteren Elements, um eine schöne knusprige Kruste zu bekommen. Ich werde die Feuchtigkeit genau im Auge behalten und eventuell die Umluft verwenden, um unerwünschte Feuchtigkeit zu reduzieren.

Wo ist die API, die die unabhängigen Systeme vertraglich bindet? Die APIs sind nicht verschwunden. Das Gehirn des Backofens wird zum Beispiel unzählige APIs haben (z. B. für die Interaktion mit Temperaturreglern und Sensoren usw.). Der Schlüssel dazu ist, dass die Schnittstelle zwischen den Systemen nicht mehr eine feste, starre API ist. Es gibt keine Methodensignaturen, keine Pfade, keine Spezifikationen für die Nutzlast. Stattdessen handelt es sich um eine Konversation über Sinne und Fähigkeiten.

Welches "Gehirn"?
Kence Anderson beschreibt in seinem Buch Designing Autonomous AI sehr schön, wie ein komplexes System in mehrere unabhängige "Gehirne" zerlegt werden kann. Jedes dieser Gehirne kann unabhängig voneinander entwickelt und verfeinert werden, und zwar unter menschlicher Anleitung, gepaart mit #Datenwissenschaft, #Maschinenlernen und #Daten-Engineering.

Was gibt's Neues?
Ich bin gespannt, was die Zukunft bringt. Die Art und Weise, wie Architekten das Design komplexer Systeme in Bezug auf APIs neu überdenken, ist meiner Meinung nach unvermeidlich. Und als Hobby-Pizzabäcker sind meine Geschmacksknospen ganz heiß auf den Tag, an dem ich mit Hilfe des GPT eine noch bessere #detroitpizza backen kann.
creative_writing
de