#машины_aws

Кто не смог присутствовать лично, могут посмотреть мое выступление в записи.

#машины_aws

Пропустили мой доклад на ZED? Ничего страшного!

Для страждущих узнать побольше про тяжелую жизнь облачной адаптации в enterprise-сектора, есть запись.

#машины_aws

Дождались!

Глубокое погружение в DynamoDB, глава 2: Таблицы, операции, вторичные индексы, пропускная способность.

Мой самый большой лонгрид: >4000 слов, приблизительное время чтения - 15 минут.

#машины_aws

Ваше выходное чтиво - третья глава по DynamoDB.

В этой части: что такое консистентность, почему ее так тяжело достичь и как воспроизвести в DynamoDB, как отлавливать изменения данных, а также особенности кеширования с использованием DAX и построение гео-распределенных таблиц.

#машины_aws

Мой “контент-план” по блогам на Январь 2021 официально выполнен!

Вниманию моих читателей - финальная (на данный момент) глава по DynamoDB.
Моделирование данных, лучшие практики, Single-Table Design… И разумеется, полезные ссылки для страждущих!

#машины_aws

На той неделе AWS выкатил интересное, но спорное по полезности обновление.

Правила Security Group обзавелись собственными идентификаторами, а значит стали де факто отдельными ресурсами. Базово о практическом применении можно прочитать здесь.

В целом, у новой функциональности хватает плюсов. Во-первых, если одно правило используется несколькими SG одновременно, то не придется больше ходить и везде их менять (до этого “общее” правило цепляли на отдельную SG и назначали на все нужные области сети). Во-вторых, это упрощает управление, если за правило отвечает другая группа - теперь она может сама поменять, что нужно, а не заводить, ну не знаю, Change Request. В-третьих, это безусловно хорошая внутренняя оптимизация, которая положительно повлияет на квоты и лимиты (или нет).

Однако есть жирный минус - правила, пусть и со своими идентификаторами, все еще не живут без самой SG и заводить их отдельно нельзя. А бонус от изменения, описанный в примере выше, применим к тем, кто по какой-то причине управляет своей инфраструктурой только через Bash и awscli.

Как будто хотя бы одна маломальски серьезная организация так делает.

К сожалению, новая “фича” выглядит сыроватой, а анонс словно сделан в спешке. Тем не менее, если правила смогут стать полноценным независимыми сущностями и попадут в RAM, то просторов для использования много.

#машины_aws

Пока я работаю над длиннопостом, два занимательных и одновременно неприятных факта про DynamoDB:

1. DynamoDB TTL - бесплатный server-side способ удаления устаревших данных не предоставляет гарантий удаления в срок истечения! Хуже того то, что объекты с истекшим сроком жизни все еще отображаются в запросах, что перекладывает ответственность за фильтрацию валидных данных на клиента. Не смотря на то, что в среднем удаление занимает до 48 часов, мне известны случаи о задержке аж на 10 суток.

2. Capacity Units распределяются по шардам (Partition Key) таблиц, что может привести к ProvisionedThroughputExceededException при том, что throttle происходит только на конкретном шарде - так называемая проблема Hot Partition. По результатам общения с техподдержкой выяснилось, что:
- В режиме provisioned CUs, они равномерно распределяются по шардам; далее DDB будет распределять CU на более активные шарды. Как происходит распределение, когда количество шардов превышает количество CU, неизвестно.
- В режиме OnDemand, каждый шард получает 1000 WCU и 3000 RCU сразу же и перераспределения между шардами уже не происходит, поскольку 1000 записей и 3000 чтений в секунду - верхний порог.

Казалось бы мелочи, но эти мелочи выпили мне немало крови в Uber. И заметно сузили мой личный список подходящих бизнес задач для DynamoDB.

#машины_aws

Чем дилетанты отличаются от неудачников:
- Дилетанты осознают свои возможности и учатся
- Неудачники улюлюкают и устраивают клоунаду в Твиттере

Очевидно, дилетантам надо помогать и наставлять, а неудачников гнать и насмехаться.

Понедельничное чтиво для моих любимых дилетантов : мой набор трюков, как не тратить лишних денег на AWS.

#машины_aws

Распространненный миф о безопасных клавдиях больно ударил, что по Capital One в 2019 что по Twitch в 2021.

Непопулярное мнение: все эти инциденты - вина владельцев и инженеров сервисов и инфраструктуры и только их.

Особая близость с платежами и деньгами в целом сделала из меня параноика в хорошем смысле этого слова. Если это доступно где-то в интернете - это можно спиз… скачать.

Последний пост в этом году, после чего я могу спокойно отправляться на каникулы: вводная в событийно-ориентированное реагирование на мониторинг безопасности.

Читаем, применяем, не даем злодеям и своим наделать глупостей.

Всех с наступающим! Увидимся в 2022.

#машины_aws

Одно из моих любимых занятий - ковырять нелюбимые инструменты, чтобы не любить их экспертно и за дело. Один из таких инструментов - CodeDeploy - до неприятия муторный, сложный и противный.

Чего только стоит необходимость запускать Shell скрипты из spec-файла. Да, даже если весь скрипт состоит из одной команды.

Предлагаю разделить мою нелюбовь и начать эту неделю с мультирегионального развертывания приложений с помощью CodePipeline и CodeDeploy. Да еще и на виртуальные машины, чтоб жизнь совсем уж медом не казалась.

#машины_aws

Я продолжаю издеваться на Code* сервисами… Хотя скорее они надо мной.

В этой части разбираюсь с поведением CodeDeploy в Blue/Green развертываниях, а так же с тем, что не умеет CodePipeline и CDK.

Ваше прокрастинационное чтиво.

#машины_aws

Теперь, когда у нас есть AWS SDK для SAP ABAP, какой язык будет следующим?

Ставлю на COBOL.