DUMP конференция | grep 'backend|devops'

Миналата седмица отидох на конференцията DUMP IT (https://dump-ekb.ru/) в Екатеринбург и искам да ви кажа какво се обсъждаше в секциите Backend и Devops и дали регионалните IT конференции заслужават внимание.

Николай Сверчков от Evil Martians за Serverless

Какво все пак имаше там?

Общо конференцията имаше 8 секции: Backend, Frontend, Mobile, Testing and QA, Devops, Design, Science и Management.

Най-големите зали, между другото, са в Наука и управление)) За ~ 350 души всяка. Backend и Frontend не са много по-малки. Стаята Devops беше най-малката, но активна.

Слушах докладите в секциите Devops и Backend и поговорих малко с лекторите. Бих искал да говоря по засегнатите теми и да прегледам тези секции на конференцията.

В секциите Devops и Backend говориха представители на SKB-Kontur, DataArt, Evil Martians, Екатеринбургско уеб студио Flag, Miro (RealTimeBoard). Обхванатите теми CI/CD, работа с услуги за опашки, регистриране; Теми без сървър и работа с PostgreSQL в Go бяха добре обхванати.

Имаше и доклади от Avito, Tinkoff, Yandex, Jetstyle, Megafon, Ak Bars Bank, но нямах време да присъствам физически на тях (видеозаписите и слайдовете на докладите все още не са налични, обещават да ги публикуват до 2 седмици на dump-ekb.ru).

Раздел Devops

Изненадващо беше, че секцията се проведе в най-малката зала, около 50 места. Хората дори стояха на пътеките :) Ще ви разкажа за докладите, които успях да слушам.

Еластик с тегло петабайт

Разделът започна с доклад на Владимир Лил (SKB-Kontur) за Elasticsearch в Kontur. Те имат доста голям и натоварен Elastic (~800 TB данни, ~1.3 петабайта, като се вземе предвид излишъкът). Elasticsearch за всички услуги на Kontur е единичен, състои се от 2 клъстера (от 7 и 9 сървъра) и е толкова важен, че Kontur има специален инженер Elasticsearch (всъщност самият Владимир).

Владимир сподели и своите мисли за ползите от Elasticsearch и проблемите, които носи.

предимства:

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

проблеми:

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

Имаше само положителни отзиви за Open Distro за Elasticsearch :) Същият проблем с оторизацията е решен там.

Откъде идва петабайтът?Техните възли се състоят от сървъри с 12*8 Tb SATA + 2*2 Tb SSD. Студено съхранение на SATA, SSD само за горещ кеш (горещо съхранение).
7+9 сървъра, (7 + 9) * 12 * 8 = 1536 Tb.
Част от площта е резервирана, обособена за резервиране и др.
Регистри от около 90 приложения се изпращат до Elasticsearch, включително всички отчетни услуги на Kontur, Elba и др.

Характеристики на разработката без сървър

Следва доклад на Руслан Серкин от DataArt за Serverless.

Руслан говори за това какво е разработката с безсървърния подход като цяло и какви са неговите характеристики.

Serverless е подход към разработката, при който разработчиците не докосват инфраструктурата по никакъв начин. Пример - AWS Lambda Serverless, Kubeless.io (Serverless в Kubernetes), Google Cloud Functions.

Идеалното приложение без сървър е просто функция, която изпраща заявка до доставчик без сървър чрез специален API Gateway. Идеална микроуслуга, докато AWS Lambda поддържа и голям брой съвременни езици за програмиране. Разходите за поддръжка и внедряване на инфраструктура стават нулеви в случай на облачни доставчици, поддръжката на малки приложения също ще бъде много евтина (AWS Lambda - $0.2 / 1 милион прости заявки).

Мащабируемостта на такава система е почти идеална - облачният доставчик се грижи за това сам, Kubeless мащабира автоматично в рамките на Kubernetes клъстера.

Има недостатъци:

• разработването на големи приложения става все по-трудно
• има трудности с профилиране на приложения (достъпни са ви само регистрационни файлове, но не и профилиране в обичайния смисъл на думата)
• без версии

Честно казано, чух за Serverless преди няколко години, но през всичките тези години не ми беше ясно как да го използвам правилно. След доклада на Руслан се появи разбиране, а след доклада на Николай Сверчков (Злите марсианци) от Backend раздела, то се консолидира. Не напразно отидох на конференцията :)

CI е за бедните или си струва да напишете свой собствен CI за уеб студио?

Михаил Радионов, ръководител на уеб студиото Flag от Екатеринбург, говори за самостоятелно написан CI/CD.

Неговото студио е преминало от „ръчен CI/CD“ (влезте в сървъра чрез SSH, направете git pull, повторете 100 пъти на ден) към Дженкинс и към самонаписан инструмент, който ви позволява да наблюдавате код и да изпълнявате издания, наречени Pullkins .

