Въведение в Amazon Fargate: какво е това, защо е страхотно (и не) и кога да го използвате.

Когато Amazon обяви Fargate в края на 2017 г. на AWS re: Invent (заедно с EKS), той наистина попадна под радара. Никой от блоговете или инфлуенсърите, които следвах по това време, всъщност не говореше за това, освен нещо като:

О, да, има и това ново нещо, което ще позволи на потребителите на ECS да пускат контейнери директно в облака.

Като разработчик това наистина ме взря. Да видим защо.

Бумът на производителността

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

Всички те също решиха основни проблеми. Ето моята разбивка на революциите и проблемите, които те решиха:

  • Поява на облачни услуги (IaaS)

    Разходи за инфраструктура и мащабируемост

  • Общност с отворен код, конференции, семинари, технически блогове, препълване на стека и т.н.

    Ограничен достъп до знания

  • Системи за управление на версиите, инструменти за сътрудничество, инструменти за непрекъсната интеграция

    Едновременно несъответствие на инженерните системи и ада на интеграцията

  • Контейнерна архитектура

    Трудност при изграждането на приложения в несъвместими среди

  • Безсървърни изчислителни услуги (PaaS)

    Администрация на сървъри и системи

Всяка една от тези революции има една обща черта: всички те дават повече контрол на софтуерните инженери. Те правят това, като насърчават добри практики и споделяне на код с работен поток за съвместна работа и намаляват нуждата от скъпи специализирани сървъри, системни администратори, DevOps, ИТ поддръжка и т.н.

Чудесно, но изчакайте - къде е Фаргейт във всичко това?

Проблем е вашият кораб

Вижте, когато Докер донесе контейнери на масите, той бързо се превърна в нов стандарт в разработването и беше широко приет.

Скоро след това и след успеха на Kubernetes , AWS стартира собствена (по-основна) услуга за управление на контейнери: Amazon Elastic Container Service (ECS). Той въведе концепцията за задачи.

Задача може да бъде всеки екземпляр от контейнери, работещи заедно. От уеб приложение, което изпълнява уеб сървър, няколко микро услуги, база данни и обратен прокси, до списък с партиди от скриптове на черупки, които ще се изпълняват периодично.

Като ранен възприемач на ECS, наистина ми хареса и известно време работи чудесно. Но в крайна сметка необходимостта да управлявате тези допълнителни слоеве (Задачи и контейнери) вместо само екземпляри на EC2 става все по-сложна.

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

Всъщност с ECS вашите контейнери се изпълняват в екземпляри на контейнери EC2 в клъстер , който ще конфигурирате за автоматично мащабиране. Всеки екземпляр може да хоства множество различни задачи. Всяка задача може да изпълнява множество контейнери.

Тъй като задачите ви ще бъдат разположени произволно (по подразбиране) на един и същи EC2 екземпляри с налични ресурси , вие се сблъсквате със следните проблеми:

  • Един клъстер следва едни и същи правила за автоматично мащабиране и автоматично предоставя същия вид екземпляри EC2.
  • Някои контейнери ще се нуждаят от напълно различни ресурси, но все пак трябва да работят заедно.
  • Някои контейнери не спазват непременно едни и същи правила за автоматично мащабиране.
  • Понякога няколко контейнера в една и съща задача се нуждаят от собствен балансир на товара и наличието на множество балансиращи товара за една и съща задача не е възможно.

Предпочитаното заобиколно решение при изправяне пред тези проблеми е да:

  • ръчно разполагайте някои от вашите копия с различни ресурси според нуждите
  • прикачете тези екземпляри към вашия клъстер
  • стартирайте един контейнер по задача
  • свържете вашите екземпляри EC2 ръчно заедно
  • напишете сложни ограничения за поставяне на стратегии на ECS, за да сте сигурни, че правилната задача е на правилната машина, която разполага със съответния ресурс в зависимост от това, което е направила

Това е много работа, доста е досадно и е трудно да се поддържа. И това като че ли побеждава първоначално целта за работа с контейнери.

Някой трябваше да измисли по-добра идея.

Оставете ги да плуват

Както се оказа, екипът на AWS имаше същите проблеми. Те помислиха за това през последната година и работиха по решаването на проблема по-долу:

Как бихме могли да стартираме контейнери, без да се притесняваме за сървъри и клъстери?

И за това е AWS Fargate . Той напълно абстрахира основната инфраструктура и вие виждате всеки един от вашите контейнери като една машина.

