Евгений Штольц - Из разработчика в архитекторы. Практический путь

Контейнеризация

История развития инфраструктуры

Limoncelli (автор "The Practice of Cloud System Administration"), работавший долгое в Google Inc, считает, что 2010 год – год перехода от эры традиционного интернет к эре облачных вычислений.

* 1985–1994 – время мэйнфреймов (больших компьютеров) и внутрикорпоративного обмена данных, при котором

можно легко планировать нагрузку

* 1995–2000 – эра появления интернет компаний,

* 2000-2003

* 2003-2010

* 2010-2019

Увеличение производительно отдельно машины меньше, чем прирост стоимости, например, увеличении производительности в 2 раза приводит к увеличению стоимости существенно большей, чем в 2 раза. При этом, каждое следующее увеличении производительности обходится кратно дороже. Следовательно, каждый новый пользователь обходился дороже.

Позже, в период 2000–2003 годах, смогла сформироваться экосистема, предоставляющая принципиально другой подход:

* появление распределённых вычислений

* появление маломощных массовой аппаратуры

* созревание OpenSource решений, позволяющие устанавливать программное обеспечение на множество машин,

не связанное связкой лицензия процессор

* созревание телекоммуникационной инфраструктуры

* увеличении надёжности за счёт распределения точек отказов

* возможность наращивания производительности при потребности в будущем за счёт добавления новых

компонентов

Следующим этапом слала унификация, наибольшее проявлявшаяся в 2003–2010 годах:

* предоставление в дата центре не места в шкафу (power-location), а уже унифицированного железа

закупленного оптом для всего цента

* экономия на ресурсах

* виртуализация сети и компьютеров

Следующую веху положил Amazon в 2010 году и ознаменовал эру облачных вычислений. Этап характеризуется строительством масштабных дата центов с заведомым избытком по мощностям для получения меньшей стоимости вычислительных мощностей за счёт опта в расчёте на экономию для себя и выгодную продажу их избытка в розницу. Такой подход применяется не только к вычислительной мощности, инфраструктуре, но и программному обеспечению, формирую его как сервисы для удешевления их использования за счёт их продажи в розницу как большим компаниям, так и начинающим.

Необходимость однотипности окружения

Обычно начинающие разработчики разрабатывающие под Linux предпочитают работать из под Windows, чтобы не изучать незнакомую ОС и набивать на ней свои шишки, ведь раньше всё было далеко не всё так просто и так отлажено. Часто разработчики вынуждены работать из под Windows из-за корпоративных пристрастий: 1C, Directum и другие системы работают только на Windows, и вся остальная, а главное сетевая, инфраструктура заточена под эту операционную систему. Работа из Windows приводит к большим потерям рабочего времени как разработчиков, так и DevOps на устранения как мелких, так и крупных отличий в операционных системах. Эти отличия начинают проявляться от самых простых задач, например, что может быть проще сверстать страничку на чистом HTML. Но неправильно настроенный редактор поставит в BOM и переводы строк, принятые в Windows: "\n\r" вместо "\n"). BOM при склейке шапки, тела и подвала страницы создаст отступы между ними, они не будут видны в редакторе, так как эти они образуются байтами метаинформации о типе файла, в Linux которые не имеют такого значения и воспринимаются как перевод отступ. Другие переводы строк в GIT не позволяет увидеть сделанные вами отличие, ведь отличие в каждой строке.

Теперь возьмём front разработчика. С первого взгляда, что сложного, ведь JS (JavaScript), HTML и CSS нативно интерпретируются браузером. Раньше делалась вёрстка всех разных страниц – проверялась дизайнером и заказчиком и отдавалась php разработчику на интеграцию с фреймворком или cms. Для того, чтобы не править шабпку на каждой страницы, а потом долго выяснять, когда они начали отличаться и какая из них правильнее использовался HAML. HAML добавляет дополнительный синтаксис в HTML, чтобы избежать булирования: циклы, подключения файлов, в нашем случае единую шапку и подвал страницы. Но он требует специальной программы, перегоняющий HTML в чистый HTML. В MS Windows это решается установкой программы компилятора и подключением её к IDE, благо все эти возможности есть в IDE WebStorm. С CSS и его размером, дублями, зависимостями и поддержкой для разных браузеров всё гораздо сложнее – там использовался LESS, а сейчас возглавил более функциональный SASS и библиотеками поддержки разных браузеров, который требует компилятора Rubi и подобная связка, обычно, с первого раза не работает. А для JS использовался CoffeScript. Всё это нужно прогонять через программы сжатия и валидации (валидировать html обычно не нужно).