Иногда добиться значительного эффекта можно используя совсем незамысловатые средства. Стоит лишь взглянуть на текущее положение дел под другим углом или свежим взглядом.
Я расскажу, как мы в Plesk сократили расходы на AWS-инфраструктуру одного из наших сервисов без применения уличной магии.
Возможно, конкретные наши шаги покажутся банальными, но я расскажу нашу историю, чтобы она вдохновила вас поразмышлять над своими сервисами.
Изображения играют важную роль в продаже авторских туров. Когда стартап в сфере туризма, маркетплейс авторских туров YouTravel.me начал обрабатывать 2,5 млн запросов на картинки и отдавать 50 GB в сутки, команда разработки задумалась, как хранить изображения, чтобы они не теряли качество, и при этом не тратить космические бюджеты.
Перед разработчиком или владельцем программного продукта часто возникает вопрос выбора подходящего места для размещения серверных мощностей. Как известно, софт не может быть без харда.
Сами по себе экзамены и сертификаты не несут в себе ничего отрицательного, негативные моменты будут рассмотрены ниже, начнем с позитивных и очевидных:
Привет, Хабр! Сегодня мы поговорим немного о DevOps и самоорганизации.
Мы начнем с фразы, с которой не соглашается добрая половина разработчиков в индустрии: "каждый разработчик должен быть сам себе DevOps". Кто-то считает, что этим должен заниматься отдельно выделенный человек, чтобы у разработчика оставалась забота только о качестве кода. Мы считаем, что в современных реалиях рынка и избытке инструментов/знаний разработчик должен уметь настроить и обслуживать конвейер быстрой и предсказуемой доставки артефакта в нужную ему среду.
И речь не идет о настройке каких-то больших и громоздких билд-систем, для которых обычно приносится в жертвую целая штатная единица. Нет. DevOps - не человек, а система ежедневных маленьких привычек, основанных на самоорганизации. Понятие, взрастающее снизу вверх, а не сверху или в бок.
В этой статье я представлю вам маленькую историю зарождения DevOps в на примере frontend проекта. Эта история применима как к разработчику-одиночке, так и к большой команде.
Несколько несложных примеров того, как на практике можно использовать продвинутые возможности Helm для эффективной организации безупречной continuous delivery в Kubernetes. Полезные рецепты, чтобы поддерживать конфигурации множества тестовых и production сред - удобно, безопасно, без копипасты и приятно на вид. Методы поддержания целостности сред - чтобы "зелёный" статус пайплайна всегда означал удачный деплоймент, а в случае неудачи среда бы сама восстанавливалась.
Одной из задач администрирования облачной инфраструктуры является мониторинг её компонентов: важно знать о неправильной работе облака, вовремя выявлять и исправлять ошибки конфигурации. Управлять облаком VMWare можно несколькими способами. В этой статье рассмотрим принципиальное решение двух практических задач через API. Примеров кода будет немного, но зато с изюминкой: добавим коду асинхронности, чтобы ускорить пачку из нескольких тысяч запросов!
Мой рабочий компьютер - Macbook Air 2020 (Intel), и его вполне хватает для написания кода и прочих задач. Однако, когда потребовалось смонтировать небольшой видеоролик, выяснилось что мощи моего ноута катастрофически не хватает, и я стал искать варианты.
Облачные провайдеры — это реактор, где вместо обогащённого урана используется твой кошелёк. В позапрошлом году наша компания начала активно применять облака и мы в полной мере ощутили это на себе: несколько команд разрабатывали отдельные продукты, и для большинства тестов запускались виртуальные мощности в AWS. Мы с коллегами получили сертификаты от Amazon, и это, вместе с наглядностью происходящего, Free Tier и Soft Limit’ами, создавало ложное чувство спокойствия за свой бюджет. А когда этому чувству поддаёшься, получаешь локальный Чернобыль. Под катом я расскажу, как решил эту проблему c помощью serverless-функций.
Мое приложение на 100% serverless, и я всегда умещался в уровень бесплатного использования, так что просто игнорировал затраты. Но затем мне пришел счет на 62$.
Под катом вы сможете найти подробную инструкцию для умного контроля расходов в облаке, до того как они превратятся в проблему.
Рассказываем про наш опыт импорта и адаптации конфигураций инфраструктуры, ранее развернутой вручную в AWS, в формат Terraform. Зачем? Причин может быть много: и отказоустойчивость, и упрощение горизонтального и вертикального масштабирования, и многие другие. С них и начнем эту статью.
Проблематика
Без каких-либо процессов автоматизации управления инфраструктурой вы неизбежно столкнетесь с известными ограничениями: невозможно быстро пересоздать инфраструктуру; нет истории изменений, произведенных в инфраструктуре; нет контроля используемых версий ПО…
Без API не обходится ни одно веб-приложение. Для их разработки используются разные методы. Сейчас, например, набирает популярность бессерверный подход — он экономичный, масштабируемый и относительно простой. Как ведущий провайдер бессерверных вычислений Amazon Web Services (AWS) вносит огромный вклад в бессерверную разработку. Здесь мы обсудим общие концепции реализации API с помощью AWS Lambda и других сервисов AWS.
Terraformer — консольный инструмент для генерации кода и стейта в форматах HCL и json для уже существующей инфраструктуры.
В нашем мире мобильных гаджетов, сфокусированных на приложениях, уже не принято говорить о веб-сайтах. Классические веб-сайты служат в основном для информационных целей, а для работы с целевой аудиторией бизнес нуждается в веб-приложениях. И тут неизбежно встает вопрос о том, где эти веб-приложения могут работать максимально надежно, быстро и эффективно с точки зрения затрат. Выбор возможных решений достаточно велик и мы рассмотрим достоинства и недостатки некоторых из них ниже. Но все же, забегая вперед, можно с уверенностью сказать, что облачные решения в настоящее время являются наиболее оптимальными.
Пошаговая инструкция по созданию и деплою статического сайта в облако, прикрутке к нему сертификата Let’s Encrypt, домена второго уровня и настройки API-шлюза.
В этой статье поговорим о нюансах использования Terraform от HashiCorp, в частности о том, как использовать Terraform при управлении несколькими аккаунтами Amazon Web Services (так делают все чаще — из-за размера организации или предпочтений команды DevOps). По сути, AWS сами намекают клиентам, что неплохо было бы использовать несколько аккаунтов, и недавно даже выпустили для этого несколько сервисов.
«Мы прогнозируем, что использование serverless будет стремительно расти. Мы также прогнозируем, что локальные гибридные облачные приложения со временем будут сокращаться, хотя некоторые развертывания могут сохраняться из-за нормативных ограничений и правил управления данными.
Бессерверные вычисления станут стандартной вычислительной парадигмой в эпоху облаков, в значительной степени, заменив серверные вычисления и тем самым закрыв эру клиент-сервер."
Cloud Programming Simplified: A Berkeley View on Serverless Computing, February 10, 2019
С публичного релиза AWS Lambda прошло ни много ни мало 6 с лишним лет. Реактивные функции, реагирующие на события, не только позволили по-другому смотреть на архитектуру систем и приложений, но и породили новый buzzword Serverless.
Мотивом к написанию этой статьи служит пост в блоге Netflix. Прочитав его, а так же комментарии русскоязычной аудитории, я прихожу к выводу, что направление "бессерверных вычислений" еще не обкатано вдоль и поперек (как и в англоязычной тусовке, чего греха таить), и неплохо бы проитерироваться по этой теме еще раз.
