Мейнфреймы. 1960–1980-е годы
Особенности периода. Начальный этап с появления компьютеров как таковых до примерно 1985-го года характеризуется тем, что программы разрабатывают для себя. Небольшие группы разработчиков реализуют довольно ограниченную функциональность, которая отвечает нуждам и используется внутри одной компании или госструктуры. Этой ограниченной функциональностью может быть запуск людей на Луну, но всё равно сфера применения этой программы гораздо-гораздо уже, чему у современных сервисов.
Пользователи: сотрудники компании. Число пользователей программ того времени очень ограниченно: это 3 космонавта корабля «Аполлон», 20 человек, рассчитывающих государственный бюджет, 100 человек, обрабатывающих результаты переписи населения.
Дистрибуция ПО: физическая, на мейнфрейме. Пробиваются перфокарты, загружаются в ЭВМ, и минут через 10 программа готова к использованию. За доставку, по сути, отвечает человек, который пробивает перфокарты. При этом если программист допустил ошибку, то исправлять её долго: заново писать и отлаживать код, пробивать перфокарты, загружать. На всё это уйдут дни и впустую будет потрачено время многих людей — цена ошибки очень высока, возможно, катастрофа.
На этом этапе IT-бизнеса как такового еще не существует. Если посмотреть в Википедии количество компаний по производству ПО, основанных в 1975-м, то их там будет всего четыре. Правда, одна из них — Microsoft, которая тогда была очень маленькой и нишевой.
Персональные компьютеры и ООП. 1980-1990-е годы
Все начинает меняться примерно в 1985 году с массовым распространением персональных компьютеров: в 77-м началось производство Apple II, в 81-м появился IBM PC, чуть раньше стали популярны минимейнфреймы от DEC.
Особенности периода: создание программного обеспечения начинает формироваться в бизнес-направление. Это становится возможным, потому что пользователей программ стало больше и можно строить программы на продажу.
Например, в 79-м появляется электронная таблица VisiCalc, которая заменяет собой бухгалтера-калькулятора — человека, который фактически работал excel'ем. Бухгалтер заносил в большую бумажную таблицу числа и как-то по формулам их обрабатывал. Потом аналитик спрашивал, что будет, если доход в третьем квартале будет в два раза больше, и бухгалтер-калькулятор менял одно значение и снова всё пересчитывал на бумаге.
Пользователи: внешние по отношению к производителю ПО компании. VisiCalc перевернул всю индустрию компьютерного бизнеса, программа, вместо узконаправленной штуки, которая пишется для конкретного набора людей, стала массовой. Например, экономисты и аналитики стали покупать компьютеры, чтобы использовать электронные таблицы.
Поскольку пользователей стало много и программы начали продавать частным лицам, возникает вопрос: как сделать так, чтобы программа работала у такого большого количества людей, и как разрабатывать такие сложные программы.
Поскольку расширяется аудитория, то нужна и большая функциональность. Соответственно, нужно увеличивать команду разработки — это уже не десяток программистов, а 100-500 человек, которые работают над сложным программным продуктом.
Интересно, что в каждой эпохе становления IT есть несколько ключевых книг, которые в своё время вызвали переворот в мышлении. Период, когда зарождается бизнес разработки программного обеспечения и команды разработчиков растут, на мой взгляд, характеризуется двумя книгами: «Мифический человеко-месяц» и «Приёмы объектно-ориентированного проектирования. Паттерны проектирования». То есть с одной стороны появляется понимание, что невозможно, увеличив команду в 4 раза, сократить время разработки в 4 раза. А с другой — что есть решение, которое способно помочь масштабироваться.
Популярным решением проблемы роста сложности ПО становится ООП. Считается, что если взять большую программу, допустим, Microsoft Excel, и разбить на какие-то объекты, то группы разработчиков смогут работать над ними независимо. Таким образом получится масштабировать работу на отдельные элементы функциональности и ускорить разработку нашего Microsoft Excel. Причем под «ускорить», скорее всего, понимается цикл разработки в несколько лет.
Но по сути, мы по-прежнему упаковываем программу в один пакет — exe-файл во времена повсеместного использования Microsoft DOS, а потом Windows — и поставляем пользователю.
Доставка ПО: на физических носителях. Но так как теперь это массовое производство, то доставка ПО заключается в том, чтобы: записать наш exe-шник на дискеты, наклеить на них наклейки с названием продукта, упаковать в коробки и буквально доставить пользователям в разных странах. При этом необходимо не допустить существенное количество брака, потому что если произвести дискеты где-нибудь в Америке, доставить в Россию и обнаружить, что половина из них с браком, это будут огромные издержки и мы потеряем пользователей насовсем.
Цена ошибки: пользователи вернут деньги и больше никогда не купят продукт, что может погубить весь бизнес.
Цикл разработки ПО просто потрясающе долог, этапы занимают месяцы:
- планирование — 12 месяцев;
- разработка — 24 месяца;
- тестирование — 12 месяцев;
- доставка — 12 месяцев.
Новая версия выпускается раз в несколько лет, поэтому никак нельзя допускать ошибки на этапе кодирования.
Однако главный риск связан с тем, что на протяжении всего этого длинного цикла разработки отсутствует обратная связь от пользователей.
Представьте: мы придумали новый IT-продукт, провели небольшое исследование и решили, что, возможно, эта программа понравится пользователю. Но убедиться в этом мы никак не можем! Мы можем только два года писать софт, а потом попросить бухгалтеров у себя в округе, например, в Редмонде, поставить новую версию Excel и попробовать её использовать. И это по сути все наши возможности для тестирования продукта. Поэтому не исключено, что через два года разработки окажется, что наше ПО никому не нужно.
Если же наш софт всё-таки покупают, но он имеет баги и плохо работает, то пользователи легко могут его вернуть — это еще физический товар, коробка, которую можно принести обратно в магазин. И заодно решить, что покупать ПО этого производителя больше никогда не стоит.
Agile. 2001–2008
Следующая эра начинается с распространением интернета в 2000-х.
Особенности периода: IT-бизнес переходит в интернет, но браузеры работают еще так себе.
Microsoft создаёт Internet Explorer и бесплатно поставляет его всем пользователям Windows. Интернет становится доступен огромному числу людей, но при этом браузер Microsoft целенаправленно сделан не очень пригодным для реализации динамической функциональности, чтобы защитить свои программы от конкуренции со стороны браузерных приложений и Netscape (подробнее по запросу «Война браузеров»). Поэтому интернет еще используется в основном для загрузки файлов, но этого уже достаточно, чтобы бизнес перешёл в интернет.
Доставка ПО: дистрибутивы становится возможно распространять через интернет.
Дистрибуция ПО через интернет позволяет гораздо чаще — раз в несколько месяцев — выпускать обновления и новые версии. Больше не обязательно записывать ПО на дискеты и диски — пользователи могут скачать обновления из интернета, а разработчики могут допускать больше ошибок.
Цена ошибки: риск для бизнеса уже не так велик, потому что пользователь может получить обновление и продолжить пользоваться продуктом.
Где-то в это время зарождается Agile и выходят книги о гибкой разработке и экстремальном программировании, которые и для современного IT-менеджмента являются классической основой, например: «Extreme Programming Explained: Embrace Change», «Refactoring. Improving the Design of Existing Code», «Test Driven Development».
Цикл разработки в начале 2000-х выглядит примерно так:
- планирование — 2 месяца;
- разработка — 6-12 месяцев;
- тестирование — 1-3 месяца;
- доставка — несколько недель.
Можно, например, больше не тестировать так тщательно. Если у 10% пользователей проявятся баги, то для них можно выпустить патч, а не тратить заранее год на то, чтобы убедиться, что наше ПО работает как надо абсолютно везде. Таким образом, можно гораздо быстрее проверять гипотезы, но быстрее тут — это по-прежнему полгода-год.
То, что можно меньше вкладываться в тестирование и детальное планирование, позволяет сократить расходы на проведение эксперимента. И слово «эксперимент» станет ключевым в следующую эпоху.
DevOps. 2009–2020
Особенности периода: устанавливаемого ПО практически не осталось, а немногое существующее обновляется через интернет. Интернет используется повсеместно, становятся популярны социальные сети и развлекательный софт, которые живут исключительно в интернете. Реализовывать сложную динамическую функциональность интерфейсов можно непосредственно в браузере — и мы переходим туда.
Доставка ПО: посредством Облака. Если раньше, программа всё равно устанавливалась на компьютер пользователя и для него должна была быть отлажена, то теперь по сути нужно сделать программу лишь под один компьютер — сервер в Облаке. Для нас это удобно тем, что у нас есть полный контроль над этим компьютером и тем, как работают на нём наши программы. Конечно, остаются некоторые трудности с отрисовкой интерфейсов в браузере, но они гораздо менее серьезные чем те, что были раньше.
Всё это позволяет ускорить планирование, реализацию, тестирование. Больше нам не нужно месяцами или годами жить с чёрной дырой неизвестности: выстоит ли проект или нет, нужна ли в нём такая функциональность и т.д. Обновлять ПО можно практически в реальном времени.
Но в 2006-2008 идеологически ПО еще разрабатывается по-прежнему — как некое цельное ядро. Это, конечно, не exe'шник, но это всё равно цельный монолит, состоящий из набора очень плотно связанных объектов. Такое ПО слишком тяжеловесное, для того чтобы меняться так быстро, как этого хочет рынок.
Для решения проблемы неповоротливости монолита те же самые ребята, которые принесли нам ООП, говорят, что приложение можно и в целом разделить на отдельные программы, которые будут между собой коммуницировать. И тогда будет возможным ещё больше увеличить команду разработчиков — с сотен до тысяч — и создавать новую функциональность непрерывно. Тем самым проводить как можно больше экспериментов, проверять гипотезы, адаптировать бизнес под запросы рынка и действия конкурентов и двигать его вперед.
В 2009 году выходит первый доклад о том, как Dev и Ops объединяются, чтобы обеспечить 80 деплоев в день, и это становится одной из главных ценностей в разработке. Цикл разработки теперь выглядит совершенно по-другому:
- планирование — несколько недель;
- разработка — несколько недель;
- тестирование — несколько дней;
- доставка — несколько минут.
Ошибки можно исправлять практически на лету и разрабатывать гипотезу очень быстро. Тут же появляется всем известное теперь слово «MVP».
Если в 70-е у разработчика почти не было права на ошибку и ПО было фактически недвижимым — при запуске космонавтов на луну требования к функциональности не часто меняются — то теперь софт становится абсолютно динамическим. Все готовы к тому, что будут баги, поэтому и нужна поддержка и команда, которая будет обеспечивать работу системы в условиях динамичного развития.
До этого профессия человека, который обеспечивал систематическую доставку программного обеспечения, вообще говоря, не была айтишной. В 70-80-е это были люди, которые засовывали перфокарты в компьютеры, в 80-90-е —люди, которые грамотно вели переговоры с фабриками и заводами по производству дисков и занимались логистикой. Это всё абсолютно не связано ни с разработкой, ни с системным администрированием.
Не погруженные глубоко в тему DevOps люди часто думают, что DevOps — это новое клёвое название для админов, которые больше общаются с разработчиками. Но бизнес (и википедия) считает, что DevOps — это методология внутри процесса разработки ПО. И не так важно, что конкретно она означает, — важно, что она дает. А дает DevOps как методология возможность максимально быстро адаптироваться к изменениям рынка и менять сам процесс разработки ПО.
Если компания не хочет отставать от конкурентов, то ей нужно переходить от длинных циклов разработки и релизов раз в месяц к DevOps. DevOps-трансформация при этом означает обеспечение Agile-процесса целиком — от разработки до выкладки. И таким образом процесс доставки ПО включается в процесс разработки и становится айтишной специальностью.
И да, поскольку процесс доставки обычно включает в себя работу, связанную с серверными и инфраструктурными штуками, то кажется, что это должен или может делать человек с админским бэкграундом. Но это приводит к проблеме во взаимопонимании инженеров и бизнеса. Особенно когда речь идет об админах, переживающих DevOps-трансформацию и выполняющих запросы бизнеса, который хочет быть гибче.
У большинства админов, которые занимаются обеспечением отказоустойчивости, идеология «работает — не трожь!» находится во главе угла. Они хоть и не запускают «Аполлон» на Луну, но мыслят теми же категориями надежности. А бизнес в новых условиях, пускай и ценой сбоев, хочет:
- минимальное время от идеи до продакшена;
- максимальное количество проверенных гипотез за короткое время;
- минимальное влияние ошибок на работу продакшена.
Пускай оно сразу упадет — это ничего, мы откатим, поправим и снова выложим. Лучше быстрее проверить, чем вкладываться во что-то, на что не будет спроса.
Не нужно обеспечивать стабильность маленького кусочка нового кода; нужно иметь возможность выкинуть его как можно быстрее и вернуть тот, который работал. Это опять про гибкость: ценность не в стабильности кода, который выложен в инфраструктуре, а в способности инфраструктуры быть максимально гибкой.
Источник статьи: https://habr.com/ru/company/itsumma/blog/525070/