Successfully reported this slideshow.
Your SlideShare is downloading. ×

Dobre praktyki projektowania architektury i wdrażania systemów IT dla chmury obliczeniowej AWS

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 33 Ad

Dobre praktyki projektowania architektury i wdrażania systemów IT dla chmury obliczeniowej AWS

Download to read offline

Jacek pracuje z chmurą obliczeniową AWS od 2008 roku, na początku jako niezależny ekspert/administrator AWS, obecnie architekt AWS/właściciel firmy, która jest pierwszym AWS Partnerem w Polsce.
Wykorzystując swoje wieloletnie doświadczenie, pomaga klientom w różnej wielkości projektach, od start-ups po rozwiązania typu Enterprise, we wdrażaniu najlepszych rozwiązań na chmurze AWS, które spełnią wszystkie wymagania biznesowe.

Jacek pracuje z chmurą obliczeniową AWS od 2008 roku, na początku jako niezależny ekspert/administrator AWS, obecnie architekt AWS/właściciel firmy, która jest pierwszym AWS Partnerem w Polsce.
Wykorzystując swoje wieloletnie doświadczenie, pomaga klientom w różnej wielkości projektach, od start-ups po rozwiązania typu Enterprise, we wdrażaniu najlepszych rozwiązań na chmurze AWS, które spełnią wszystkie wymagania biznesowe.

Advertisement
Advertisement

More Related Content

Slideshows for you (20)

Similar to Dobre praktyki projektowania architektury i wdrażania systemów IT dla chmury obliczeniowej AWS (20)

Advertisement

Recently uploaded (20)

Dobre praktyki projektowania architektury i wdrażania systemów IT dla chmury obliczeniowej AWS

  1. 1. Good practices to design and implement IT architecture based on AWS
  2. 2. About us • 11+ years of professional experience in Unix and 7+ years in Cloud Computing administration • Founder at LCloud – “Linxsys Cloud”, AWS Partner from 2012, first AWS Partner in Poland • We are after 150+ AWS projects • Enterprise experience: • Email: jacek.biernat@linxsys.pl
  3. 3. Design for Failure – High Available solution One of the major reasons for migration to Cloud Computing: - Avoid single points of failure - Assume everything fails Our goal: Application should continue to function even if the underlying physical hardware fails or is removed or replicated
  4. 4. A simple Architecture
  5. 5. High Available Environment
  6. 6. Stateless solutions Do not modify the application code:
  7. 7. Stateless solutions Do not modify the application code: - Network-Attached Storage (NAS) solution with Raid 1 via network: DRBD, GlusterFS
  8. 8. Stateless solutions Do not modify the application code: - Network-Attached Storage (NAS) solution with Raid 1 via network: DRBD, GlusterFS - Amazon Elastic File System (EFS)
  9. 9. Stateless solutions Do not modify the application code: - Network-Attached Storage (NAS) solution with Raid 1 via network: DRBD, GlusterFS - Amazon Elastic File System (EFS) - Mount Amazon S3 bucket as file system: s3fs, s3ql
  10. 10. Stateless solutions Do not modify the application code: - Network-Attached Storage (NAS) solution with Raid 1 via network: DRBD, GlusterFS - Amazon Elastic File System (EFS) - Mount Amazon S3 bucket as file system: s3fs, s3ql - Amazon Elastic Load Balancer with sticky session (sometimes is enough)
  11. 11. Stateless solutions Modify the application code:
  12. 12. Stateless solutions Modify the application code: - Our database tier
  13. 13. Stateless solutions Modify the application code: - Our database tier - Amazon S3
  14. 14. Stateless solutions Modify the application code: - Our database tier - Amazon S3 - Amazon Elasticache (Redis), Amazon DynamoDB
  15. 15. When an AWS AZ in EU-West itself fails ?
  16. 16. When the Entire EU West region is affected ?
  17. 17. Proposal of solutions when a region is not available
  18. 18. Proposal of solutions when a region is not available • RTO and RPO is max. 24 hours – Amazon Cloudformation templates – Copy backup to second region
  19. 19. Proposal of solutions when a region is not available • RTO and RPO is max. 24 hours – Amazon Cloudformation templates – Copy backup to second region • RTO and RPO is max. 5 minutes – Amazon Cloudformation templates – Configure Replication data between regions
  20. 20. Proposal of solutions when a region is not available • RTO and RPO is max. 24 hours – Amazon Cloudformation templates – Copy backup to second region • RTO and RPO is max. 5 minutes – Amazon Cloudformation templates – Configure Replication data between regions • Keep two active environments Master-Master – Use a queue solution (Amazon DynamoDB, SQS)
  21. 21. Implement Elasticity Don’t assume health or fixed location of components. Use designs that are resilient to reboot and re-launch.
  22. 22. Standardized Application Stacks
  23. 23. Approaches to designing AMI 1. Inventory of fully baked AMI 2. Base AMI with fetch on boot 3. AMI with Agent to management system
  24. 24. Fully baked AMI
  25. 25. Tools for fully baked AMI • AWS Console • AWS API with scripts
  26. 26. Base AMI
  27. 27. Base AMI • Jenkins/Team City • Amazon Cloudformation
  28. 28. Base AMI • Jenkins/Team City • Amazon Cloudformation • Ansible playbooks • Aminator
  29. 29. AMI with Agent to management system
  30. 30. Tool to management system • Puppet • Chef • Ansible
  31. 31. Micro-services and elastic resource pools with AWS • Each service is decoupled from the rest and deployed individually • We run multiple services on the same instances • An automated deployment system takes care of all services lifecycle details
  32. 32. Amazon EC2 Container Service (ECS) – a fully managed platform
  33. 33. Thank you for your attention

×