О чем и для кого статья
В какой-то момент в нашей компании возникла необходимость уметь быстро разворачивать множество тестовых сред в Azure. Данная статья расскажет об архитектуре данного решения и о его ключевых деталях.
Я подразумеваю, что читатель статьи уже владеет основами Terraform.
Предполсылки и требования
Для начала хотелось бы рассказать о нашей компании. Мы финтех стартап, занимающийся факторингом. Мы с самого начала развивались как cloud native. Все наши вычислительные мощности и сервера находятся в Azure.
На момент событий, описываемых в статье, большинство наших ресурсов составляли Azure App Service, Azure Sql Servers и Azure Blob storages. У нас было два крупных монолита и около 10 микросервисов вокруг. Честно говоря, это было больше похоже на распределённый монолит, потому что тестировать приходилось всю экосистему, а не отдельные сервисы.
В определенный момент мы начали очень быстро расти с, примерно, 20 человек в Tech отделе до 120 за год. В это время основной нашей болью было количество тестовых сред. У нас были три среды: test, staging и prod. Команды толкались в этих средах, test был постоянно разломан, протестировать что-либо было невозможно. От этого staging тоже забивался неработающим функционалом и выпуски затягивались на недели.
Быстрым решением на тот момент было увеличение числа контуров. Мы хотели дать по тестовому контуру на команду. То есть попросту продублировать все сервисы столько раз сколько есть команд. Понятно, что это не идеальное решение, и в идеале для работы над одним микросервисом команде не нужны все остальные сервисы и инфраструктура вокруг них. Но наличие крупных сервисов, над которыми работали несколько команд, и сильная связность между микросервисами не позволяли нам так сделать. Поэтому мы стали искать решение по автоматизации создания нашей облачной инфраструктуры. Нужна была возможность быстро создавать и уничтожать тестовые контура.