Cloud Architecture Mistakes: The High Costs Of A DIY Mindset

Opublikowane ponownie przez Plato

Obserwuje: 0

Jest to pięcioczęściowa seria poświęcona kosztownym błędom, które często popełniają organizacje podczas budowania architektury chmurowej. Część pierwsza wyjaśnił, w jaki sposób organizacje przenoszące się do chmury mogą szybko stracić widoczność i kontrolę nad przetwarzaniem swoich danych, oraz szczegółowo omówił, jak uniknąć tego błędu. Część druga dotyczy sposobów, w jakie robienie tego samemu może się nie udać.

Co byś zrobił, gdyby Twoja firma wymagała zbudowania sieć w chmurze z przyszłościową architekturą i spójnym projektem w wielu chmurach? (Czy wspominałem, że Twoja sieć będzie musiała zapewnić wbudowane zabezpieczenia z widocznością operacyjną i kontrolą, a ponadto zoptymalizować koszty?)

Czy stworzyłbyś złożoną sieć skryptów automatyzacji, aby zbudować własną sieć?

Czy wolisz kupić pojedynczą, spójną i powtarzalną architekturę chmurową ze wsparciem dla przedsiębiorstw?

Według niedawnego raport EMA, zespoły zajmujące się sieciami wielochmurowymi zgłaszają trudności w zbudowaniu spójnej sieci w ich środowisku wielochmurowym, przy czym 97% organizacji stoi przed poważnymi wyzwaniami — w szczególności monitorowaniem i zarządzaniem pojemnością, a także widocznością i przepustowością — podczas wdrażania połączeń między ich sieciami i zarządzania nimi i chmura. Wiele przedsiębiorstw obsługujących obciążenia o znaczeniu krytycznym wolałoby kupić rozwiązanie tego typu niż je zbudować.

Co zaskakujące, zauważyłem, że wiele niedoinformowanych organizacji wciąż popełnia błąd „zrób to sam”. Myślą, że mogą zatrudnić programistów, wykorzystać natywne konstrukcje sieciowe i bezpieczeństwa CSP oraz zbudować sieć w chmurze za pomocą skryptów automatyzacji. To błędne, czasochłonne i kosztowne podejście. Chociaż takie podejście wiąże się z kilkoma wyzwaniami, przeanalizujmy niektóre z tych krytycznych.

Skrypty automatyzacji specyficzne dla CSP, takie jak CloudFormation, dotyczą tylko określonego CSP. W scenariuszu z wieloma chmurami zakończą się niepowodzeniem. A według A Ankieta firmy Microsoft, 95% decydentów biznesowych stwierdziło, że wiele chmur ma kluczowe znaczenie dla ich sukcesu biznesowego.

Wspieranie skryptu automatyzacji wymagałoby zaangażowania krytycznych zasobów do wykonywania przyziemnych zadań, a nie bycia częścią rozwoju firmy i inicjatyw strategicznych. Skrypty te nie mają żadnej scentralizowanej płaszczyzny kontroli. Nie ma „mózgu ani inteligencji”. Chodzi głównie o uruchomienie i zapomnienie. Jeśli zmienią się warunki sieciowe (na przykład nauczona zostanie nowa trasa BGP), statyczny skrypt automatyzacji nie może podjąć żadnej akcji w oparciu o nową zmianę stanu. Nie ma dostępnej pętli sprzężenia zwrotnego.

Zachowanie sieci może się zmienić w każdej chwili. Może wystąpić skok wymagający automatycznego skalowania infrastruktury. Możesz mieć atakującego próbującego wstrzyknąć oprogramowanie ransomware do sieci. Bezmyślny skrypt automatyzacji nie może dostosować się do tych zmian.

Jeśli automatyk zachoruje lub odejdzie z organizacji, cała wiedza przepadnie, a zrozumienie i udoskonalenie tego skryptu automatyzacji przez nową osobę będzie prawie niemożliwe.

Nie wspominając o tym, że koszt zatrudnienia lub zastąpienia tej osoby gwałtownie rośnie z powodu niedoboru umiejętności w zakresie obsługi wielu chmur.

Zalecenia

Chociaż rozwiązanie typu „zrób to sam” może wydawać się najłatwiejsze i najbardziej opłacalne w krótkim okresie, inwestycja w chmurową platformę sieciową stworzoną w chmurze, której celem jest utrzymanie Twojej firmy w czołówce, zapewni Ci długoterminowy sukces i skalowalność . Organizacje powinny skoncentrować swoje zespoły na innowacjach i czasie wprowadzania produktów na rynek, zamiast na ciągłym pisaniu i ulepszaniu skryptów. Korzyści, których należy szukać u dostawcy platformy sieciowej w chmurze, powinny obejmować co najmniej:

Scentralizowany kontroler z rozproszoną płaszczyzną danych
Oparta na zamiarach i osadzona kontrola sieci i bezpieczeństwa
Możliwości samoleczenia z wykrywaniem anomalii
Analiza zachowania sieci oparta na ML
Solidne wsparcie dla Terraform, które umożliwiłoby pisanie Terraform niezależnie od CSP
Wsparcie dla wszystkich głównych dostawców CSP do obsługi aplikacji o znaczeniu krytycznym dla Twojej firmy

Pułapki dostawców, których należy unikać, obejmują:

Starsi dostawcy sprzętu z niedojrzałymi i skoncentrowanymi na sprzęcie opcjami, które są nieodpowiednie dla nowoczesnych i krytycznych obciążeń biznesowych
Dostawcy zabezpieczeń dla Twoich potrzeb w zakresie sieci w chmurze
Dostawcy próbujący „zmyć w chmurze” swoją starszą technologię sprzętową, podnosząc i przesuwając kod sprzętowy jako maszynę wirtualną i nazywając to rozwiązaniem sieciowym w chmurze

Wnioski

Samodzielne robienie tego w chmurze – przy użyciu natywnej sieci i struktury bezpieczeństwa CSP oraz wielu zautomatyzowanych skryptów – może początkowo wydawać się przystępnym skrótem, ale może szybko doprowadzić do przypadkowego rozwiązania, które powoduje nieefektywność i zwiększa koszty. Skrypty tylko dla CSP nie będą działać w środowisku wielu chmur, a zautomatyzowane skrypty wymykają się scentralizowanej kontroli. Z drugiej strony inteligentna platforma sieciowa w chmurze zapewnia scentralizowaną kontrolę, możliwości samonaprawy, możliwość lepszego wykorzystania uczenia maszynowego oraz wsparcie dla wszystkich głównych dostawców CSP.

Dalej: W części trzeciej zbadamy zagrożenia związane z nieodpowiednimi opcjami showback i chargeback oraz korzyści płynące z posiadania rozwiązania rozliczeniowego zbudowanego na platformie niezależnej od CSP.