Облачные вычисления *

В предыдущей статье, была рассмотрена модель данных, необходимая для хранения информации об абитуриентах. Теперь пришло время показать, как используя реляционные БД можно обрабатывать модифицирующие запросы от миллиарда абитуриентов. А что бы расставить все точки над i, предлагаемая архитектура должна обрабатывать миллион модифицирующий запросов в секунду. Используя реляционные БД, гарантировать, что все возможные комбинации обрабатываются за сутки для миллиарда абитуриентов, каждому из которых предоставляется 20 вариантов! С ростом числа абитуриентов требования по железу должны рости линейно.

Сегодня мы кратко расскажем о подходах, стеке, фреймворках и облачных решениях, на которых построена наша технологическая платформа. Передаем слово Юрию Буйлову, техническому директору «СберАвто».

Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".

Как какой из двух категорий относится эта статья — решать вам.

В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.

Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.

Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).

Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.

Kubernetes, как система оркестрации, позволяет автоматизировать процесс развертывания сложных приложений и восстанавливать ожидаемое состояние кластера после сбоев. В общем случае приложение представляет собой резидентно запущенные контейнеры, которые обрабатывают запросы клиентов в цикле обработки событий, при этом при росте нагрузки могут создаваться дополнительные реплики (с использованием механизма Horizontal Pod Autoscaling). Однако, нередко бывают случаи, когда сервис используется не очень часто, но при этом в запущенном состоянии он забирает большое количество оперативной памяти или процессорного времени, и желательно обеспечить механизм запуска сервиса по запросу (или по внешнему событию). Для реализации такого варианта использования сейчас доступен инструмент knative, который был принят в марте 2022 года в качестве incubating-проекта в CNCF (Cloud Native Computing Foundation). В этой статье мы разберемся с основными понятиями knative и попробуем создать архитектуру приложения, основанную на событиях, с использованием eventing-возможностей knative.

Монолиты подобно величественным космическим линкорам из саги о «Звездных воинах» барражируют в ИТ-системах многих крупных корпораций, М.Видео-Эльдорадо не исключение. Стоит признать, что монолитные приложения — неотъемлемая часть современной ИТ-инфраструктуры, задействованная в ключевых бизнес-процессах, от бэк-офиса и поставок товаров до обслуживания клиентов, сбора и обработки различных данных.

При этом, далеко не все «акулы бизнеса» счастливы сожительствовать с упомянутыми сущностями. Модернизация этих «вавилонских башен» — источник стресса и головной боли для многих ИТ-специалистов. Некоторые из них постигают дзен и мирятся с происходящим, другие, напротив, стремятся перевести монолиты в облако c помощью реплатформинга и другими способами на букву «Р». Мы идем вторым путем. 

Попросили поделиться опытом М.Видео-Эльдорадо руководителя домена Канонические сервисы Александра Зеленюка. Под катом его рассказ.

Статья будет полезна тем, кто использовал свой дата-центр или классический хостинг, но затем столкнулся с миром публичных облачных платформ. Если не продумали все детали при планировании, то проблемы почти неизбежны. Рассккажу, как их избежать.

77+ примеров использования смарт-контрактов

В своей основе, контракты определяют условия и обязанности при обмене чем-либо между двумя и более независимыми сторонами. Исторически так сложилось, что требовался  централизованный арбитраж для подтверждения, что условия контракта соблюдаются. Благодаря появлению технологии блокчейн и смарт-контрактов, мы можем заменить централизованных арбитражеров на децентрализованную инфраструктуру, сокращая таким образом риски всех участников и повышая при этом эффективность исполнения.

Однако, из-за механизмов консенсуса в блокчейне, смарт-контракты не имеют встроенной функции или возможности связываться с внешними ресурсами, такими как поставщики данных или сервисы API, как средством верификации исхода реальных событий, происходящих за пределами блокчейна. Это создает так называемую проблему оракулов в блокчейне и является одним из самых серьезных препятствий для исполнения смарт-контрактов.

Чтобы преодолеть отсутствие такого связующего звена, гибридные смарт-контракты используют оракулы в качестве посредника для сбора информации из внешних источников данных, предоставления информации во внешние источники, и для вычислений off-chain. Оракулы обеспечивают не только двустороннюю связь между смарт-контрактами и внешним миром,  но и безопасную среду, которая защищает от любого риска единой точки отказа (single point of failure), например, от манипуляции данных или системного сбоя.