Просто трябва да посочите какъв ресурс ви е необходим за всеки контейнер и той ще ви вдигне тежкото повдигане. Вече не трябва да управлявате правилата за многопластов достъп. Можете да настроите фино разрешенията между вашите контейнери, както бихте направили между отделни екземпляри на EC2.

Все едно вашите контейнери се превръщат в кораби със собствено платно, кормило и екипаж и са в състояние да доплуват сами до местоназначението си.

Контейнери като услуга (CaaS)

Всъщност вярвам, че контейнерите като услуга (CaaS) са истинските PaaS, които разработчиците чакат от години. Той позволява на разработчиците да разполагат своите контейнери директно в облака, без да се притесняват от всичко между тях.

Разбира се, вече има много технологии, които ви позволяват да стартирате кода си безпроблемно в облака, без да се налага да се притеснявате за мащаба или администрирането на сървъра (като невероятния Heroku , Lambda или дори по свой собствен начин на приложението Google) . Но всички имат ограничения.

  • Трябва да избирате между загуба на малко гъвкавост
  • Трябва да се придържате към поддържаните езици
  • Не можете да използвате поддържаните езици, защото вашият проект се нуждае от собствена библиотека с ниско ниво, която е достъпна само за много специфични системи
  • Вашият проект използва авангардна технология, която няма да бъде достъпна за масите през следващите няколко години
  • Някои от тези платформи са много (много) скъпи, особено при мащабиране

Fargate (или CaaS) ви носи най-доброто от двата свята.

Контейнерната архитектура ви носи гъвкавостта и контрола, от които се нуждаете. Тя ви позволява да използвате всякакъв вид технология, работеща във всякакъв вид система, която искате. Аспектът на контейнера ще гарантира, че ще имате едно и също поведение на всеки хост, независимо дали става въпрос за среда за разработка, тестване, постановка или прод.

Намирам тази точка за критична за много технологични стартиращи компании. Всъщност понякога едно от конкурентните ви предимства е използването на модерна технология, в която сте участвали, или интелигентното повторно използване на друга в напълно нов и революционен контекст.

Безсървърното внедряване ви позволява да се съсредоточите върху писането на страхотен код. Без провизиране, лесно мащабиране.

Граници

CaaS срещу PaaS

Вярно е, че се отказвате от някои страхотни аспекти на истинския PaaS. Да, пак ще трябва да актуализирате изображенията на контейнера си ръчно и понякога ще трябва да пишете свои собствени изображения на Docker. Отначало това може да бъде борба, ако не знаете основите на системното администриране .

Но това също така означава, че можете да правите почти всичко, за което можете да мислите, и да имате пълна гъвкавост и свобода в системите, езиците, инструментите, библиотеките и версиите, които искате да използвате.

Разходи

Нека си признаем, облачните услуги (IaaS) са по-скъпи от наличието на собствена инфраструктура (ако можете да я увеличите и намалите при поискване). По същата причина липсата на необходимост от осигуряване, управление и мащабиране на вашите сървъри има разходи. Все още може да не е най-доброто решение за някои от най-простите ви случаи на употреба.

Да се ​​надяваме, че ще работят за намаляване на разходите. Колкото и да е добър продуктът, трудно е да се оправдае почти 4 пъти цената на еквивалентен екземпляр EC2 при поискване (например за t2.medium).

Трябва ли да превключа всичките си ECS задачи на Fargate?

Все още не. Както беше посочено по-горе, в някои случаи ще увеличите повече от три пъти разходите си. Докато те намалят разходите, може да ви е по-добре да използвате стандартни инсталации EC2.

Fargate обаче може да бъде по-полезен за вас в следните случаи на употреба:

  • Ако имате проблеми с автоматичното мащабиране на вашите ECS задачи ефективно и често в крайна сметка получавате много неизползвани CPU или памет . С Fargate плащате само за ресурсите, които сте определили в задачите си .
  • За вашите задачи, които ще се изпълняват при поискване или по график и не се нуждаят от специален екземпляр EC2. С Fargate плащате само когато задачата ви се изпълнява.
  • За вашите задачи, които имат максимално използване на паметта и / или процесора . Само защото ще ви спести време и неприятности при конфигурирането и управлението на такива случаи.

Бонус

За тези, които предпочитат Kubernetes пред ECS , Fargate скоро ще може да стартира Elastic Container Service за Kubernetes.