Полезный пост с описанием моментов по созданию мультирегиональных приложений:

https://aws.amazon.com/blogs/architecture/creating-a-multi-region-application-with-aws-services-part-2-data-and-replication/

When building a distributed system, consider the consistency, availability, partition tolerance (CAP) theorem. This theorem states that an application can only pick 2 out of the 3, and tradeoffs should be considered.
▫️ Consistency – all clients always have the same view of data
▫️ Availability – all clients can always read and write data
▫️ Partition Tolerance – the system will continue to work despite physical partitions

#design

Хорошая статья-сравнение параллельного запуска Lambda, App Runner и Fargate:

https://nathanpeck.com/concurrency-compared-lambda-fargate-app-runner/

🔸 Concurrency
🔹 Scaling

Lambda
🔸 Single concurrent request per Lambda function instance, but many separate Lambda function instances
🔹 Fully managed by AWS Lambda, default limit of 1000 concurrent executions. Scale out more function instances in under a second.

App Runner
🔸 Multiple concurrent requests per container, enforces a configurable hard limit such as 100 concurrent reqs/container
🔹 Fully managed by App Runner. Configure a concurrency limit per containerized process. Scale out more container instances in less than 1 min.

Fargate
🔸 Multiple concurrent requests per container, no built-in limits on concurrency per container
🔹 Managed by you. Scale out more container instances based on your desired metric: CPU, concurrency, or a custom metric. Scale out in less than 1 min.

#design

Network Infrastructure Security Guidance:

https://media.defense.gov/2022/Mar/01/2002947139/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDANCE_20220301.PDF

Contents
1. Introduction
2. Network architecture and design
3. Security maintenance
4. Authentication, authorization, and accounting
5. Administrator accounts and passwords
6. Remote logging and monitoring
7. Remote administration and network services
8. Routing
9. Interface ports
10. Notification banners
11. Conclusion

#security #network #design

​​AWS drawing and diagramming tools:

https://aws.amazon.com/architecture/icons/#Drawing_and_diagramming_tools

#design

Бесконечно можно смотреть на 🔥 огонь и обсуждать, как на ☁️ AWS установить 🗒️ Wordpress:

https://www.youtube.com/watch?v=PYyAl2RPdhM

#design #Wordpress

​​📓 AWS Fault Isolation Boundaries:

https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html

Очень полезный для понимания работы AWS на глобальном уровне документ. Важный при проектировании архитектуры и принципиально важный при построении Disaster Recovery схемы.

Основная мысль такая. Если падает us-east-1, где располагается control plane большинства глобальных сервисов, то операции по их созданию, изменению, удалению перестанут работать (могут перестать, полагаться на это нельзя). При этом сервисы в регионах с нагрузками будут работать. Поэтому нужно планировать Disaster Recovery схему так, чтобы она не зависела от control plane.

В переводе на сервисы это означает следующее.


🔹 Route 53

Route 53 задействован под капотом самого AWS при создании многих сервисов, которым он должен сделать DNS собственные записи, в том числе хелсчеки, поэтому при проблемах в us-east-1 у Route 53 может не быть возможности создать нужные записи и потому запросы на создание большинства популярных ресурсов вернут ошибку. Это верно как минимум для следующего списка (список не полный):

▪️ API Gateway
▪️ CloudFront
▪️ DynamoDB Accelerator (DAX)
▪️ Global Accelerator
▪️ ECS with DNS-based Service Discovery
▪️ EKS Kubernetes control plane
▪️ ElastiCache
▪️ ELB load balancers
▪️ Lambda URLs
▪️ MemoryDB for Redis
▪️ Neptune
▪️ OpenSearch
▪️ PrivateLink VPC endpoints
▪️ RDS/Aurora

👉 Рекомендация: для критичных Disaster Recovery схем нужно создавать ресурсы заранее. Не получится во время проблем в us-east-1 поднять RDS базу данных из бэкапа. Не получится создать балансеры, Redis или CloudFront.


🔸 S3

