Jedno jądro dla agentów, robotów i urządzeń

Reguła mówiąca, kto może zwolnić paletę, powinna obowiązywać niezależnie od tego, czy paletę zwalnia człowiek stukający w ekran, agent uzgadniający zamówienie, czy maszyna zdejmująca ją z regału. Dziś te trzy ścieżki idą przez trzy różne systemy z trzema różnymi modelami uprawnień, a reguła istnieje trzy razy — co znaczy, że w co najmniej jednym miejscu jest zła.

Trzy ciała, jeden zestaw pytań

Agenci programowi, fizyczne roboty i urządzenia osobiste wyglądają na różne problemy inżynierskie i na dole stosu nimi są. Planowanie ruchu nie ma nic wspólnego z uzgadnianiem faktur.

Ale każde z nich musi odpowiedzieć na te same cztery pytania, zanim zrobi cokolwiek, co dotyka biznesu:

W czyim imieniu działam? Co wolno mi teraz zrobić? Jakie są moje bieżące limity? I jaki ślad po sobie zostawiam?

To nie są pytania robotyczne ani agentowe. To są pytania systemu operacyjnego, a odpowiadanie na nie osobno w każdej domenie jest sposobem, w jaki organizacje kończą z robotem magazynowym respektującym limity bezpieczeństwa, ale nieświadomym blokady kredytowej klienta.

Co naprawdę znaczy „jedno jądro”

Nie jeden plik binarny działający na robocie kompletującym i na serwerze. Części, które muszą być wspólne, są węższe i ważniejsze.

Tożsamość. Jedno pojęcie tego, kim jest aktor — człowiekiem czy nie — i z czyjego upoważnienia działa. Urządzenie w czyjejś kieszeni działające jako jego delegat powinno być dla systemu tak samo czytelne jak jego logowanie.

Polityka. Reguła o zwalnianiu palety jest napisana raz i ewaluowana przez ten sam silnik, niezależnie od tego, które ciało pyta. Egzekwowanie lokalne może być cache’owane dla autonomii na brzegu, ale źródło jest jedno.

Ślad audytowy. Jeden zapis tego, co się wydarzyło, w jednym miejscu i w tym samym kształcie — czy aktorem był człowiek, agent, czy maszyna. To ta część zamienia trzy podsystemy w jeden system, który da się wytłumaczyć audytorowi.

Model stanu. Wszystkie trzy działają na tych samych encjach. Robot przewożący towar i agent obiecujący termin dostawy mówią o tej samej palecie.

Wszystko poniżej — sterowanie ruchem, czujniki, sterowniki, gwarancje czasu rzeczywistego — zostaje specyficzne dla domeny i tak powinno być.

Dlaczego brzeg nie jest przypadkiem brzegowym

Typowy zarzut brzmi, że roboty i urządzenia pracują offline, więc centralna polityka jest niepraktyczna.

To prawda i jest to ograniczenie projektowe, a nie kontrargument. Wzorzec jest znany z każdego systemu rozproszonego: polityka jest dystrybuowana na brzeg, ewaluowana lokalnie, a decyzje uzgadniane po powrocie łącza. Urządzenie pracuje dalej na zacache’owanej obwiedni; po prostu nie może jej przekroczyć, będąc odłączone.

Dostajesz autonomię z granicą zamiast autonomii z luką — a to właśnie w luce mieszkają incydenty.

Argument organizacyjny

Istnieje wersja tego wywodu, która nie ma nic wspólnego z architekturą.

Kiedy roboty, agenci i urządzenia żyją w osobnych systemach, dostają osobnych właścicieli. Inne zespoły, inni dostawcy, inne procesy przeglądowe i żadnego jednego miejsca, w którym ktoś może odpowiedzieć na pytanie „co temu aktorowi wolno”. Odpowiedzialność idzie za granicami systemów, więc rozbity stack produkuje rozbitą odpowiedzialność.

Postawienie ich na jednym jądrze jest częściowo decyzją techniczną, a głównie decyzją o tym, kto może odpowiedzieć na tamto pytanie jednym zapytaniem.

Dokąd to zmierza

Ciekawe nie jest to, że robot i agent współdzielą model uprawnień. Ciekawe jest to, co staje się możliwe, gdy już go współdzielą: praca, która przechodzi między ciałami bez przekazania.

Przychodzi zamówienie, agent sprawdza je wobec kredytu i stanów, robot na hali je kompletuje, urządzenie w ręce magazyniera pokazuje wyjątek i przyjmuje potwierdzenie — jeden proces, jedna polityka, jeden ślad audytowy, czterech aktorów, zero projektu integracyjnego.

To nie jest roadmapa robotyczna ani agentowa. To roadmapa systemu operacyjnego — i powód, żeby zbudować warstwę pod spodem, zanim zbuduje się cokolwiek na wierzchu.