Wyzwania Przemysłu 4.0 - chmura czy lokalnie?

Główne wyzwanie

Jeśli przyszedłeś do przemysłu z innej branży, to możesz myśleć, że Przemysł 4.0 z punktu widzenia oprogramowania i integracja może być trudna. A jednak prawda jest taka, że teoretycznie proces ten powinien być prosty, przynajmniej w zakresie tzw. cloudification.

Często jednak tak nie jest. W Przemyśle 4.0 właściwa architektura infrastruktury a nie oprogramowanie jest podstawa sukcesu lub winowajcą niepowodzenia całego przedsięwzięcia.

Zastanawiasz się dlaczego? Cóż, jest kilka stosunkowo powszechne przyczyny na to, co przedstawiliśmy poniżej:

• Klienci z branży chcą mieć elastyczność w zakresie ich systemów komputerowych i skalowalność rozwiązań Cloud do agregacji i analizy danych, co oznacza, że często są przeciwnikami sztywnych, jednowymiarowych rozwiązań.
• Fabryki często nie mają dostępu do stabilnego, szybkiego i łatwo dostępnego połączenie internetowe.
• Fabryki muszą działać, jeśli sieć nie działai dlatego nie chcemy polegać wyłącznie na internecie.
• Konfiguracja IT w fabrykach jest następująca proste jak tylko się daprawie zawsze kompromisowo traktując HA, skalowalność i dostęp w imię praktyczności. To stwarza prawdziwe problemy, jeśli chodzi o modernizacje technologiczne.

Kwestie te prowadzą do częściowo sprzecznych wymagań, jeśli chodzi o podejście niehybrydowe (On-Premises lub Cloud):

• wykorzystywać infrastrukturę i usługi Cloud,
• fabryczny proces produkcyjny nie może na nim polegać.

In-Cloud czy On-Premises - jak to połączyć? Rozwiązanie

Najbardziej oczywistym podejściem jest posiadanie obu On-Premises usługi i In-Cloud usługi. Jednak może być trudno wiedzieć, jak oddzielić te dwie rzeczy.

Przyjrzyjmy się bliżej, co składa się na każdy z nich.

On-Premises zasadniczo obejmuje wszystko, co jest potrzebne do nieprzerwanego prowadzenia produkcji fabrycznej, podczas gdy Chmura usługi w zasadzie obejmują wszystkie inne aspekty. Wiąże się to z dwoma kwestiami:

• fabryki potrzebują wielu funkcji naszego produktu, aby uruchomić produkcję - to często obejmuje niektóre analityki,
• różni klienci mają różne potrzeby i wymagają gwarancji w zakresie tego, co jest potrzebne do kontynuowania procesu produkcji.

Oznacza to, że jeśli chcemy mieć jednorodną architekturę u wszystkich klientów, wiedząc, że niektóre fabryki mają słaby dostęp do Internetu i nie może polegać na Chmurze oparte na frontendach i backendach, wszystko powinno być On-Premises.

To powiedziawszy, istnieją alternatywy, ulepszone opcje, które również możemy rozważyć.

1. Posiadać zagregowane (dla wielu fabryk danego klienta) widoki i analitykę tylko w Chmurze.
2. Przenieś resztę usług pomiędzy Cloud i On-Premises w oparciu o potrzeby i dostępność.

Chociaż obie opcje zapewniają niezawodne alternatywyMogą one również powodować kilka problemów:

• usługi z uporczywością,
• synchronizacja stanu między chmurą a siedzibą firmy jest wyzwaniem, jeśli sieć nie jest niezawodna,
• jednorodna konfiguracja infrastruktury wymagana pomiędzy lokalem i chmurą, aby opcja ta była łatwa do utrzymania i wymiany.

Jednorodna konfiguracja infrastruktury

Konfiguracja chmury może być oparta na. IaaC oraz gitOps podejście. W tym przypadku zarówno infrastruktura jak i aplikacja są definiowane i zarządzane poprzez kod. W ANT Solutions osiągamy to poprzez Terraform, Flux i Gitlab CI/CD orkiestrując Cloud Setup, Resources, Kubernetes, Clusters i aplikacje.