S3 региональный сервис, но из-за того, что у S3 все имена должны быть уникальные, то не получится создать или удалить бакет во время проблем в us-east-1. Кроме того все операции по изменению конфигурации бакета (bucket policy, настройки CORS, ACL, шифрования, репликации, логирования и др.) тоже зависят от us-east-1.

👉 Рекомендация: для критичных DR схем создавать S3 бакеты заранее. Не получится во время проблем в us-east-1 создать новый S3 бакет или срочно прикрутить к нему репликацию.


🔹 CloudFront

CloudFront используется для API Gateway with edge-optimized endpoints.

👉 Рекомендация: создавать заранее все нужные API Gateway with edge-optimized endpoints.


🔸 AWS STS

IAM сервис глобальный, получить временные credentials через STS можно из любого региона. Если у вас захардкожен us-east-1, то когда у него проблемы, вы получите ошибки, в то время как региональный STS будет работать.

👉 Рекомендация: изменить в AWS CLI / AWS SDK захардкоженный us-east-1 на регион с нагрузкой.


🔹 IAM Identity Center (AWS SSO) / Federated SAML

SSO может пострадать, если в том регионе, где он настроен, проблемы.

👉 Рекомендация: создайте IAM юзеров на случай, если вы, как я, слишком уж стараетесь соблюдать security best practices. По-другому зайти в систему во время проблем с SSO не получится, потому для критических случаев нужно создать рабочекрестьянского IAM user-а.

Ужас какой. Короче, типа — WiFi это конечно очень круто, но бухту кабеля и обжим всё-таки пока не выбрасывайте.


🔸 S3 Storage Lens

Дефолтная борда и её метрики располагаются в us-east-1, поэтому при проблемах они могут быть не доступны.

👉 Рекомендация: если для вас критичны S3 Storage Lens, то нужно создать свои собственные дашборды, указав при создании свой регион.

#design

​​📄 AWS Whitepaper — AWS Multi-Region Fundamentals:

https://docs.aws.amazon.com/pdfs/whitepapers/latest/aws-multi-region-fundamentals/aws-multi-region-fundamentals.pdf

🔹 This paper focuses on high availability and continuity of operations requirements, and helps you navigate the considerations for adopting a multi-Region architecture for a workload.
🔸 It describes fundamental concepts that apply to design, development, and deployment of a multi-Region workload, along with a prescriptive framework to help you determine whether a multi-Region architecture is the right choice for a particular workload.
🔹 You need to ensure a multi-Region architecture is the right choice for your workload, because these architectures are challenging, and it’s possible that, if not done correctly, the overall availability of the workload can decrease.

#design

​​📓 Choosing the right AWS service to deploy your website or web application in the AWS Cloud — AWS Prescriptive Guidance:

https://docs.aws.amazon.com/prescriptive-guidance/latest/website-deployment-services

▫️ Static: S3 + CloudFront
▫️ JS framework + CI/CD: Amplify
▫️ Serverless + low-cost: API Gateway + Lambda + S3
▫️ WordPress/Drupal/Joomla: LightSail
▫️ Containers: App Runner or ECS or Fargate
▫️ Kubernetes: EKS
▫️ On-premises: EKS Anywhere or ECS Anywhere
▫️ Old-style managed environment: Beanstalk
▫️ Self-managed: EC2

#design

​​📘 AWS Reference Architecture — Invoking Asynchronous External APIs:

https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/invoking-asynchronous-external-apis-ra.pdf

1️⃣ Set up Step Functions
2️⃣ Send the task token and the request payload
3️⃣ Use Lambda to poll SQS and trigger an express Step Functions workflow
4️⃣ (Optionally) Add dynamic delay inside Lambda controlled by AppConfig
5️⃣ Step Function invokes an API Gateway HTTP proxy API
6️⃣ Invoke the external third-party asynchronous service API
7️⃣ Store the workflow’s task token and the received job ID in DynamoDB
8️⃣ Receive the completed job ID in a callback webhook endpoint
9️⃣ Transform the external callbacks with API Gateway
🔟 Use Lambda to poll the callback SQS
1️⃣1️⃣ Pass the job ID to the next step, and invoke a Step Function processor to fetch the job’s results