От мейнфреймов до ПК, до смартфонов, до облаков и так далее. Генеральный директор Robusta.dev Натан Йеллен говорит о Kubernetes и будущем облачных вычислений. Узнайте, почему Kubernetes — это больше, чем просто платформа для оркестрации контейнеров, это облачный стандарт следующего полувека.

Преимущества Kubernetes как оркестратора контейнеров широко известны с момента его появления в 2014 году.

Привет, Хабр! В последнее время мы получили немало запросов на знакомство с нашими продуктами в контексте импортозамещения — после известных событий их число выросло раз в 10 по сравнению с «досанкционными» временами.

Я Гришин Александр продакт менеджер VMmanager, отвечаю за его разработку и развитие. В этой статье я хочу порассуждать о VMmanager: получится ли им заменить продукты VMware, кому он подойдет, а кому нет. Насколько сложно будет переехать на отечественное решение. 

Привет, я Александр Радаев, аналитик компании proCATT. В последнее время занимался вопросами переезда клиентов в облака. И постоянно сталкивался с тем, что постоянно приходилось сопоставлять сервисы различных облачных провайдеров друг с другом.

В результате в базе знаний появилась полезная информация, частью которой я сегодня хочу поделиться. Речь пойдет об инструментах, нужных для организации среды для приложений, использующих бессерверный подход.

В России сейчас всего 3 облачных провайдера, предлагающих  облачные функции. Я расскажу, у кого что есть, и как это соотносится с сервисами общеизвестных облаков Google, Amazon и Azure.

Как я знакомился с OpenStack и прострелил себе колени, голову и сердце.

В офисе Compaq Computer в 1996 небольшая группа технических руководителей прогнозировала будущее интернет-бизнеса и называла его «облачными вычислениями». Они «предсказали», все программное обеспечение для бизнеса переместится в Интернет, а так же то, что потребительские файловые хранилища тоже переедут в облако. 

Шон О'Салливан два года делал свой стартап NetCentric, целью которого было запихнуть софт в интернет (software inside the internet). Compaq проинвестировали 5 млн долларов и выделили своего директора по маркетингу Джорджа Фавалоро, чтобы написать нормальный бизнес-план.

NetCentric столкнулся с трудностями и был продан в 2001 году. Для Compaq это стало началом 2-миллиардного бизнеса по продаже серверов интернет-провайдерам.

До "облачных вычислений" О'Салливан основал в 1986 году MapInfo (один из первых location-based services) и за 7 лет набрал более миллиона пользователей и капитализацией 200 млн долларов. А в 2011 О'Салливан пытался сделать свой Uber. Вернемся к облачным вычислениям.

Гиперконвергентные решения, доступные на современном рынке, можно условно разделить на два типа: «полноценные» и интегрированные. Их главное отличие заключается в железе, которое можно использовать при построении инфраструктуры. У настоящей гиперконвергенции (Nutanix HCI и VMware HCI) нет привязки к производителям оборудования: она запросто подружится с недорогими commodity серверами. А интегрированные решения работают только на железе конкретных вендоров.

Наша платформа vStack — это тоже полноценная гиперконвергенция. Под катом я подробно расскажу, как в ней реализованы функции вычисления (SDC), хранения (SDS) и сети (SDN) и какие возможности это дает владельцам инфраструктуры.

Термин CloudOps широко распространен в западной ИТ-среде, но почти не используется в России. На Хабре, например, он всего 1 раз вскользь упоминается в статье "Кто такие DevOps". Прочитайте это краткое описание, чтобы, встретившись с CloudOps, вы сразу понимали, о чем идет речь.

CloudOps – это практика управления программными продуктами, развернутыми в облачной (чаще мультиоблачной) среде. Сюда входит полный фарш админской работы: развертывание, настройка и оптимизация рабочих нагрузок и ИТ-сервисов, поддержание их работоспособности и обеспечение безопасности.

В облаке многие думают над стартом приложения, но не все задумываются о том, как оно завершается. В свое время мы наловили довольно много ошибок, связанных именно с остановкой подов. Например, увидели, что Kubernetes изредка убивает наше приложение до того, как оно успевает освободить ресурсы, хотя вроде бы так происходить не должно. Воспроизвести проблему с первого подхода не получилось, и мы задались вопросом, а что же там происходит под капотом?

В ходе своих изысканий мы нашли сразу несколько моментов, которые в нашем сервисе нуждаются в graceful shutdown. На паре примеров я в этой статье покажу, почему важно об этом подумать и с какой стороны к можно подойти к этой задаче.