Код Terraform является декларативным. Мы используем его, чтобы определить, что мы хотим получить от наших облачных провайдеров. Если перевести этот код на простой язык, то он будет выглядеть как подробный список покупок:

Дай мне частную виртуальную сеть с базой данных и кластером kubernetes. Кластер должен иметь некоторое количество узлов, и все они должны использовать определенный тип CPU. База данных должна быть расположена именно здесь, и она должна иметь возможность хранить определенное количество гигабайт…

Цель этой статьи — рассказать о том, как мы в Bulder Bank подходим к проблеме написания понятного кода Terraform.

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

Kubectl (Kubernetes Control) — это по сути основной интерфейс для взаимодействия с Kubernetes-кластером. Сторонние разработчики сделали для него много полезных плагинов, которые в той или иной ситуации могут облегчить работу инженера и сэкономить время. В этой статье рассмотрим 11 удобных плагинов для расширения функционала kubectl.

Недавно мы проводили вебинар «Обзор паттернов интеграции микросервисов». На нём энтерпрайз архитектор Пётр Щербаков рассказал, зачем IT-специалистам нужны шаблоны интеграции, и разобрал, для каких задач они подходят, а для каких нет. Для тех, кто пропустил или предпочитает читать, а не смотреть подготовили текстовый обзор интеграционных паттернов: Circuit Breaker, Sidecar, Ambassador, Anti-Corruption Layer и Async Request-Reply.

Микросервисная архитектура – одна из самых полезных архитектур в индустрии программного обеспечения. При правильном подходе она может помочь в создании лучших программных приложений. Из этой статьи вы узнаете, что такое микросервисная архитектура, какие шаблоны проектирования необходимы для ее реализации, а также почему стоит и почему не стоит использовать эту архитектуру для вашего нового программного обеспечения.

API (Application Programming Interface, программный интерфейс приложения), является жизненно важным компонентом в современном ландшафте разработки программного обеспечения, обеспечивая строительные блоки для взаимодействия приложений друг с другом. В этой статье рассмотрим пять основных типов API: REST, SOAP, WebSocket, gRPC и GraphQL, чтобы получить более четкое представление об их функциях, особенностях и идеальных сценариях использования.

Как бы хороша не была System Shock 1, я так и не смог перебороть свои предубеждения и погрузиться в эту икону иммерсивных игр. И если людям, заставшим эти игры в момент их выхода, еще как‑то можно на ностальгической волне побороть своего «графодрочера», то как быть людям, которые не имеют такого преимущества? Как современному геймеру заставить себя сесть за условную Arcanum, даже понимая, насколько она потрясающая?

В 1997 году в свет вышла Fallout – игра, ставшая эталоном жанра. Она покорила умы и сердца миллионов геймеров по всему миру, которые не спали ночами, говоря себе «Ну еще один квест и точно на боковую!». Без крупной пиар кампании и поддержки от издателя (он не верил в успех проекта) продажи были скромны. Но это не помешало выпустить продолжение, в котором разработчики взяли всё лучшее от прародителя, доработали, расширили и сдобрили щепоткой юмора (в первой части его было существенно меньше). Обе игры со временем обрели культовый статус и стали примером того, как надо делать глубокие, интересные проекты с проработанной вселенной, увлекательным действом и миром, в котором почти каждый поступок имеет последствия.

Сегодня я хотел бы рассказать вам про Fallout 2. Игра поразила меня своей свободой и стала одной из самых любимых на всю оставшуюся жизнь. Она является мерилом, по которому я сравниваю все последующие проекты в индустрии. Именно Fallout 2 показал мне, какими глубокими, вдумчивыми и многогранными бывают игры, даря право выбора и ответственность за последующие события. А делает это чувство сильнее вера в по-настоящему живой мир, заставляя сопереживать и ощущать себя его частью. Сегодня я хочу попробовать сделать и вас хотя бы ненадолго частью этого мира.

Что ж, прежде чем перейти к обзору, я просто не могу не процитировать ставшую уже культовой фразу, сказанную устами Рона Перлмана: «War. War never changes...»

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

Чтобы понять, насколько революционным был их подход, давайте просто вспомним, что Heroku создала в 2007-2011 году. Я могу назвать как минимум 3 вещи - контейнеры, serverless и доставку кода через push в GIT. Во многом современный технологический ландшафт был вдохновлен решениями Heroku, увидевшими свет 15 лет назад.

В этой статье я хочу поговорить об истории компании и причинах утраты “былого величия” в наши дни. 

Начало истории Heroku

В 2007 году трое разработчиков Ruby — Джеймс Линденбаум, Адам Виггинс и Орион Генри — основали Heroku. Поначалу это был редактор кода в браузере. Проект вызывал “ВАУ эффект”, но не сильно вовлекал пользователей. С этим проектом основатели даже прошли Y Combinator. В ходе доработки платформы разработчики сделали, как им тогда казалось, второстепенную фичу - возможность разворачивать приложения из мастер ветки привязанного GitHub. Цель была простая - дать возможность разработчикам сразу понять, как работает их код. Почему фича казалась второстепенной? На тот момент GitHub только появился, и делать интеграцию с ним было далеко не очевидной идеей. 

Но однажды, анализируя то, как пользователи используют проект, основатели Heroku заметили, что многие клиенты используют только функцию развертывания приложений через push в GIT. И с этого момента началась новая страница развития сервиса.