Облачни функции срещу двигател Kubernetes

Актуализирано август 2019 г.

Изчислителната линия на Google предлага много голям избор. Две от най-добрите технологии на GCP са Kubernetes Engine и Cloud Functions. И двете са мощни и като разработчик е лесно по подразбиране на Cloud Functions, защото това отнема много административна работа от ръцете ми. Тази административна работа, макар и декларативни yaml файлове, е важен аспект за конфигурирането на Kubernetes Engine.

Първоначалното предположение за тази статия беше от програмист, който просто ме попита: „кога бихте избрали Kubernetes над облачните функции?“. Това е въпрос, който сам обмислях много, откакто работя с двете, и затова смятам, че най-добрият начин да се справим с това е по подразбиране към Cloud Functions и да обясня случаите, в които Kubernetes Engine би бил по-добър избор. Макар да не описвам всяка причина, ето топ няколко, които участват в избора на Kubernetes.

3 езика няма да го режат

Когато използвате Cloud Functions в момента, имате само три среди за развитие, от които да избирате, а това са Node.js, Python и Go. Това е невероятна технология и е мощна.

Kubernetes Engine ви предлага свобода, защото шушулките, които създавате, са изолирани среди, които могат да работят на всеки език и време на изпълнение. Може да сте .NET магазин и трябва да използвате C #. Забавлявах се с идеята да използвам библиотеките на Core Foundation от Apple в услуга. Тази услуга ще трябва да бъде написана в Swift. Това са само някои от случаите, които могат да включват използването на различен език и набор от рамки. В бъдеще облачните функции ще поддържат повече от тези технологии, но това ще отнеме доста години, преди да е в производство.

скорост

Скорост и имам предвид в момента, а не в 200 мс. Това е фундаментална разлика. Има случаи, когато просто искате да получите данни и да ги избутате някъде. Ако някоя облачна функция не се използва за известно време, всички случаи на тази функция се изключват. Това е добро нещо, не плащате нищо, ако не го използвате. Възможно е обаче да има случаи, в които просто не искате да чакате това студено начално време. Ако това не е опция, тогава Kubernetes ще има гръб, вече сте клъстер и можете да имате няколко шушулки, работещи за тази конкретна услуга, готови да пристъпите към действие, когато възникне нужда.

Тежка обработка и големи натоварвания

Функциите са чудесни за свързване на различни услуги заедно. Те обаче не са предназначени за тежки или продължителни задачи. Те са кратки на процесора и паметта в сравнение с Compute, Kubernetes и App Engine. Те имат много по-бързо време за изчакване на 5 минути, което означава, че работата трябва да се свърши бързо и трябва да се върнете от функцията бързо.

Плюс това, той не се справя добре с тежки товари. Ако ще направите много обработка на изображения или анализ на големи данни на облачна функция, ще изпаднете в проблеми. С Kubernetes Engine имате възможност да мащабирате шушулки въз основа на различни параметри като висок процесор, памет и т.н. С облачните функции нямате възможност да избирате процесор, а разпределението на паметта е доста ниско в сравнение с другите изчислителни услуги.

Призоваване лудост

Колко пъти извиквате функцията? Дали е сто или сто хиляди пъти на ден? По-различно е, ако функцията ви в облак разчита на задействане на базата данни на firebase, в този момент си струва да се съгласите за облачната функция. Ако обаче се опитвате да създадете услуга, която ще валидира имейли или просто поглъщате огромно количество данни, тогава си струва да разгледате Kubernetes. Първо, винаги можете да използвате няколко шушулки, така че да намалите закъсненията в услугата. Второ, при облачните функции част от цената е колко пъти се извиква функция. С Kubernetes можете да увеличавате мащаба до повече случаи по време на пиковите размери, отколкото мащаба обратно надолу. Няма значение дали вашата услуга е извикана десет хиляди пъти, в този момент плащате за броя възли и шушулки, които стартирате, което ще намали общите ви разходи.

Микросервизна комуникация

И накрая, ние имаме комуникация между обслужване. Облачните функции имат някои наистина мощни задействания както за Firebase, така и за GCP. Например, можете да настроите задействане на Cloud Pub / Sub или да задействате друга функция, като качвате файлове в Cloud Storage. В допълнение, имаме HTTP задействания, които са полезни за създаване на уеб куки.

Какво обаче, ако имате няколко услуги, които не е необходимо да се задействат, а просто искате те да си говорят помежду си? В момента разговорът и комуникацията между услугите не е наистина ефективен подход при използване на облачни функции. Помислете само за процеса на внедряване. С облачните функции това е тромаво, когато започнете да актуализирате куп услуги в Google Cloud. Междувременно с Kubernetes просто качвате конфигурациите си и Kubernetes гарантира, че средата работи правилно за вас. Да, има много повече работа за предварително създаване на файлове на yaml, но тогава е много просто да поддържате тази инфраструктура и да работи.

В крайна сметка това зависи от това какво изграждате и какви са вашите нужди, но ако жонглирате идеята да извикате множество задействащи HTTP функции въз основа на едно обаждане в облачните си функции, тогава трябва да се отдръпнете и да се запитате дали Kubernetes е по-добър вариант за 90% взаимодействие, което се случва.

Този списък не е изчерпателен и определено е отворен за тълкуване. Отново, това се основава на вашите нужди като компания и организация. Kubernetes все още нараства с бързи темпове и не всеки има разработчик / екип под ръка, който може да управлява проект на Kubernetes Engine за тях. От друга страна, може би имате много .NET Core услуги, които искате да разгърнете и облачните функции просто няма да го прекъснат, защото трябва да използвате Node.js, Python или Go. Винаги си струва да направите крачка назад и да помислите за различните технологии в играта и как можем да ги използваме, за да бъдат възможно най-продуктивни.

Джеймс Уилсън е програмист, изграждащ разпределени системи, използващи Go и Google Cloud. Той също е автор на Pluralsight и можете да разгледате курсовете му тук.