#design

Микросервисы → Монолит

Статья от Amazon Prime Video, где рассказывается, как удалось уменьшить расходы в десять раз после перехода с микросервисов на монолитную архитектуру:

https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

Статья достаточно скудная на факты, потому попробую изложить свою версию развития событий исходя из данного текста.

v.0.0.0

— Привет, Дмитро. Тут задача срочная прилетела — клиенту нужно запилить сервис по проверке качества роликов. А вы, помню, уже как-то что-то делали для тестирования видео?
— Было дело, накрапали костылик для внутренних нужд, чтобы отчёты слать аналитикам.
— Вот и отлично, приступайте.
— А какая нагрузка планируется?
— Подробностей не знаю, если что, чего-нибудь помощней поставим.
— Не, мы ж на Лямбдах всё написали.
— О, отлично, передам маркетингу — у нас будет Serverless-решение!

v.0.1.0

— Макс, что по нагрузке?
— Всё должно работать рилтайм и в перспективе держать тысячи параллельных задач на обработку.
— <censored>! Мы ж никогда пробовали на таких объёмах.
— Поздно, уже всё продано, продолжайте делать.
— А денег у клиента хватит?
— Деньги не проблема, главное сделать быстро!

v.1.0.0

— Дмитро, у нас проблемы. Клиент увидел счёт за прошлый месяц и офигел.
— Я предупреждал. И это лишь 5% от полной нагрузки.
— А почему так дорого?
— Так мы ж каждый кадр видео на S3 гоняем Лямбдами по несколько раз с помощью дорогущих Step Functions.
— И как это исправить?
— Никак, нужно всё переделывать. Проанализировать результаты под нагрузкой, попробовать различные варианты, спроектировать...
— ...А если нужно вчера?
— Ну, можно всё тупо засунуть в один контейнер и масштабировать как монолит с помощью ECS. Ещё и дешевле получится.
— О, супер, так и сделаем. И продадим как версию 2.0. А я напишу маркетингу, пусть они статейку накатают, как мы сэкономили клиенту кучу денег, перейдя на монолит с микросервисов. Все будут обсуждать только это и никто не вспомнит, как мы облажались с первой версией.

#serverless #monolith #design

Анализ статьи Amazon Prime Video

Во-первых, мои поздравления команде маркетинга Amazon — браво, великолепная работа! Кратко, минимум информации, точно в больное место и в результате каждый может сделать для себя (не)правильные выводы.

Во-вторых, если у вас есть сомнения в компетенциях управляющих процессом разработки в Amazon, то сначала спросите, что по этому поводу думает Google ChatGPT или просто посмотрите список самых успешных IT компаний.

Целью команды Amazon Prime Video было максимально быстро получить рабочий вариант. С отлаженным процессом разработки на Serverless можно выдавать готовые решения за несколько спринтов, в том числе для сложных и нагруженных систем.

Главный плюс Serverless — не условная "бесплатность", это уже побочный эффект. Главный плюс — скорость разработки и возможность справляться с неизвестной или непрогнозируемой нагрузкой.

Анализ статьи с цитатами из текста

1️⃣ Была задача получить решение максимально быстро и они сделали это. Serverless прекрасно вписывается в этот подход и команда имеет опыт разработки Serverless решений.

«We designed our initial solution as a distributed system using serverless components (for example, AWS Step Functions or AWS Lambda), which was a good choice for building the service quickly.»

2️⃣ Они получили опыт эксплуатации первой тестовой версии и реальные данные по нагрузке. Выяснилось, что быстро разработанное Serverless-решение имеет ограничения по масштабированию да при этом ещё и дорогое.

«In theory, this would allow us to scale each service component independently. However, the way we used some components caused us to hit a hard scaling limit at around 5% of the expected load. Also, the overall cost of all the building blocks was too high to accept the solution at a large scale.»

