Размышления о том, откуда берется желание сдать сертификацию 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
![О топорах и капусте - 1 О топорах и капусте - 1](https://www.pvsm.ru/images/2019/05/24/o-toporah-i-kapuste.png)
Работая с таким зоопарком сервисов AWS хочется знать что есть в арсенале и как это что-то лучше использовать.
Читать полностью »