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.
어렸을 때 저는 제트슨 가족을 보는 것을 좋아했습니다. 나이가 들어 소프트웨어를 작성하고 시스템 아키텍처를 만들고 구현하는 일을 하게 되면서 제트슨과 같은 주방이 실현되는 날은 절대 오지 않을 거라고 생각했습니다.
GPT(ChatGPT 등)는 제 생각을 바꿔놓았습니다.

계약상의 의무
건축가는 변호사처럼 생각해야 합니다. 시스템 또는 구성 요소 간의 계약(API)을 정의합니다. 이러한 API의 남용이나 오용을 모니터링합니다.

저는 Swagger 에디터를 사용하여 이러한 계약을 정의하고, 목업에 암시된 상호 작용과 일치하도록 API를 작성합니다. 팀과 함께 디자인을 검토하고, 시나리오를 통해 API가 사용 사례에 맞는지, 성능 병목 현상이 발생하지 않는지 확인하고, 그 과정에서 가능한 한 많이 시뮬레이션하고 자동화합니다.

처음부터 제대로 구현하기 위해 매우 신중을 기했습니다. 물론 처음부터 완벽할 수는 없었습니다. 따라서 시스템의 나머지 부분에 대한 비용/영향을 최소화하면서 API를 발전시킬 수 있는 방법도 고려해야 했습니다. API가 배포되면 정직한 정치인이 #미국헌법을 수호하듯 제가 지켜야 할 무언가가 될 것입니다. 팀은 API에 영향을 미치는 모든 변경 사항에 주의를 기울여야 했습니다.

API 메시... API 엉망진창에 가깝습니다!
API는 더 많은 API와 라이브러리에 의존하는 API에 의존합니다. 시스템이 충분히 커지면 이러한 복잡성은 병목 현상이 됩니다. 작은 변화도 큰 파급 효과를 가져올 수 있습니다. 일부 접근 방식(예: 연합 #GraphQL)은 이러한 복잡성을 훌륭하게 관리하는 데 도움이 됩니다. 하지만 여전히 많은 취약성이 존재할 수 있는 API를 사용합니다. #애자일이든 아니든, 복잡한 API 웹을 개발하는 것은 복잡하고 전문 기술이 필요하며 예상치 못한 문제들로 가득합니다.

ChatGPT 스타일의 주방 대화
제트슨의 주방에는 다양한 부품, 센서, 하드웨어, 입력 및 출력으로 구성된 여러 시스템이 포함되어 있습니다. 주방에서 독립적인 시스템 간의 상호 작용이 복잡하다는 점, 젯슨 부부의 주방 구성 요소가 다양한 공급업체 또는 제조업체에서 제공된다는 점을 고려하면 기존 API 설계로는 비전을 달성할 수 없습니다. 전혀 실용적이지 않습니다.

이제 API와 Jetsons의 주방에 대해 #chatgpt 스타일로 생각해 봅시다.

간단하게 피자를 예로 들어보겠습니다. 여러분(또는 로봇)이 처음부터 피자를 만듭니다.

오븐이 냉장고에 묻습니다: "피자가 있네요. 이게 저수분 모짜렐라인지 알려줄 수 있나요?"라고 묻습니다.

냉장고: "그건 모짜렐라도 아니에요. 이 피자에는 뭰스터 치즈가 들어 있는 게 틀림없어요. 그리고 사람이 30분 전에 내용물을 일부 제거했기 때문에 피자에 뮌스터 치즈가 들어 있을 확률이 상당히 높습니다."

이때 주방에 있는 센서가 방 안을 훤히 들여다보고 있습니다. 센서: "이 피자의 크러스트가 콜리플라워로 만들어졌으니 주의하세요. 치즈 종류에 대한 비디오 센서의 평가에 동의합니다. 최근에 새로운 치즈가 주방에 들어온 적이 없습니다."

오븐: "제가 알아야 할 다른 사항은 없나요?"

센서: "반죽의 온도가 47F입니다. 이는 상온 반죽을 사용하는 전문 셰프의 의견보다 더 차갑습니다."

오븐: "좋아요. 어떻게 해야 할지 알겠어요. 반죽이 식었으니 레시피에 명시된 온도보다 조금 낮은 온도에서 요리를 시작하겠습니다. 그런 다음 바삭한 크러스트를 제공하기 위해 바닥 요소의 온도를 높이겠습니다. 수분을 주의 깊게 관찰하고 바람직하지 않은 수준의 수분을 완화하기 위해 대류를 사용할 수 있습니다."

독립적인 시스템을 계약적으로 묶는 API는 어디에 있나요? API는 사라지지 않았습니다. 예를 들어 오븐의 두뇌에는 온도 컨트롤러 및 센서와의 상호 작용을 위한 무수히 많은 API가 있습니다(예: 온도 컨트롤러 및 센서와의 상호 작용 등). 여기서 핵심은 시스템 간의 인터페이스가 더 이상 고정되고 딱딱한 API가 아니라는 것입니다. 메서드 서명도, 경로도, 페이로드 사양도 없습니다. 대신 감각과 기능에 관한 대화가 이루어집니다.

무슨 "두뇌"?
Kence Anderson의 저서 '자율 AI 설계'는 복잡한 시스템을 여러 개의 독립적인 "두뇌"로 분해할 수 있는 방법을 잘 설명합니다. 그의 책에 따르면 각 두뇌는 #데이터과학, #머신러닝, #데이터엔지니어링과 결합된 인간의 안내를 통해 독립적으로 개발 및 개선될 수 있습니다.

무슨 일이 일어나고 있나요?
앞으로의 미래가 기대됩니다. 아키텍트가 API와 관련하여 복잡한 시스템 설계를 재고하는 방식은 피할 수 없는 변화라고 생각합니다. 그리고 아마추어 피자를 만드는 사람으로서 더 나은 #디트로이트피자를 만들기 위해 GPT의 도움을 받는 날을 기다리며 미각에 물이 차오르고 있습니다.