Co jest natywne dla chmury? Nowoczesny sposób tworzenia oprogramowania

Termin „natywny dla chmury” jest szeroko rozpowszechniany, zwłaszcza przez dostawców chmury. Nie tylko to, ale ma nawet własną podstawę: Cloud Native Computing Foundation (CNCF), uruchomioną w 2015 roku przez Linux Foundation.

Zdefiniowano „natywny dla chmury”

W ogólnym zastosowaniu „natywny dla chmury” to podejście do tworzenia i uruchamiania aplikacji, które wykorzystuje zalety modelu dostarczania chmury obliczeniowej. „Natywne dla chmury” dotyczy sposobu tworzenia i wdrażania aplikacji, a nie tego, gdzie. Oznacza to, że aplikacje działają w chmurze publicznej, a nie w lokalnym centrum danych.

CNCF definiuje „natywny dla chmury” nieco węższy, co oznacza używanie stosu oprogramowania open source do kontenerowania, w którym każda część aplikacji jest spakowana we własnym kontenerze, dynamicznie aranżowana, tak aby każda część była aktywnie planowana i zarządzana w celu optymalizacji zasobów wykorzystanie i zorientowane na mikrousługi, aby zwiększyć ogólną elastyczność i łatwość konserwacji aplikacji.

„Aplikacja natywna w chmurze została zaprojektowana specjalnie pod kątem elastycznego i rozproszonego charakteru wymaganego przez nowoczesne platformy przetwarzania w chmurze” - mówi Mike Kavis, dyrektor zarządzający w firmie konsultingowej Deloitte. „Te aplikacje są luźno powiązane, co oznacza, że ​​kod nie jest połączony na stałe z żadnym ze składników infrastruktury, dzięki czemu aplikacja może być skalowana w górę iw dół na żądanie i obejmować koncepcje niezmiennej infrastruktury. Zazwyczaj te architektury są tworzone przy użyciu mikrousług, ale nie jest to obowiązkowe ”.

W przypadku aplikacji natywnych w chmurze dużą różnicą jest więc to, jak aplikacja jest budowana, dostarczana i obsługiwana - mówi Andi Mann, główny rzecznik technologii w firmie Splunk, dostawcy usług w chmurze. „Korzystanie z usług w chmurze oznacza używanie elastycznych i skalowalnych komponentów, takich jak kontenery, w celu dostarczania dyskretnych i wielokrotnego użytku funkcji, które integrują się w dobrze opisany sposób, nawet poza granicami technologicznymi, takimi jak wielochmurowa chmura, co umożliwia zespołom dostawczym szybkie iteracje przy użyciu powtarzalnej automatyzacji i orkiestracji”.

Tworzenie aplikacji natywnych w chmurze zazwyczaj obejmuje programowanie, zwinną metodologię, mikrousługi, platformy chmurowe, kontenery takie jak Kubernetes i Docker oraz ciągłe dostarczanie - krótko mówiąc, każdą nową i nowoczesną metodę wdrażania aplikacji.

Z tego powodu naprawdę chcesz mieć model platformy jako usługi (PaaS). PaaS nie jest wymagany, ale znacznie ułatwia pracę. Zdecydowana większość klientów korzystających z chmury zaczyna od infrastruktury jako usługi (IaaS), która pomaga wyodrębnić ich aplikacje z podstawowego sprzętu. Ale PaaS dodaje dodatkową warstwę, aby wyodrębnić podstawowy system operacyjny, dzięki czemu możesz całkowicie skupić się na logice biznesowej swojej aplikacji i nie martwić się wykonywaniem wywołań systemu operacyjnego.

Powiązane nagranie wideo: Jakie jest podejście natywne dla chmury?

W tym 60-sekundowym filmie dowiesz się, jak podejście natywne dla chmury zmienia sposób, w jaki przedsiębiorstwa strukturyzują swoje technologie - od Craiga McLuckiego, założyciela i dyrektora generalnego firmy Heptio oraz jednego z wynalazców Kubernetes o otwartym kodzie źródłowym.

