2. Типичная архитектура разработки и тестирования
локально
Обсуждение миграции
Возможные (и некоторые – совершенно точные)
челленджи
Открывающиеся на этом пути возможности
5. IIS VM SQL VM
IaaS
PaaS – Website
PaaS – Cloud Service
11. Обязательно нужно привлекать вендора:
1) Есть специальные программы DevOps/др.
(спросите у нас в перерыве )
2) Без архитектора со стороны вендора может
быть сложно с нюансами
3) Ни в коем случае не делать burst
4) Делать это инкрементально
12. Классикой является развязывание связной
архитектуры и переезд, начиная с самого некритичного компонента:
1) Хранилище
2) Мониторинговые инструменты
3) Сборка
4) Репозиторий
5) Все остальное, что осталось
Посмотрим по отдельности на подводные камни.
13. 1) Связность облачной инфраструктуры с
локальной
2) Хранилище уже не просто «диск и шара»
3) Функциональный паритет локального ПО с
сервисами
4) Инфраструктурного плана вопросы
(построение домена, др.)
5) Бенчмаркинг не очень прост
6) Сервисные ограничения
7) Сложность подсчета цены
14. VSO
Yes Yes
Yes Yes
Yes Yes
Yes Yes
+/- ++
+/- ++
Yes No
Yes No
Yes No
Yes No
Yes Partial
No Yes
No Yes
No Yes
25. https://blogs.msdn.microsoft.com/bharry/2014/08/22/retrospective-on-the-aug-14th-vs-online-outage/
We’ve gotten sloppy. Sloppy is probably too harsh. As with any team, we are pulled in the tension between
eating our Wheaties and adding capabilities that customers are asking for. In the drive toward rapid
cadence, value every sprint, etc., we’ve allowed some of the engineering rigor that we had put in
place back then to atrophy – or more precisely, not carried it forward to new code that we’ve been
writing. This, I believe, is the root cause – Developers can’t fully understand the cost/impact of a change
they make because we don’t have sufficient visibility across the layers of software/abstraction…