Прим. прев.: Тази статия, която стана хит в Medium, е преглед на ключовите (от 2010 до 2019 г.) промени в света на езиците за програмиране и свързаната с тях технологична екосистема (особено внимание се отделя на Docker и Kubernetes). Нейният оригинален автор е Cindy Sridharan, която се специализира в инструментите за разработчици и разпределени системи — в частност, тя е написала книга „Distributed Systems Observability“ и е доста популярна в интернет пространството сред IT специалисти, особено заинтересовани от темата за cloud native.
2019 г. приключи, затова бих искала да споделя моите мисли за някои от най-важните технологични постижения и иновации на изминалото десетилетие. Освен това ще се опитам да погледна малко в бъдещето и да определя основните предизвикателства и възможности на предстоящата декада.
Искам веднага да уточня, че в тази статия не обхващам промените в области като наука за данни (data science), изкуствен интелект, frontend engineering и т.н., тъй като лично нямам достатъчно опит в тях.
Типизацията нанася ответен удар
Една от най-позитивните тенденции на 2010-те години беше възраждането на езиците със статична типизация. Въпреки това, подобни езици никога не изчезнаха (C++ и Java са търсени днес; те доминираха и преди десет години), обаче езици с динамична типизация (динамични) преживяха значителен растеж на популярността след възникването на движението Ruby on Rails през 2005 г. Този растеж достигна своя връх през 2009 г. с открития код на Node.js, благодарение на който Javascript на сървъра стана реалност.
С времето динамичните езици загубиха част от своята привлекателност в областта на създаването на сървърен софтуер. Езикът Go, популяизиран по време на контейнерната революция, изглеждаше по-добре приспособен за създаване на високопроизводителни, ресурсоефективни сървъри с паралелна обработка на информация (с което самият създател на Node.js).
Rust, представен през 2010 г., включи постижения в в опит да стане безопасен и типизиран език. През първата половина на десетилетието отношението към Rust в индустрията беше доста хладно, обаче през втората половина неговата популярност значително нарасна. Сред забележителните примери за използване на Rust можем да споменем неговото приложение за , (мы рассказывали о нём в — бел. ред.), досрочном WebAssembly-компиляторе от Fastly (ныне входит в bytecodealliance) и др. В условиях, когда Microsoft рассматривает возможность переписать некоторые части ОС Windows на Rust, можно с уверенностью сказать, что в 2020-х этот язык ожидает светлое будущее.
Даже динамические языки получили новые возможности вроде (optional types). Впервые они были реализованы в TypeScript — языке, позволяющем создавать типизированный код и компилировать его в JavaScript. PHP, Ruby и Python обзавелись собственными системами опциональной типизации (, ), которые успешно используются в .
Возвращение SQL в NoSQL
NoSQL — еще одна технология, которая в начале десятилетия была гораздо более популярной, чем в конце. Думаю, для этого есть две причины.
Во-первых, модель NoSQL с отсутствием схемы, транзакций и более слабыми гарантиями согласованности, оказалась сложнее в реализации, нежели модель SQL. В с названием «Почему следует предпочитать строгую согласованность при любом удобном случае» (Why you should pick strong consistency, whenever possible) Google пишет:
Одна из вещей, которую мы уяснили в Google, состоит в том, что код приложения проще, а сроки разработки короче, если инженеры могут положиться на имеющиеся хранилища при обработке сложных транзакций и поддержании порядка данных. Цитируя оригинальную документацию к Spanner, «мы считаем, что лучше, если программисты будут заниматься проблемами с производительностью приложения из-за злоупотребления транзакциями по мере возникновения узких мест, нежели чем постоянно будут держать в уме отсутствие транзакций».
Вторая причина связана с ростом «масштабируемых» распределенных баз данных SQL (таких как и ) в публичном облачном пространстве, а также Open Source-альтернатив вроде CockroachDB (про неё мы тоже — бел. ред.), которые решают многие из технических проблем, из-за которых традиционные SQL-базы «не масштабировались». Даже MongoDB, когда-то бывшая олицетворением движения NoSQL, теперь распределенные транзакции.
В ситуации, когато е необходима атомарност на операциите за четене и записване в множество документи (в една или няколко колекции), MongoDB поддържа транзакции с много документи. При разпределени транзакции, транзакциите могат да се използват за множество операции, колекции, бази данни, документи и шардове.
Тотална стримификация
Apache Kafka безспорно стана едно от най-важните изобретения на последното десетилетие. Неговият изходен код беше отворен през януари 2011 г. и през тези години Kafka направи истинска революция в работата с данни за бизнеса. Kafka беше използван във всички компании, в които съм работил, от стартапи до големи корпорации. Осигурените от него гаранции и опции за употреба (pub-sub, потоци, събитийно-ориентирани архитектури) се прилагат в различни задачи: от организиране на съхранение на данни до мониторинг и потокова аналитика, търсени в множество области, като финанси, здравеопазване, държавен сектор, търговия на дребно и др.
Непрекъсната интеграция (и в по-малка степен непрекъснато разгръщане)
Непрекъснатата интеграция (Continuous Integration) не се е появила в последните 10 години, но именно през последното десетилетие тя се е разпространила до такава степен, че се е превърнала в част от стандартния работен процес (проверка на тестовете на всички pull request-и). Установяването на GitHub като платформа за разработка и съхранение на код и, което е по-важно, развитието на работния процес на база означава, че провеждането на тестове преди приемането на pull request-а в master е единственото работен процес в разработката, познат на инженерите, започнали кариерите си през последните десет години.
Непрекъснатото разгръщане (Continuous Deployment; разгръщане на всеки комит в момента, в който попадне в master) не е толкова широко разпространено, колкото непрекъснатата интеграция. Въпреки това, с множество различни облачни API за разгръщане, нарастваща популярност на платформи като Kubernetes (осигуряващи стандартизиран API за разгръщане) и появата на мултиплатформени, мултиоблачни инструменти като Spinnaker (построени върху споменатите стандартизирани API), процесите на разгръщане стана по-автоматизирани, организирани и, като цяло, по-сигурни.
Контейнери
Контейнерите вероятно могат да бъдат наречени най-обсъжданата, рекламирана и погрешно разбирана технология на 2010-те години. От друга страна, те са едно от най-важните иновации на предишното десетилетие. Частично причината за целия този хаос е в смесените сигнали, които получавахме практически от навсякъде. Сега, когато шумотевицата малко утихна, някои моменти придобиха по-ясни оттенъци.
Контейнерите станаха популярни не защото това е най-добрият начин да стартирате приложение, отговарящ на изискванията на глобалната общност от разработчици. Те станаха популярни, защото успешно се вписват в маркетинговото търсене на инструмент, решаващ съвсем различна задача. Docker се оказа фантастичен инструмент за разработка, решаващ настоящия проблем с съвместимостта (‘работи на моята машина’).
По-точно, революцията е предизвикана Docker-образ, тъй като решава проблема с паритета между средите и осигурява истинска преносимост не само на файла на приложението, но и на всички негови софтуерни и оперативни зависимости. Този факт, че този инструмент по някакъв начин покачи популярността на ‘контейнерите’, които по същество са доста нискоуровнева част от реализацията, за мен остава, вероятно, най-голямата загадка на миналото десетилетие.
Serverless
Готова съм да споря, че появата на ‘безсървърни’ изчисления е дори по-важна от контейнерите, тъй като наистина позволява реализацията на мечтата за изчисления по запитване (on-demand). През последните пет години наблюдавах постепенното разширяване на приложението на безсървърния подход (добавяна е поддръжка за нови езици и среда за изпълнение). Появата на продукти като Azure Durable Functions изглежда като правилна стъпка към реализиране на stateful функции (попутно решаваща , свързани с ограниченията на FaaS). С интерес ще наблюдавам как тази нова парадигма ще се развива в близките години.
Автоматизацията
Вероятно, сообщество инженеров по эксплуатации стало главным бенефициаром этого тренда, так как он позволил реализовать концепции вроде «инфраструктура как код» (IaC). Кроме того, увлечение автоматизацией совпало с ростом «культуры SRE», которая ориентирована на более программный подход к эксплуатации.
Универсальная API-фикация
Еще одной интересной особенностью прошедшего десятилетия стала API-фикация различных задач разработки. Эффективные, гибкие API позволяют разработчикам создавать инновационные рабочие процессы и инструменты, что, в свою очередь, способствует обслуживанию и повышает удобство работы.
Кроме того, API-фикация — это первый шаг к SaaS-фикации определенного функционала или инструмента. Эта тенденция также совпала с ростом популярности микросервисов: SaaS стал просто еще одним сервисом, с которым можно работать через API. В настоящее время существует множество SaaS- и FOSS-инструментов в таких областях, как мониторинг, платежи, балансировка нагрузки, непрерывная интеграция, оповещения, переключение функциональности, CDN, управление трафиком (например, DNS) и т.д., которые активно развивались в прошлом десятилетии. (флаг функциональности), CDN, инжиниринг трафика (например, DNS) и т.д., которые процветали в прошлом десятилетии.
Наблюдаемость
Следует отметить, что сегодня доступны намного более современные инструменты для мониторинга и диагностики поведения приложений, чем когда-либо ранее. Систему мониторинга Prometheus, получившую статус Open Source в 2015 году, можно считать, пожалуй, лучшей системой мониторинга из тех, с которыми мне доводилось работать. Она не идеальна, однако значительное количество аспектов реализовано в ней совершенно правильно (например, поддержка измерений [dimensionality] при работе с метриками).
Распределенная трассировка стала еще одной технологией, вышедшей в мейнстрим в 2010-х благодаря таким инициативам, как OpenTracing (и ее преемнице OpenTelemetry). Хотя трассировка по-прежнему довольно сложна в применении, некоторые из последних разработок позволяют надеяться, что в 2020-х мы раскроем ее истинный потенциал. (Прим. перев.: Читайте также в нашем блоге перевод статьи «» этого же автора.)
Заглядывая в будущее
За съжаление, съществуват много болеви точки, които очакват разрешение в идното десетилетие. Ето моите мисли по този повод и някои потенциални идеи за тяхното преодоляване.
Решаване на проблема с закона на Мур
Краят на закона на Деннарда и отстъплението от закона на Мур изискват нови иновации. John Hennessy в обяснява защо архитектури, зависими от проблемите, (domain specific) като TPU, могат да станат едно от решенията на проблема с отстъплението от закона на Мур. Тулкити като от Google вече представляват добра стъпка напред в тази посока:
Компилаторите трябва да поддържат нови приложения, лесно да се пренасочват към ново хардуерно обезпечение, да свързват много нива на абстракция, започвайки от динамично управлявани езици до векторни ускорители и софтуерно управлявани устройствa, като предоставят високо ниво на превключватели за автоматична настройка, осигурявайки функционалност just-in-time, диагностика и разпространявайки отладъчна информация за функционирането и производителността на системите в целия стек, като в повечето случаи осигуряват производителност, близка до ръчно написания асемблер. Ние планираме да споделим нашето виждане, напредъка и плановете относно разработването и публичната достъпност на такава компилираща инфраструктура.
CI/CD
Въпреки че растежът на популярността на CI стана един от основните трендове на 2010-те, Jenkins все още остава златен стандарт за CI.
Тази област спешно се нуждае от иновации в следните области:
- потребителски интерфейс (DSL за кодиране на тестови спецификации);
- детайли от реализирането, които ще го направят истински мащабируем и бърз;
- интеграция с различни среди (staging, prod и т.н.) за извършване на по-усъвършенствани форми на тестване;
- непрекъсната проверка и разпределение.
Инструменти за разработчици
Като индустрия, ние започнахме да създаваме все по-сложен и впечатляващ софтуер. Въпреки това, когато става въпрос за нашите собствени инструменти, може да се каже, че ситуацията би могла да бъде значително по-добра.
Съвместното и отдалечено (по ssh) редактиране набра известна популярност, но не стана нов стандартен метод за разработка. Ако и вие, както и аз, отхвърляте самата мисъл за необходимостта от постоянно свързване с интернет, само за да можете да се занимавате с програмиране, то работата през ssh на отдалечена машина едва ли ще ви устройва.
Локалните разработки, особено за инженери, които работят върху големи услуги с ориентирана архитектура, все още остават проблем. Някои проекти се опитват да го решат и бих искал да разбера как ще изглежда най-ергономичният UX за този сценарий на употреба.
Също така бих искал да развия концепцията за "преносими среди" в други области на разработката, като възпроизвеждане на грешки (или ), срещащи се при определени условия или настройки.
Също така бих искала да видя повече иновации в области като семантично и контекстно зависимо търсене на код, инструменти, които позволяват свързването на инциденти в продукция с конкретни части от кодовата база и т.н.
Изчисления (бъдещето PaaS)
На фона на общия шум около контейнерите и serverless в 2010-те, спектърът от решения в публичното облачно пространство значително се разшири през последните няколко години.
В тази връзка възникват няколко интересни въпроса. На първо място, списъкът с налични опции в публичното облак постоянно расте. Доставчиците на облачни услуги имат персонал и ресурси, които им позволяват лесно да следят последните постижения в света на Open Source и да предлагат продукти като "serverless pod'ове" (подозирам, просто правейки собствените си FaaS runtime'и съвместими с OCI) или други подобни странни неща.
Тези, които ползват облачни решения, могат само да завиждат. В теорията облачните предложения на Kubernetes (GKE, EKS, EKS на Fargate и др.) предоставят независими от облачния доставчик API за стартиране на работни натоварвания. Ако ползвате подобни продукти (ECS, Fargate, Google Cloud Run и др.), вероятно вече максимално използвате най-интересните функции, предлагани от доставчика на услуги. Освен това, при появата на нови продукти или изчислителни парадигми, миграцията вероятно ще бъде лесна и безпроблемна.
С оглед на това, колко бързо се развива спектърът на подобни решения (бих се учудил, ако в близко бъдеще не се появят нови варианти), на малките "платформени" екипи (екипи, свързани с инфраструктурата и отговорни за създаването на платформи on-premise за стартиране на работни натоварвания в компаниите) ще им бъде невъзможно да се конкурират по отношение на функционални възможности, удобство на използване и обща надеждност. Десетилетие 2010-те премина под знака на Kubernetes като инструмент за създаване на PaaS (платформа като услуга), затова ми се струва напълно безсмислено създаването на вътрешна платформа на базата на Kubernetes, която предлага същите възможности за избор, удобство и свобода, налични в публичното облачно пространство. Представянето на
Ако погледнем наличните сегашни изчислителни способности, става очевидно, че създаването на собствена PaaS изцяло на базата на Kubernetes е равно на самостоятелното запращяне в ъгъл (не особено далновиден подход, нали?). Дори и някой да реши днес да създаде контейнерна PaaS на базата на Kubernetes, след няколко години тя ще изглежда остаряла в сравнение с облачните способности. Въпреки че Kubernetes е започнал своето съществуване като проект с отворен код, неговия предшественик и идеен вдъхновител е съответният вътрешен инструмент на Google. Обаче той първоначално е бил разработен в началото/средата на 2000-те години, когато изчислителният ландшафт е бил напълно различен.
В допълнение, в много широк смисъл компаниите не трябва да стават експерти в управлението на Kubernetes клъстери, както те не се занимават със създаване и поддържане на собствени центрове за данни. Осигуряването на надеждна изчислителна основа е основна задача. доставчици на облачни услуги.
Накрая, имам чувството, че като индустрия малко регресирахме относно опита на взаимодействие (). Heroku бе стартирана през 2007 година и все още остава една от най- лесните за използване платформи. Несъмнено, Kubernetes разполага с много по-голяма мощ, разширяемост и програмируемост, но ми липсва колко лесно беше да започна работа и да направя разгръщане в Heroku. За да се възползваш от тази платформа, ти е нужно само да знаеш Git.
Всичко това води до следното заключение: необходимите ни са най-добрите, по-високо ниво абстракции (особено верни за абстракции от най-високо ниво).
Правилният API на най-високо ниво
Docker е отличен пример за необходимостта от по-добро разделение на задачите, съчетано с правилната реализация на API на най-високо ниво..
Проблемът на Docker е, че (поне) в началото пред проекта бяха поставени твърде глобални цели: всичко с цел разрешаване на проблема със съвместимостта ("работи на моята машина") чрез контейнерна технология. Docker бе и формат на изображения, и runtime с собствена виртуална мрежа, и CLI инструмент, и демон, работещ под root, и много други. Във всеки случай, комуникацията беше повече от объркваща, да не говорим за "леките VM", контролни групи, пространства имена, многобройни проблеми със сигурността и функции, смесени с маркетинговото призив "създавайте, доставяйте, стартирайте всяко приложение навсякъде".
Както с всички добри абстракции, се изисква време (както и опит и болка), за да се разделят различни проблеми на логически слоеве, които могат да се комбинират помежду си. За съжаление, преди Docker да може да достигне такава зрялост, в битката се включи Kubernetes. Той монополизира хипа до такава степен, че сега всеки се опитваше да не изостава от промените в екосистемата на Kubernetes, а екосистемата на контейнерите стана второстепенна.
Kubernetes споделя много от същите проблеми, които и Docker. Независимо от всички приказки за страхотна и композируема абстракция, разделянето на различни задачи на слоеве не е особено добре инкапсулирано. В своята същност това е оркестратор на контейнери, който стартира контейнери в клъстера, състоящ се от различни машини. Това е доста ниско ниво задача, приложима само за инженери, експлоатиращи клъстера. От друга страна, Kubernetes е също абстракция от най-високо ниво, CLI инструмент, с който потребителите взаимодействат чрез YAML.
Docker беше (и остава) страхотен инструмент за разработка, въпреки всички свои недостатъци. В опит да настигне всички "зайци" разработчиците му успяха да реализират правилно абстракция от най-високо ниво. Под абстракция от най-високо ниво разбирам подмножество функционалности, в които се интересуваше целевата аудитория (в този случай разработчиците, прекарали по-голямата част от времето си в локалните си среда за разработка) и което работеше чудесно "извън кутията".
Dockerfile и CLI утилита docker трябва да станат пример за изграждане на добър "потребителски интерфейс от най-високо ниво". Обикновеният разработчик може да започне работа с Docker, без да знае каквито и да било подробности от реализацията, които допринасят за експлоатационния опит, като пространства за имена, контролните групи, ограничения по памет и CPU и т.н. В крайна сметка писането на Dockerfile не се различава особено от написването на shell скрипт.
Kubernetes е предназначен за различни целеви групи:
- администратори на клъстера;
- инженери-програмисти, занимаващи се с въпросите на инфраструктурата, разширяващи възможностите на Kubernetes и създаващи платформи на неговата основа;
- крайни потребители, взаимодействали с Kubernetes чрез
kubectl.
Подходът "един API за всичко", приложен в Kubernetes, представлява недостатъчно инкапсулирана "гора от сложност" без указания как да се мащабира. Всичко това води до неоправдано дълго обучение. Както Адам Джейкъб, "Docker донесе на потребителите трансформиращо преживяване, което все още не е надминато. Попитайте всеки, който използва K8s, иска ли да работи като техния първи docker run. Отговорът ще бъде положителен:
Бих казала, че основната част от инфраструктурната технология днес е твърде нискоуровнева (и следователно смятана за "т твърде сложна"). Kubernetes е реализиран на доста ниско ниво. Разпределеното трасиране в нейната (множество span-ове, зашити заедно, за да образуват traceview) също е реализирано на твърде ниско ниво. Инструментите за разработчици, реализиращи "абстракции на най-високо ниво", обикновено се оказват най-успешни. Това заключение е валидно в удивителен брой случаи (ако технологията е твърде сложна или трудна за употреба, тогава "API/UI на най-високо ниво" за тази технология едва предстои да бъде открита).
В момента екосистемата cloud native ни обърква с цикличността си на ниско ниво. Като индустрия трябва да внедряваме иновации, да експериментираме и да обучаваме как изглежда правилното ниво на "максимална, най-висока абстракция".
Търговия на дребно
През 2010-те години цифровият опит в търговията на дребно почти не се е променил. От една страна, леснотата на онлайн пазаруването би трябвало да удари класическите търговски магазини, от друга — онлайн пазаруването дотолкова фундаментално почти не се е променило за десетилетие.
Въпреки че нямам конкретни мисли относно развитието на тази индустрия през следващото десетилетие, ще бъда силно разочарована, ако през 2030 г. пазаруваме по същия начин, по който го правим през 2020 г.
Журналистика
С всеки изминал ден все повече се разочаровывам от състоянието на световната журналистика. Става все по-трудно да се намерят безпристрастни новинарски ресурси, които да излъчват обективно и педантично. Много често границата между самата новина и мнението за нея се размазва. Обикновено информацията се представя с предразсъдък. Това е особено вярно в определени държави, където исторически не е имало разделение между новината и мнението за нея. В скорошна статия, публикувана след последните общи избори във Великобритания, Alan Rusbridger, бивш редактор на The Guardian, :
Основната идея е, че с течение на годините наблюдавах американските вестници и се чувствах съжалителен към колегите там, които са отговорни единствено за новините, оставяйки коментирането на съвсем други хора. Въпреки това, с времето съжалението се трансформира в завист. Сега смятам, че всички британски национални вестници трябва да разделят отговорността за новините от отговорността за коментарите. За съжаление, на обикновения читател – особено онлайн читателя – му е твърде трудно да различи разликата.
Като се има предвид достатъчно съмнителната репутация на Силиконовата долина, що се отнася до етика, при никакви обстоятелства не бих доверила технологиите да „революционизират“ журналистиката. В същото време, аз (и много мои познати) бихме се радвали, ако се появи неутрална, безкористна и надеждна новинарска платформа. Все още не си представям как би изглеждала такава платформа, но съм сигурна, че в епохата, когато истината става все по-трудна за разпознаване, нуждата от честна журналистика е по-голяма от всякога.
Социални мрежи
Социалните мрежи и колективните новинарски платформи са основен източник на информация за много хора на различни части на света, а недостатъкът на точност и нежеланието на някои платформи да извършат дори основна проверка на фактите водят до такива трагични последствия като геноцид, намеса в изборите и т.н.
Социалните мрежи също са най-мощното медийно средство, което някога е съществувало. Те коренно промениха политическата практика. Те промениха рекламата. Те промениха поп културата (например, основен принос за развитието на т.нар. cancel culture [култура на остаряване – бел. прев.] внасят именно социалните мрежи). Критици твърдят, че социалните мрежи се оказаха плодородна почва за бързи и „капризни“ промени в моралните ценности, обаче те също така предоставиха на представителите на маргинални групи възможността да се обединяват (преди те никога не са имали такава възможност). По същество, социалните мрежи промениха начина на комуникация и начина на самоизразяване на хората в XXI век.
Въпреки това, аз също съм убедена, че социалните медии насърчават проявата на най-лошите човешки импулси. Вниманието и обмислянето често биват пренебрегвани в името на популярността, и става практически невъзможно да се изрази аргументирано несъгласие с определени мнения и позиции. Поляризацията често излиза извън контрол, в резултат на което аудиторията просто не слуша индивидуалните мнения, докато абсолютистите контролират въпросите на онлайн етикета и приемливостта.
Замислям се дали е възможно да се създаде "най-добрата" платформа, която да насърчава качеството на дискусиите? В крайна сметка, именно това, което движи "вовлечеността", често носи основната печалба на тези платформи. Как Кара Сушър в New York Times:
Може да се развива цифровото взаимодействие, без да се провокира омраза и нетърпимост. Причината, поради която повечето социални мрежи изглеждат толкова токсични, е, че те са създадени за скорост, вирусност и привличане на внимание, а не за съдържание и точност.
Би било наистина тъжно, ако след две десетилетия единственото наследство на социалните медии бъде размазването на нюансите и адекватността в публичния дискурс.
P.S. от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «».
Източник: habr.com