3️⃣ На основе полученных данных они получили возможность сформировать конкретные требования как по масштабированию, так и по стоимости. В результате чего переработали решение, выбрав монолитную архитектуру вместо распределённой.

«We initially considered fixing problems separately to reduce cost and increase scaling capabilities. We experimented and took a bold decision: we decided to rearchitect our infrastructure.
We realized that distributed approach wasn’t bringing a lot of benefits in our specific use case, so we packed all of the components into a single process. This eliminated the need for the S3 bucket as the intermediate storage for video frames because our data transfer now happened in the memory. We also implemented orchestration that controls components within a single instance.»

4️⃣ Изменения затронули лишь исполнительную часть, общая схема не изменилась, поэтому переход Serverless → ECS был быстрым.

«Conceptually, the high-level architecture remained the same. We still have exactly the same components as we had in the initial design (media conversion, detectors, or orchestration). This allowed us to reuse a lot of code and quickly migrate to a new architecture.»

Выводы

Имея свободу в изменении в том числе архитектурного решения, можно и быстро разрабатывать, и получать эффективные проекты.

Однако каждый может сделать и свои выводы — ещё раз респект маркетингу Amazon. Кстати, им точно стоит развить успех и помочь коллегам из AWS с придумыванием адекватных названий для сервисов.

P.S. Самая уместная (из немногих) статья по данной теме:

https://adrianco.medium.com/so-many-bad-takes-what-is-there-to-learn-from-the-prime-video-microservices-to-monolith-story-4bd0970423d4

#design #development #marketing

​​🔢 «Evolutionary Architectures» is a four-part blog series that shows how solution designs and decisions evolve as companies go through the different stages of the startups lifecycle.

1️⃣ «I’ve got this great idea!» — MVP:

https://aws.amazon.com/blogs/startups/evolutionary-architectures-series-part-1/

2️⃣ «I think we may be onto something» — evolving technical solution:

https://aws.amazon.com/blogs/startups/evolutionary-architectures-series-part-2/

3️⃣ «To the moon 🚀» — evolving architecture:

https://aws.amazon.com/blogs/startups/evolutionary-architectures-series-part-3/

4️⃣ «Would you like coffee with that?» — formalizing security and backup posture to meet various compliance standards:

https://aws.amazon.com/blogs/startups/evolutionary-architectures-series-part-4/

#design

Универсальные ответы для собесов по DevOps

... Что ...?

— «Docker» (40%)
— «Kubernetes» (40%)
— «Зависит от контекста» (20%)


... Почему?

— «Так исторически сложилось» (100%)

#devops #design

​​THE FRUGAL ARCHITECT

https://thefrugalarchitect.com/

#architecture #design

📚 Два главных документа которые должен знать каждый грамотный AWS DevOps Engineer:

1️⃣ AWS CAF (AWS Cloud Adoption Framework)
2️⃣ AWS WAF (Well-Architected Framework)

Это немалый объём и в реальности не два документа. Но это база. © Настоящая база, которая не про айноды. 😁

Можно спорить про применимость это для начинающих, хотя WAF (не который firewall) точно показан с самого начала и в режиме pocket book на все случаи.

Обязательно рекомендуется продвинутым. Особенно, если нужно прокачаться в ширину, а не глубину.

#design #CAF #WAF #devops

AWS Cloud Adoption Framework на русском.

https://d1.awsstatic.com/whitepapers/ru_RU/aws-cloud-adoption-framework.pdf

#design

​​Microfrontends on AWS

https://docs.aws.amazon.com/prescriptive-guidance/latest/micro-frontends-aws/introduction.html

• Foundational concepts
• Alternative architectures
• Architectural decisions
• Frameworks and tools
• API integration ‒ BFF
• Styling and CSS
• Organization
• Governance
• Platform team

#design

Постоянно обсуждать факап CrowdStrike — это норм.

А вот какого рожна фронт шлёт файлы на бэк, чтобы тот сохранял на S3, вместо того, чтобы грузить напрямую через подписанные ссылки — не, ты что, времени нет, работать надо.

#design