Różnice między aplikacjami natywnymi dla chmury i lokalnymi

Tworzenie aplikacji natywnych dla chmury wymaga zupełnie innej architektury niż tradycyjne aplikacje korporacyjne.

Języki

Lokalne aplikacje napisane do uruchamiania na serwerach firmowych są zwykle pisane w tradycyjnych językach, takich jak C / C ++, C # lub inny język Visual Studio, jeśli są wdrażane na platformie Windows Server i korporacyjna Java. A jeśli jest na komputerze mainframe, prawdopodobnie w Cobolu.

Aplikacje natywne dla chmury są częściej pisane w języku zorientowanym na WWW, co oznacza HTML, CSS, Java, JavaScript, .Net, Go, Node.js, PHP, Python i Ruby.

Możliwość aktualizacji

Aplikacje natywne dla chmury są zawsze aktualne i aktualne. Aplikacje natywne dla chmury są zawsze dostępne.

Aplikacje lokalne wymagają aktualizacji i zwykle są dostarczane przez dostawcę na zasadzie subskrypcji i wymagają przestoju podczas instalowania aktualizacji.

Elastyczność

Aplikacje natywne dla chmury wykorzystują elastyczność chmury, wykorzystując zwiększone zasoby podczas gwałtownego wzrostu wykorzystania. Jeśli aplikacja handlu elektronicznego oparta na chmurze doświadcza gwałtownego wzrostu użycia, możesz ustawić ją tak, aby korzystała z dodatkowych zasobów obliczeniowych, dopóki ten wzrost nie spadnie, a następnie wyłącz te zasoby. Aplikacja natywna dla chmury może w razie potrzeby dostosować się do zwiększonych zasobów i skalować.

Aplikacja lokalna nie może skalować się dynamicznie.

Wieloosobowość

Aplikacja natywna dla chmury nie ma problemu z pracą w zwirtualizowanej przestrzeni i współdzieleniem zasobów z innymi aplikacjami.

Wiele aplikacji lokalnych albo nie działa dobrze w środowisku wirtualnym, albo w ogóle nie działa i wymaga niezwirtualizowanej przestrzeni.

Połączone zasoby

Aplikacja lokalna ma dość sztywne połączenia z zasobami sieciowymi, takimi jak sieci, zabezpieczenia, uprawnienia i magazyn. Wiele z tych zasobów wymaga zakodowania na stałe i psują się, jeśli cokolwiek zostanie przeniesione lub zmienione.

„Sieć i pamięć masowa są zupełnie inne w chmurze. Termin „re-platforming” oznacza zwykle pracę mającą na celu dostosowanie się do zmian w technologiach sieciowych, pamięci masowej, a nawet bazodanowych, aby umożliwić działanie aplikacji w chmurze ”- mówi Kavis z Deloitte.

Przestój

W chmurze występuje większa nadmiarowość niż lokalna, więc jeśli dostawca usług w chmurze doświadczy awarii, inny region może przejąć zapas czasu.

Aplikacje lokalne mogą być gotowe do przełączania awaryjnego, ale istnieje duża szansa, że ​​jeśli serwer ulegnie awarii, aplikacja przestanie działać.

Automatyzacja

Tak duża część chmury jest zautomatyzowana, w tym zarządzanie aplikacjami. „Korzyści płynące z dostarczania natywnego dla chmury, zwłaszcza szybkość i elastyczność, w znacznym stopniu polegają na niezawodnych, sprawdzonych i poddanych audytowi znanych i dobrych procesach, które są wykonywane wielokrotnie w razie potrzeby przez narzędzia do automatyzacji i orkiestracji, a nie poprzez interwencję ręczną” - mówi Splunk's Mann. Inżynierowie powinni starać się zautomatyzować praktycznie wszystko, co robią więcej niż raz, aby zapewnić powtarzalność, samoobsługę, elastyczność, skalowalność oraz audyt i kontrolę.

