Размышления о том, откуда берется желание сдать сертификацию AWS Solutions Architect Associate.

Мотив первый: «Топоры»

Один из самых полезных для любого профессионала принципов «Знай свои инструменты» (или в одной из вариаций «точи пилу»).

Мы в облаках уже давно, но до поры до времени это были просто монолитные приложения с базами, развернутые на инстансах EC2 — дёшево и сердито.

Но постепенно нам стало тесно в рамках монолита. Взяли курс на распил в хорошем смысле – на модуляризацию, а затем и модные нынче микросервисы. И очень быстро на этой почве «расцветают сто цветов».

Да что там далеко ходить – проект логирования активности, который я сейчас веду, включает в себя:

• Клиентов в виде разнообразных приложений нашего продукта – от глухих уголков дремучего легаси до ультрамодных микросервисов на .Net Core.
• Очереди Amazon SQS, в которые складываются логи о том, что происходит с клиентами.
• Микросервис на .Net Core, который достает сообщения из очереди и отправляет их в Amazon Kinesis Data Streams (KDS). Имеет также Web API интерфейс и swagger UI как дублирующий канал и для ручного тестирования. Оборачивается в докеровский linux-контейнер и хостится под управлением Amazon ECS. Предусмотрен autoscaling на случай большого потока логов.
• Из KDS данные пожарными шлангами направляются в Amazon Redshift с промежуточными складами в Amazon S3.
• Операционные логи для девелоперов (дебаг-информация, сообщения об ошибках и т.п.) форматируются в приятный глазу JSON и отправляются в Amazon CloudWatch Logs

Работая с таким зоопарком сервисов AWS, хочется знать, что есть в арсенале и как это что-то лучше использовать.
Читать дальше ->

https://habr.com/ru/post/453390/?utm_source=habrahabr&utm_medium=rss&utm_campaign=453390