Downloaded 25 times
Uploaded byAlex Tregubov
Architecture of infrastructure in cloud 0.5
The document discusses the architecture of infrastructure in cloud computing. It covers why organizations move to the cloud, cloud-ready architectures like grid and transactional, common cloud services like object storage, compute instances, load balancers and CDNs. It also discusses disaster recovery, capacity planning, dynamic, proactive and reactive scaling in the cloud. The document provides examples of Amazon and other cloud vendor services and considerations for when an organization may not be suitable to move completely to the cloud.
More Related Content
Similar to Architecture of infrastructure in cloud 0.5
![UNIT I -Introduction to CLOUD COMPUTING [Autosaved].pptx](https://cdn.slidesharecdn.com/ss_thumbnails/uniti-introductiontocloudcomputingautosaved-250128091123-f66abd14-thumbnail.jpg?width=640&height=640&fit=bounds)
Architecture of infrastructure in cloud 0.5
- 1.
- 2. PRESENTATION STRUCTURE • Why cloud? • Cloud ready architectures • Cloud services • Disaster recovery • Capacity planning 2
- 3.
- 4. WHY WE TALKABOUT CLOUDS? • Основная причина – борьба с высокими нагрузками 4
- 5. CLASSICAL APPLICATION EVOLUTION Database cache User requests Database server Application server Media content Content server 5
- 6. KEY BOTTLENECKS • CPU -> Balancer for app servers, database clustering • RAM -> Clustering or memory consuming components • Network ing-> DNS RR, object storage, CDN • Disk I/O -> database clustering • Ping -> CDN, per-region architecture 6
- 7. VIRTUAL/HARDWARE VS CLOUD Virtual/HW hosting Cloud On-demand self-service Broad network access Resource pooling Rapid elasticity 7
- 8.
- 9. CLOUD ARCHITECTURES -GRID 9
- 10. CLOUD ARCHITECTURES -TRANSACTIONAL 10
- 11.
- 12. CLOUD SERVICES • Object Storage • Compute Instances • Load balancers • CDN • Networking 12
- 13. OBJECT STORAGE • AmazonS3 • Atmos 13
- 14.
- 15. EPHEMERAL • Sometimes youhave no “physical “ access to VM at all 15
- 16. LOAD BALANCERS • Whatis it? • How it works? • How it configures? 16
- 17. MONITORING • Cloud Watch • What is it? • How I can use it? • Monitoring + Load balancer 17
- 18. CONTENT DELIVERY NETWORK •Amazon Cloud Front • Akamai • Etc. • What is it? • Why I should use it? • Where I can use it? 18
- 19. NETWORKING • Public networks • Private networks • Network configuration • Security groups 19
- 20.
- 21. AUTOMATION 21
- 22. MONITORING 22
- 23.
- 24.
- 25.
- 26.
- 27.
- 28. WHY PROJECTS MOVINGTO CLOUD? • Cost reduction • Pay as you go • Scalability and elasticity • Ready for automation • Device and location independent • Buzzword 28
- 29. WHEN YOU CANTUSE CLOUD? • When you need hardware • When you need high speed I/O (high speed storage) • 100% capacity usage • Barrier to exit (migration to cloud more expensive then classical infrastructure) • Integration with legacy systems • Security concerns 29
- 30. OUR CONTACTS SpecialEPM-CITConsulting@epam.com http://cloud.epam.com https://twitter.com/EPAM_Cloud http://epamcloud.blogspot.com/ https://www.yammer.com/epam.com/ 30
- 31. QUESTIONS 31
- 32. THANK YOU 32
Editor's Notes
- #5 С каждым днем количество пользователей в сети растет, если средний сайт раньше должен был работать с 10ми и сотнями пользователями онлайн, теперь эта уже как минимум тысячи.Все чаще проекту нужно быстро, а желательно еще и автоматически справляться с растущей нагрузкой на ваше приложение.Давайте посмотрим как идет эволюция большинства проектов.
- #6 В самом простом случае, у нас есть application-сервер который доступен из Интернета, который обрабатывает запросы пользователей, а также отдает медиа контент (картинки, видео, CSS, JS и т.д.).На бэкенде работает сервер баз данных.Это простая схему, среднее приложение так и работает, но если оно активно развивается, количество пользователей растет, инфраструктура соответственно становится сложнее…Дальше поняли что отделение статических данных от контроллера это хорошо, т.к. уменьшается время на обработку «ненужных» запросов к апп-серверу, трафик и TCP-соединенияДальше база перестала выдерживать нагрузки и мы поставили предварительный кэш на чтение (memcached, redis, EHCache/Terracota etc.)Дальше начали плодить app-сервера т.к. CPU одного сервера не справляется с нагрузкойДальше база начала валится на записи и пришлось делать database clusterИтак мы очевидно сталкиваемся с проблемами масштабирования, а именно…
- #7 CPU,решается балансировкой на несколько серверовRAM, …
- #8 Из-за того что узкие места могут появляться в любой момент, более того для некоторых приложений это нормальная практика, вам нужно реагировать на них быстро и желательно без потерь для пользователя.Классический хостинг явно проигрывает клаудам, он не дает вам нужно быстроты в управлени и пластичности. Он не дает приложению возможности САМОМТОЯТЕЛЬНО масштабироваться.Давайте рассмотрим как должно выглядеть идеальное облачное приложение.
- #9 Можно выделить две основные архитектуры при построении облачных приложений…
- #10 Grid, решающяя задачи на вычисление или обработку данных. Научные системы, биллинг системы, обработка медиа информации (кодирование звука, видео, изображения)
- #11 Transactional – сделал запрос, получил ответ. Поисковые системы, блоги, соц сети и т.д.Ваше приложение масштабируется в нужных пределах по всем узким местам (CPU, сеть и т.д.)Вы используете сервисы и API облака для масштабирования в обоих направлениях (как на увеличение так и на уменьшение)
- #29 Облако нам дает:Снижение стоимости за счет оплаты только тех сервисов и ресурсов которые вы использовали…
- #30 Есть причины по которым облако не даст вам преимуществ или вы и вовсе не сможете его использовать:…
- #31 You can always come to us and ask questions, but we recommend you to use our Informational Portal first, it has answers to all Frequently Asked questions, integration with Management Console, Comprehensive help materials, Glossary and other valuable additions that will help you on your way to Self-Service model utilization.