Aplikacjami lokalnymi trzeba zarządzać ręcznie.

Modułowa konstrukcja

Aplikacje lokalne są zwykle monolityczne w projekcie. Z pewnością zrzucają część pracy do bibliotek, ale ostatecznie jest to jedna duża aplikacja z całą masą podprogramów. Aplikacje natywne dla chmury są znacznie bardziej modułowe, a wiele funkcji jest podzielonych na mikrousługi. Dzięki temu można je wyłączać, gdy nie są potrzebne, i wprowadzać aktualizacje do tego jednego modułu, a nie do całej aplikacji.

Bezpaństwowość

Luźno powiązany charakter chmury oznacza, że ​​aplikacje nie są powiązane z infrastrukturą, co oznacza, że ​​są bezpaństwowe. Aplikacja natywna w chmurze przechowuje swój stan w bazie danych lub innej zewnętrznej jednostce, dzięki czemu instancje mogą przychodzić i odchodzić, a aplikacja może nadal śledzić, gdzie w jednostce pracy znajduje się aplikacja. „To jest istota luźno powiązanych. Brak powiązania z infrastrukturą pozwala aplikacji działać w sposób wysoce rozproszony i nadal utrzymywać swój stan niezależnie od elastycznego charakteru infrastruktury bazowej ”- mówi Kavis.

Większość aplikacji lokalnych jest stanowych, co oznacza, że ​​przechowują stan aplikacji w infrastrukturze, w której działa kod. Z tego powodu aplikacja może zostać uszkodzona podczas dodawania zasobów serwera.

Wyzwania związane z przetwarzaniem natywnym dla chmury

Mann mówi, że jednym z największych błędów popełnianych przez klientów jest próba przeniesienia swoich starych aplikacji lokalnych do chmury. „Próba przeniesienia istniejących aplikacji - zwłaszcza monolitycznych starszych aplikacji - i przeniesienia ich do infrastruktury chmury nie przyniesie korzyści z podstawowych funkcji natywnych dla chmury”.

Zamiast tego powinieneś starać się robić nowe rzeczy na nowe sposoby, albo umieszczając nowe aplikacje natywne dla chmury w nowej infrastrukturze chmury, albo rozbijając istniejące monolity w celu ich refaktoryzacji przy użyciu zasad natywnych dla chmury od podstaw.

Musisz także zrezygnować ze starych metod deweloperskich. Model kaskadowy z pewnością nie wystarczy, a nawet programowanie zwinne może nie wystarczyć. Dlatego musisz przyjąć nowe podejścia natywne dla chmury, takie jak tworzenie minimalnego opłacalnego produktu (MVP), testowanie na wielu odmianach, szybka iteracja i ścisła współpraca ponad granicami organizacyjnymi w modelu DevOps.

Istnieje wiele aspektów natywności chmury, w tym usługi infrastrukturalne, automatyzacja / orkiestracja, wirtualizacja i konteneryzacja, architektura mikrousług i obserwowalność. Wszystko to oznacza nowy sposób robienia rzeczy, co oznacza łamanie starych nawyków w miarę uczenia się nowych sposobów. Zrób to więc w umiarkowanym tempie.

Dowiedz się więcej o powiązanych technologiach natywnych dla chmury

  • Wyjaśnienie platformy jako usługi (PaaS)
  • Wielochmurowe wyjaśnienie
  • Wyjaśnienie metodologii Agile
  • Najlepsze praktyki w zakresie zwinnego programowania
  • Devops wyjaśnił
  • Najlepsze praktyki DevOps
  • Omówienie mikrousług
  • Samouczek dotyczący mikrousług
  • Wyjaśnienie kontenerów Docker i Linux
  • Samouczek dotyczący Kubernetes
  • CI / CD (ciągła integracja i ciągłe dostarczanie) wyjaśniono
  • Najlepsze praktyki w zakresie CI / CD