Защо Дженкинс не работи? Не предоставяше достатъчно гъвкавост по подразбиране и беше твърде трудно за персонализиране.

„Флаг“ се развива в Laravel (PHP framework). При разработването на CI/CD сървър Михаил и колегите му използваха вградените механизми на Laravel, наречени Telescope и Envoy. Резултатът е сървър в PHP (моля, имайте предвид), който обработва входящи заявки за уеб кукичка, може да изгради интерфейса и бекенда, да разположи на различни сървъри и да докладва на Slack.

След това, за да могат да изпълняват синьо/зелено внедряване и да имат еднакви настройки в dev-stage-prod среди, те преминаха към Docker. Предимствата останаха същите, добавени бяха възможностите за хомогенизиране на средата и безпроблемно внедряване и необходимостта да се научи Docker да работи правилно с него.

Проектът е в Github

Как намалихме броя на връщанията към версията на сървъра с 99%

Последният доклад в секцията Devops беше от Виктор Еремченко, водещ инженер devops в Miro.com (бивш RealTimeBoard).

RealTimeBoard, водещият продукт на екипа на Miro, е базиран на монолитно Java приложение. Събирането, тестването и внедряването му без престой е трудна задача. В този случай е важно да разположите такава версия на кода, така че да не се налага да се връща назад (това е тежък монолит).

По пътя към изграждането на система, която ви позволява да направите това, Миро премина през път, включващ работа върху архитектурата, използваните инструменти (Atlassian Bamboo, Ansible и т.н.) и работа върху структурата на екипите (те вече имат специален екип на Devops + много отделни Scrum екипи от разработчици с различни профили).

Пътят се оказа труден и трънлив, а Виктор сподели натрупаната болка и оптимизъм, които не свършиха дотук.

Спечели книга за задаване на въпроси

Бекенд раздел

Успях да присъствам на 2 доклада - от Николай Сверчков (Evil Martians), също за Serverless, и от Григорий Кошелев (компания Kontur) за телеметрията.

Без сървър за обикновените смъртни

Ако Руслан Сиркин говори за това какво е Serverless, Николай показа прости приложения, използващи Serverless, и говори за подробностите, които влияят на цената и скоростта на приложенията в AWS Lambda.

Интересна подробност: минималният платен елемент е 128 Mb памет и 100 ms CPU, струва $0,000000208. Освен това 1 милион такива заявки на месец са безплатни.

Някои от функциите на Николай често надхвърляха ограничението от 100 ms (основното приложение беше написано на Ruby), така че пренаписването им в Go осигури отлични спестявания.

Vostok Hercules — направете телеметрията страхотна отново!

Последният доклад на секцията Backend от Григорий Кошелев (компания Kontur) за телеметрията. Телеметрията означава регистрационни файлове, показатели, следи на приложения.

За тази цел Contour използва самостоятелно написани инструменти, публикувани в Github. Инструмент от доклада - Херкулес, github.com/vostok/hercules, се използва за доставяне на телеметрични данни.

Докладът на Владимир Лила в секцията Devops обсъди съхраняването и обработката на регистрационни файлове в Elasticsearch, но все още има задача за доставяне на регистрационни файлове от много хиляди устройства и приложения и инструменти като Vostok Hercules ги решават.

Веригата следва път, известен на мнозина - от RabbitMQ до Apache Kafka, но не всичко е толкова просто)) Те трябваше да добавят Zookeeper, Cassandra и Graphite към веригата. Няма да разкривам изцяло информацията за този доклад (не моя профил), ако се интересувате, можете да изчакате слайдовете и видеоклиповете на уебсайта на конференцията.

Как се сравнява с други конференции?

Не мога да го сравня с конференциите в Москва и Санкт Петербург, мога да го сравня с други събития в Урал и с 404fest в Самара.

DAMP се провежда в 8 секции, това е рекорд за конференциите в Урал. Много големи секции за наука и управление, това също е необичайно. Публиката в Екатеринбург е доста структурирана - в града има големи отдели за развитие на Yandex, Kontur, Tinkoff и това оставя отпечатък върху репортажите.

Друг интересен момент е, че много компании имат 3-4 лектори на конференцията наведнъж (такъв беше случаят с Kontur, Evil Martians, Tinkoff). Много от тях бяха спонсори, но репортажите са съвсем наравно с други, това не са рекламни репортажи.

Да отида или да не отида? Ако живеете в Урал или наблизо, имате възможност и се интересувате от темите - да, разбира се. Ако мислите за дълго пътуване, бих разгледал темите на репортажите и видео репортажите от минали години www.youtube.com/user/videoitpeople/videos и взе решение.
Друго предимство на конференциите в регионите, като правило, е, че е лесно да се общува с лектора след докладите, просто има по-малко кандидати за такава комуникация.

Благодаря на Dump и Екатеринбург! )

Източник: www.habr.com