Эффективность, которую даёт использование облачных сервисов — один из главных трендов для преобразования многих IT-компаний на сегодняшний день. Автоматизация всех процессов по пути от кода на GIT до развёртывания на Development и/или Production, а также последующий мониторинг, реакция на инциденты и т.д. (что также может и должно быть автоматизировано) — всё это, если не отменяет, то существенно меняет многие общепризнанные ITIL-практики. Взгляд на DevOps-процессы с точки зрения Amazon AWS: как они могут быть реализованы на его сервисах в рамках концепции IaaC (Infrastructure as a Code) — всё это будут даны далее в цикле статей, посвящённых Code-сервисам Amazon AWS: CodeCommit, CodeBuild, CodeDeploy, CodePipeline, CodeStar.
Эта статья первая, обзорная.
Цель данной статьи есть не ликбез по DevOps и не банальное дублирование и так имеющихся у первоисточника материалов. Целью есть представление реализации DevOps на сервисах Amazon AWS в её общем виде, из которой каждый волен выбрать нужный вариант. Целевыми читателями являются знакомые как минимум о существовании Amazon AWS, планирующие задействовать его возможности в своей работе, перенести туда свои процессы частично или полностью. Предоставляемые сервисы Amazon AWS плодятся с большой скоростью, их число уже превысило круглую отметку в 100 штук, потому даже имеющим хороший опыт с AWS может быть полезным узнать — что же появилось нового, такого, которое, может быть, они просто пропустили, а это можно успешно задействовать в их работе.
![image](https://habrastorage.org/getpro/habr/post_images/6bc/e8f/911/6bce8f911f432bfb2096afd8639f5489.png)
Немного общих, но для кого-то важных слов, особенно для тех, кто не имеет достаточного опыта работы с Amazon AWS. Изображённые на логотипе кубики логически правильно передают основную идею: Amazon AWS — это конструктор, который даёт набор сервисов и из которого каждый может собрать себе нужное. Однако как раз этот момент «кубико-центричности» может некоторых отталкивать в случае, если нужный кубик (сервис) не удовлетворяет его запросы. В таком случае нужно помнить, что одну и ту же задачу можно решить с помощью разных сервисов, многие сервисы могут во многом дублируют друг друга, а потому не подошедший к вашим запросам сервис Amazon AWS никак не отменяет его использование, а всего лишь даёт повод найти подходящий. Ведь сервисы Amazon AWS появились как результат эксплуатации в первую очередь для собственных нужд. В Amazon AWS работают тысячи небольших команд (они их называют two pizza team), каждая из которых вольна выбирать свой собственный способ работы (язык, ОС, структура, протоколы и т.п.), а значит и сервисы, имеющиеся на Amazon AWS изначально должны поддерживать всё многообразие такого зоопарка их эксплуатирующих уже просто внутри самой компании Amazon AWS.
Особенно это важно для Code-сервисов Amazon AWS, которые как раз предназначены не для того, чтобы указывать вам, что нужно использовать, а для того, чтобы дать вам, с одной стороны, возможность интегрироваться с уже привычными, имеющимися и отлаженными вашими процессами и инструментами, с другой, предложить свою собственную реализацию, которая обычно наиболее эффективна в рамках задействования функционала Amazon AWS.
Даже хорошо понимая каждый кубик в отдельности, далеко не всегда понятно, какой дом из них можно построить. Потому попробуем собрать эти сервисы в одной картинке, чтобы получить общее представление, что можно собрать из такого конструктора. Если выделить Code-сервисы и соотнести их с привычными процессами, то получится примерно такая конструкция:
![image](https://habrastorage.org/getpro/habr/post_images/1b2/320/e3b/1b2320e3bbb62c79bd9183247907468d.png)
Кратко пройдёмся по каждому из Code-сервисов (подробно далее каждому из них будет посвящена отдельная статья):
Наиболее очевидный и понятный сервис — амазоновская реализация GIT, полностью его повторяющая. Отличий от GIT в плане работы и взаимодействия (команды) нет, нужен по сути для непосредственной интеграции в структуру сервисов AWS, в том числе для организации доступа через сервисы IAM. Сам код хранится на S3.
Сборочный сервер — для проектов, требующих сборки перед развёртыванием, например, Java. По умолчанию запускает контейнер на базе Ubuntu, но можно указать и свой собственный.
Поддерживает интеграцию с Jenkins через плагин.
Кроме сборки, аналогично могут быть проведены тесты. И хотя это не основное его назначение, он может быть выбран в качестве такового.
Потому AWS CodeBuild также присутствует и на этапе «Test».
Сервис для развёртывания кода, который с помощью предустановленного агента и гибких настроек работает в любом окружении. Особенным отличием является то, что агент работает не только с Amazon AWS виртуалками, но и «внешними», что позволяет централизованно разворачивать самое разношерстное ПО, в т.ч. и локально.
Как было видно из главной диаграммы, взаимодействует с предыдущими тремя сервисами, запуская их в нужной последовательности и, собственно, обеспечивая автоматизацию DevOps-процессов.
Позволяет организовывать ветвления процессов, запускать сторонние сервисы (например, для тестирования), делать параллельные ветки, запрашивать подтверждение (Approval Actions) перед запуском следующего этапа. В общем — это центральный инструмент для организации DevOps на Amazon AWS.
Сервис, по сути дублирующий CodePipeline, но заточенный под простоту запуска и настройки, что решается с помощью широкого набора готовых шаблонов (под связку приложение-язык) и действительно удобного Dashboard с плагинами, имеющими некоторую интеграцию с сервисом мониторинга (CloudWatch) и плагином для интеграции с Jira.
Сервисы Amazon AWS, реализующие концепцию «Инфраструктура как код», это:
Весьма часто возникают вопросы по поводу того, какой из них выбрать и почему три сервиса предназначены для одного и того же (развёртывание инфраструктуры и приложений), располагаясь в главной диаграмме на стадии Deploy. Если кратко, то их использование можно представить как:
![image](https://habrastorage.org/getpro/habr/post_images/4a2/4e5/917/4a24e591750ea6768b6d35c5ad13aeb6.png)
То есть для того, чтобы сделать что-то быстро (и это не значит, что плохо), это какой-то стандартный функционал (например, простой сайт) — удобно использовать Elastic Beanstalk. Если это сложный проект с многочисленными вложенными элементами и серьёзными требованиям по сетевым настройкам — без использования CloudFormation не обойтись. Как нечто среднее — представляется использование OpsWorks, базирующегося на Chef.
Однако в реальности (и как раз на сложных проектах обычно используется) комбинация из всех трёх: CloudFormation поднимает основную инфраструктуру (VPC, подсети, репозитории, создаёт нужные роли в IAM для доступа и т.д.), после запускает OpsWorks-стек, который уже может гибко настроить внутреннюю составляющую запущенных виртуалок. А для удобности процесса разработки CloudFormation может поднять и стек для Elastic Beanstalk компонентов, чтобы разработчики с помощью .ebextensions могли сами менять некоторые параметры работающего приложения (количество и тип используемых виртуалок, использование Load Balancer и т.д.) просто изменяя простой файл конфигурации в папке с кодом, когда применение изменений (в т.ч. в инфраструктуру приложения) происходит автоматически после коммита.
![image](https://habrastorage.org/getpro/habr/post_images/5d4/cd8/ec3/5d4cd8ec3ef84af9f6235d02a0d40d24.png)
Отдельно стоит сказать про сервис Lambda, реализующего концепцию ServerLess-архитектуры, который, с одной стороны, аналогично Elastic Beanstalk, можно вписать в DevOps-процесс с помощью использования AWS Code-сервисов. А с другой стороны AWS Lambda — отличное (читай — обязательное) средство автоматизации всего и вся на Amazon AWS. Все процессы, подразумевающие взаимодействие друг с другом — могут быть связаны с помощью Lambda. Она может обработать и отреагировать на результаты мониторинга CloudWatch, например, перезагрузив сервис (виртуалку, кластер) и послав на почту админу сообщение о проблемах. Она же используется в связи DevOps-процессов, например, для запуска своих способов сборки и тестов с последующей передачей на Deploy в общем порядке. И вообще, с помощью AWS Lambda может быть реализована самая сложная логика, которая пока недоступна с помощью текущего набора сервисов Amazon AWS.
Кроме перечисленных сервисов, в DevOps-процессах могут быть задействованы и другие сервисы. Потому, если попытаться представить общую схему используемых сервисов, то картина может получиться весьма запутанная (ниже просто лишь условный пример).
![image](https://habrastorage.org/getpro/habr/post_images/84f/d4d/d8c/84fd4dd8ce37bc283649f3c5c7212a1f.png)
Не всё может быть передано визуально, т.к. такие глобальные сущности как сервис управления доступом AWS IAM проникает и присутствует практически во всех составляющих. На базе вычислительных мощностей сервиса EC2 работают все другие сервисы. Сервис хранения данных S3 используется для передачи данных между очень многими другими сервисами. А такие высокоуровневые сервисы как AWS Service Catalog могут давать взаимодействие и, в том числе, между разными аккаунтами Amazon AWS.
Далее, по мере более подробного рассмотрения отдельных сервисов, запутанная и непонятная схема будет вырисовываться в понятный набор инструментов, где каждый сможет подобрать себе нужное.
Итого по общей схеме сервисов Amazon AWS, которые могут быть задействованы в DevOps-процессах. Самая популярная связка это что-то типа: CodePipeline/CodeCommit + ElasticBenstalk/OpsWorks в качестве Deploy. А чтобы «быстро просто глянуть» — хорошо подойдёт CodeStar. Правда AWS CodeStar платный, однако фактор стоимости целенаправленно здесь не учитывался, чтобы сначала дать общее представление о выборе, ведь каждую составляющую можно брать по желанию, в том числе задействуя нужное через плагины популярных CI/CD проектов типа Jenkins сотоварищи.
Ссылки:
Эта статья первая, обзорная.
Цель данной статьи есть не ликбез по DevOps и не банальное дублирование и так имеющихся у первоисточника материалов. Целью есть представление реализации DevOps на сервисах Amazon AWS в её общем виде, из которой каждый волен выбрать нужный вариант. Целевыми читателями являются знакомые как минимум о существовании Amazon AWS, планирующие задействовать его возможности в своей работе, перенести туда свои процессы частично или полностью. Предоставляемые сервисы Amazon AWS плодятся с большой скоростью, их число уже превысило круглую отметку в 100 штук, потому даже имеющим хороший опыт с AWS может быть полезным узнать — что же появилось нового, такого, которое, может быть, они просто пропустили, а это можно успешно задействовать в их работе.
Не (только) кубики
![image](https://habrastorage.org/getpro/habr/post_images/6bc/e8f/911/6bce8f911f432bfb2096afd8639f5489.png)
Немного общих, но для кого-то важных слов, особенно для тех, кто не имеет достаточного опыта работы с Amazon AWS. Изображённые на логотипе кубики логически правильно передают основную идею: Amazon AWS — это конструктор, который даёт набор сервисов и из которого каждый может собрать себе нужное. Однако как раз этот момент «кубико-центричности» может некоторых отталкивать в случае, если нужный кубик (сервис) не удовлетворяет его запросы. В таком случае нужно помнить, что одну и ту же задачу можно решить с помощью разных сервисов, многие сервисы могут во многом дублируют друг друга, а потому не подошедший к вашим запросам сервис Amazon AWS никак не отменяет его использование, а всего лишь даёт повод найти подходящий. Ведь сервисы Amazon AWS появились как результат эксплуатации в первую очередь для собственных нужд. В Amazon AWS работают тысячи небольших команд (они их называют two pizza team), каждая из которых вольна выбирать свой собственный способ работы (язык, ОС, структура, протоколы и т.п.), а значит и сервисы, имеющиеся на Amazon AWS изначально должны поддерживать всё многообразие такого зоопарка их эксплуатирующих уже просто внутри самой компании Amazon AWS.
Особенно это важно для Code-сервисов Amazon AWS, которые как раз предназначены не для того, чтобы указывать вам, что нужно использовать, а для того, чтобы дать вам, с одной стороны, возможность интегрироваться с уже привычными, имеющимися и отлаженными вашими процессами и инструментами, с другой, предложить свою собственную реализацию, которая обычно наиболее эффективна в рамках задействования функционала Amazon AWS.
DevOps конструктор Amazon AWS
Даже хорошо понимая каждый кубик в отдельности, далеко не всегда понятно, какой дом из них можно построить. Потому попробуем собрать эти сервисы в одной картинке, чтобы получить общее представление, что можно собрать из такого конструктора. Если выделить Code-сервисы и соотнести их с привычными процессами, то получится примерно такая конструкция:
![image](https://habrastorage.org/getpro/habr/post_images/1b2/320/e3b/1b2320e3bbb62c79bd9183247907468d.png)
Кратко пройдёмся по каждому из Code-сервисов (подробно далее каждому из них будет посвящена отдельная статья):
AWS CodeCommit
как выглядит![image](https://habrastorage.org/getpro/habr/post_images/32e/2b9/43c/32e2b943cbb9f830a5a89c93050efc0d.png)
![image](https://habrastorage.org/getpro/habr/post_images/32e/2b9/43c/32e2b943cbb9f830a5a89c93050efc0d.png)
Наиболее очевидный и понятный сервис — амазоновская реализация GIT, полностью его повторяющая. Отличий от GIT в плане работы и взаимодействия (команды) нет, нужен по сути для непосредственной интеграции в структуру сервисов AWS, в том числе для организации доступа через сервисы IAM. Сам код хранится на S3.
AWS CodeBuild
как выглядит![image](https://habrastorage.org/getpro/habr/post_images/c49/355/c8e/c49355c8e917c928951b2b9bba6e0afa.png)
![image](https://habrastorage.org/getpro/habr/post_images/c49/355/c8e/c49355c8e917c928951b2b9bba6e0afa.png)
Сборочный сервер — для проектов, требующих сборки перед развёртыванием, например, Java. По умолчанию запускает контейнер на базе Ubuntu, но можно указать и свой собственный.
Specify a Docker image![image](https://habrastorage.org/getpro/habr/post_images/d89/c01/6a8/d89c016a8a30e2f2fb9b27a2616488ff.png)
![image](https://habrastorage.org/getpro/habr/post_images/d89/c01/6a8/d89c016a8a30e2f2fb9b27a2616488ff.png)
Поддерживает интеграцию с Jenkins через плагин.
Кроме сборки, аналогично могут быть проведены тесты. И хотя это не основное его назначение, он может быть выбран в качестве такового.
AWS CodeBuild as Test provider![image](https://habrastorage.org/getpro/habr/post_images/b03/c20/515/b03c20515285498bb807379aea4bec8b.png)
![image](https://habrastorage.org/getpro/habr/post_images/b03/c20/515/b03c20515285498bb807379aea4bec8b.png)
Потому AWS CodeBuild также присутствует и на этапе «Test».
AWS CodeDeploy
Сервис для развёртывания кода, который с помощью предустановленного агента и гибких настроек работает в любом окружении. Особенным отличием является то, что агент работает не только с Amazon AWS виртуалками, но и «внешними», что позволяет централизованно разворачивать самое разношерстное ПО, в т.ч. и локально.
AWS CodePipeline
как выглядит![image](https://habrastorage.org/getpro/habr/post_images/ed3/8bf/720/ed38bf72009815d4c301719e9a832390.png)
![image](https://habrastorage.org/getpro/habr/post_images/ed3/8bf/720/ed38bf72009815d4c301719e9a832390.png)
Как было видно из главной диаграммы, взаимодействует с предыдущими тремя сервисами, запуская их в нужной последовательности и, собственно, обеспечивая автоматизацию DevOps-процессов.
Позволяет организовывать ветвления процессов, запускать сторонние сервисы (например, для тестирования), делать параллельные ветки, запрашивать подтверждение (Approval Actions) перед запуском следующего этапа. В общем — это центральный инструмент для организации DevOps на Amazon AWS.
AWS CodeStar
как выглядит![image](https://habrastorage.org/getpro/habr/post_images/d4c/e91/b48/d4ce91b48ddf43024e1469575c989057.png)
![image](https://habrastorage.org/getpro/habr/post_images/d4c/e91/b48/d4ce91b48ddf43024e1469575c989057.png)
Сервис, по сути дублирующий CodePipeline, но заточенный под простоту запуска и настройки, что решается с помощью широкого набора готовых шаблонов (под связку приложение-язык) и действительно удобного Dashboard с плагинами, имеющими некоторую интеграцию с сервисом мониторинга (CloudWatch) и плагином для интеграции с Jira.
Шаблоны AWS CodeStar![image](https://habrastorage.org/getpro/habr/post_images/7d4/f22/1a2/7d4f221a24016efd7c6d95048bbc95ec.png)
![image](https://habrastorage.org/getpro/habr/post_images/7d4/f22/1a2/7d4f221a24016efd7c6d95048bbc95ec.png)
IaaC-сервисы Amazon AWS
Сервисы Amazon AWS, реализующие концепцию «Инфраструктура как код», это:
- Elastic Beanstalk
- OpsWorks
- CloudFormation
Весьма часто возникают вопросы по поводу того, какой из них выбрать и почему три сервиса предназначены для одного и того же (развёртывание инфраструктуры и приложений), располагаясь в главной диаграмме на стадии Deploy. Если кратко, то их использование можно представить как:
![image](https://habrastorage.org/getpro/habr/post_images/4a2/4e5/917/4a24e591750ea6768b6d35c5ad13aeb6.png)
То есть для того, чтобы сделать что-то быстро (и это не значит, что плохо), это какой-то стандартный функционал (например, простой сайт) — удобно использовать Elastic Beanstalk. Если это сложный проект с многочисленными вложенными элементами и серьёзными требованиям по сетевым настройкам — без использования CloudFormation не обойтись. Как нечто среднее — представляется использование OpsWorks, базирующегося на Chef.
Однако в реальности (и как раз на сложных проектах обычно используется) комбинация из всех трёх: CloudFormation поднимает основную инфраструктуру (VPC, подсети, репозитории, создаёт нужные роли в IAM для доступа и т.д.), после запускает OpsWorks-стек, который уже может гибко настроить внутреннюю составляющую запущенных виртуалок. А для удобности процесса разработки CloudFormation может поднять и стек для Elastic Beanstalk компонентов, чтобы разработчики с помощью .ebextensions могли сами менять некоторые параметры работающего приложения (количество и тип используемых виртуалок, использование Load Balancer и т.д.) просто изменяя простой файл конфигурации в папке с кодом, когда применение изменений (в т.ч. в инфраструктуру приложения) происходит автоматически после коммита.
AWS Lambda
![image](https://habrastorage.org/getpro/habr/post_images/5d4/cd8/ec3/5d4cd8ec3ef84af9f6235d02a0d40d24.png)
Отдельно стоит сказать про сервис Lambda, реализующего концепцию ServerLess-архитектуры, который, с одной стороны, аналогично Elastic Beanstalk, можно вписать в DevOps-процесс с помощью использования AWS Code-сервисов. А с другой стороны AWS Lambda — отличное (читай — обязательное) средство автоматизации всего и вся на Amazon AWS. Все процессы, подразумевающие взаимодействие друг с другом — могут быть связаны с помощью Lambda. Она может обработать и отреагировать на результаты мониторинга CloudWatch, например, перезагрузив сервис (виртуалку, кластер) и послав на почту админу сообщение о проблемах. Она же используется в связи DevOps-процессов, например, для запуска своих способов сборки и тестов с последующей передачей на Deploy в общем порядке. И вообще, с помощью AWS Lambda может быть реализована самая сложная логика, которая пока недоступна с помощью текущего набора сервисов Amazon AWS.
Кроме перечисленных сервисов, в DevOps-процессах могут быть задействованы и другие сервисы. Потому, если попытаться представить общую схему используемых сервисов, то картина может получиться весьма запутанная (ниже просто лишь условный пример).
![image](https://habrastorage.org/getpro/habr/post_images/84f/d4d/d8c/84fd4dd8ce37bc283649f3c5c7212a1f.png)
Не всё может быть передано визуально, т.к. такие глобальные сущности как сервис управления доступом AWS IAM проникает и присутствует практически во всех составляющих. На базе вычислительных мощностей сервиса EC2 работают все другие сервисы. Сервис хранения данных S3 используется для передачи данных между очень многими другими сервисами. А такие высокоуровневые сервисы как AWS Service Catalog могут давать взаимодействие и, в том числе, между разными аккаунтами Amazon AWS.
Далее, по мере более подробного рассмотрения отдельных сервисов, запутанная и непонятная схема будет вырисовываться в понятный набор инструментов, где каждый сможет подобрать себе нужное.
Итого по общей схеме сервисов Amazon AWS, которые могут быть задействованы в DevOps-процессах. Самая популярная связка это что-то типа: CodePipeline/CodeCommit + ElasticBenstalk/OpsWorks в качестве Deploy. А чтобы «быстро просто глянуть» — хорошо подойдёт CodeStar. Правда AWS CodeStar платный, однако фактор стоимости целенаправленно здесь не учитывался, чтобы сначала дать общее представление о выборе, ведь каждую составляющую можно брать по желанию, в том числе задействуя нужное через плагины популярных CI/CD проектов типа Jenkins сотоварищи.
Ссылки:
- Accelerating DevOps Pipelines with AWS: Video, Presentation
Поделиться с друзьями
Fortop
Вопрос как человеку опытному в работе именно с AWS.
Какой TCO с учетом стоимости решений Амазона и вашей работы?
Насколько конкуретное решение сравнивая с остальными?
Простой пример расчет стоимости от Амазон 31869,06$ в год
Плюс часть оплаты услуг DevOps исходя из 20/30/40 часов работы в месяц
Если взять тот же OVH, то их решение обходится в 15000-19000$ (и сервера мощнее чем инстансы амазона в расчете выше).
Плюс часть оплаты услуг DevOps исходя из 40/60/80 часов работы в месяц
Время деплоя приложения и там и там равнозначно поскольку использется Docker и Docker Hub
osigida
КМК ценность Амазона не в цене виртуалки. Действительно, можно найти миллион провайдеров, кто предложит виртуалки дешевле. Ценность Амазона в широте услуг.
Замете, автор даже в скользь не прошелся по виртуалкам, а рассказывал о сервисах на целенных на поддержку разработки. И это далеко не все, Амазон предлагает еще кучу разных услуг и сервисов, в общем то, не плохо друг с другом интегрированных.
Можно считать пятиминутку восхваления Амазона законченной.
Fortop
Именно в комплексе сервисов и ценен Амазон. Тут вы абсолютно правы.
Но я откровенно не встречал проектов, которые пользуются хотя бы половиной. Поэтому вопрос сравнения открыт даже в контексте поддержки разработки
osigida
мы использовали: RDS, Elastisearch, Elasticache, ECS, EC2, VPS. Opsworks, Cloudformation, route 53, s3, cloudfront, couldwatch, aim, certificate manager, work mail
на не очень большом проекте, скорее пилот, в месяц ~7к выходило…
как то так :-)
apple_rom
Хороший ответ и вполне характерный набор используемых Amazon AWS сервисов. Можно даже сказать классический. Как раз в том числе для обладателей подобной инфраструктуры данная статья — повод задуматься, а после спланировать и ввести преобразования. Перечисленный набор для обеспечения эффективного DevOps-процесса почти всегда дополняет:
Если проект не заморожен, а развивается — удобно (и правильно) подключать различные сервисы через APIGateway. При этом цель не задействовать максимум сервисов Amazon AWS. Просто грамотное проектирование подразумевает microservises/serverless архитектуру, что как раз подразумевается и реализуется через максимальное задействование AWS-сервисов.
С другой стороны, понятно, если у вас «все процессы на своём и давно отлажены» или же «проект сделан и работает» — то внедрение таких практик (как описаны в статье — использование Code-сервисов Amazon AWS) от затратно до бессмысленно.
Равно как и справедливо было сказано про распространённое заблуждение, когда пытаются оценить «решения Амазона» с точки зрения стоимости виртуалок. Как простой довод я обычно привожу следующий факт. Например, из ваших расчётов один из значимых параметров — это стоимость аренды мощных виртуалок типа m4.4xlarge, которые идут по $0.862 за час. В то время как это «обычная» цена. Есть скидка, которая может быть получена при аренде на год или три — она может составлять десятки процентов, но подобные скидки есть у всех. Однако редко кто говорит про Spot-виртуалки, в то время, как их стоимость в разы меньше. Например, за эти же m4.4xlarge-виртуалки на данный момент можно платить в 4 раза дешевле!
Согласитесь, калькуляция при таком раскладе резко изменится.
В качестве примера могу сказать, что достаточно популярный Битрикс24 в своей работе использует как раз такие Spot-instances. Да, они имеют некоторые особенности, которые должны быть учтены (и заложены в архитектуру) и те же Битрикс24, в случае отсутствия в нужный момент Spot-виртуалок — поднимают обычные (дорогие). Но при первой возможности они их убивают и снова пользуются дешёвыми. Что при грамотной реализации кластерной системы работы им даёт и надёжность, и весьма существенную экономию.
Fortop
Сколько у вас было DevOps на проект?
osigida
от 0 до 2х, начинали сами разработчики, потом наняли 2х опс-ов в помощь
Fortop
Понятно.
Если информация не секретная, то итоговый бюджет за срок жизни проекта (год? два?) получился какой?
На железо + поддержка.
osigida
уже 4ре года, сейчас только поддержка,
в самые горячие периоды стоимость сервисов была до 11к в месяц.
Последние пол года держится около $5500, поддержки практически никакой (я один смотрю за зоопарком, и я не опс)
Fortop
Спасибо за информацию
igordata
семь тысяч долларов?
osigida
ага…