Teraz możesz się zastanawiać, czy możemy użyć ta sama konfiguracja On-Premises, czyli często pojedyncza konfiguracja bare-metal. Cóż, odpowiedź brzmi: tak! Najbardziej oczywistym rozwiązaniem jest użycie Kubernetes również On-Premises i orkiestrowanie go poprzez tę samą bazę kodu. Jednak Kubernetes nie jest tani w administrowaniu dla scenariuszy On-Premises, a dodatkowo, Konfiguracja branży on-premises często jest minimalna, zawierające jeden lub dwa hosty typu bare metal.

Na szczęście istnieją narzędzia zaprojektowane, aby pomóc w tym. Należą do nich małe, tanie, jednowęzłowe konfiguracje Kubernetes zaprojektowane do użytku Edge/On-Premises:

• micro k8s,
• k3s

To pozwala nam używać tego samego gitOps Kod Fluxbez względu na to, gdzie aplikacja ma być wdrożona i ta sama konfiguracja aplikacji poprzez Wykresy na sterzewykluczając scenariusze podwójnej konfiguracji, podwójnego ustawienia, które są zarówno podatne na błędy, jak i kosztowne.

Synchronizacja po przestoju

Innym aspektem, nad którym musimy mieć kontrolę, jest możliwość synchronizacji danych pomiędzy On-Premises i Chmura. Dla uproszczenia wykluczmy wymianę stanu aplikacji i po prostu rozważmy pozyskiwanie danych z fabryki, które jest wymagane dla obu jeziora danych oraz zastosowania.

Pierwszą rzeczą, która przychodzi do głowy, jest wprowadzenie retries i buforowania. Jednak może się to wydawać problematyczne z punktu widzenia złożoność kodu i nie jest szczególnie niezawodna jako infrastruktura On-Premises, ponieważ może prowadzić do utrata danych.

Zamiast tego, odpowiedź brzmi komunikacja asynchroniczna. Wybieramy NATS które oferują szereg ciekawych funkcji, nie tylko zapewniając asynchroniczną komunikację, ale także automatyczną replikację danych.

Zawsze, gdy system cierpi z powodu przestoju, Serwery NATS będą synchronizować dane, dzięki czemu proces ten jest bezproblemowy dla naszej aplikacji. Oprogramowanie On-Premises nie dba o uruchomienie sieci, a nawet o istnieniu Usług w Chmurze, a Usługi w Chmurze otrzymują wszystkie dane, gdy tylko są dostępne.

Wynik - konfiguracja bez wprowadzania zmian

Wszystkie powyższe punkty umożliwiają nam ustawienie podstaw dla odsprzężonych adaptacyjnych architektura hybrydowa umożliwiający zamienianie usług między chmurą a siedzibą firmy przy minimalnym wysiłku i bez konieczności korzystania z jakichkolwiek produktów hybrydowych dostawcy usług w chmurze. Produkty te zazwyczaj zamykają nas w planach abonamentowych i nie pozwalają na interakcję scenariuszy On-Premises opartych na tej samej architekturze.

Fakt, że oba środowiska są rozłączne i jednorodne, pozwala nam również na swobodnie wybierać pomiędzy konfiguracją on-premises, konfiguracją cloud, konfiguracją hybrydową.

To z kolei pozwala nam jako ANT zaoferować naszym klientom jak najwięcej. konfiguracja działa najlepiej dla nich bez konieczności wprowadzania jakichkolwiek zmian w architekturze infrastruktury. Wszelkie modyfikacje są ściśle ograniczone do konfiguracji infrastruktury.

Należy wspomnieć, że zazwyczaj staramy się zachęcać naszych klientów do iść jak najdalej w kierunku Cloud, ponieważ opłaca się to w kategoriach HA i skalowalności.

Dodatkowo, homogeniczna architektura ułatwia testowanie różnych scenariuszy w replikowalnych środowiskach i zwiększa szybkość działania, silna redukcja błędów w produkcji.

Jeśli chcesz dowiedzieć się więcej o tym, jak ANT może pomóc Twojej firmie w osiągnięciu przewagi nad wyzwaniami ANT, przeczytaj więcej w naszej dedykowanej sekcji o Produkcja w chmurze.