Забележка. превод: Тази статия, която стана хит в Medium, е преглед на ключови (2010-2019) промени в света на езиците за програмиране и свързаната технологична екосистема (със специален фокус върху Docker и Kubernetes). Неговият оригинален автор е Синди Шридхаран, която е специализирана в инструменти за разработчици и разпределени системи - по-специално тя написа книгата „Наблюдаемост на разпределените системи“ - и е доста популярна в интернет пространството сред ИТ специалистите, особено заинтересовани от темата за родния облак.
С наближаването на края на 2019 г. исках да споделя мислите си за някои от най-важните технологични постижения и иновации от последното десетилетие. Освен това ще се опитам да погледна малко в бъдещето и да очертая основните проблеми и възможности на следващото десетилетие.
Искам да поясня, че в тази статия не обхващам промени в области като науката за данни (наука за данни), изкуствен интелект, frontend инженеринг и т.н., тъй като аз лично нямам достатъчно опит в тях.
Типизацията отвръща на удара
Една от най-положителните тенденции на 2010 г. беше възраждането на статично типизираните езици. Такива езици обаче никога не са изчезнали (C++ и Java са търсени днес; те доминираха преди десет години), но динамично въведените езици (динамика) претърпяха значително увеличение на популярността след появата на движението Ruby on Rails през 2005 г. . Този растеж достигна своя връх през 2009 г. с отворения код на Node.js, което направи Javascript-on-the-server реалност.
С течение на времето динамичните езици са загубили част от своята привлекателност в областта на създаването на сървърен софтуер. Езикът Go, популяризиран по време на революцията на контейнерите, изглеждаше по-подходящ за създаване на високопроизводителни, ресурсно ефективни сървъри с паралелна обработка (с която самият създател на Node.js).
Rust, представен през 2010 г., включваше напредък в в опит да стане безопасен и въведен език. През първата половина на десетилетието приемането на Rust от индустрията беше доста хладно, но популярността му нарасна значително през втората половина. Известни случаи на употреба на Rust включват използването му за , (говорихме за това в - прибл. превод), ранен компилатор на WebAssembly от Fastly (сега част от bytecodealliance) и т.н. Тъй като Microsoft обмисля възможността за пренаписване на някои части от операционната система Windows в Rust, е безопасно да се каже, че този език има светло бъдеще през 2020-те години.
Дори динамичните езици получиха нови функции като (типове по избор). Те бяха внедрени за първи път в TypeScript, език, който ви позволява да създавате въведен код и да го компилирате в JavaScript. PHP, Ruby и Python имат свои собствени опционални системи за въвеждане (, ), които се използват успешно в .
Връщане на SQL към NoSQL
NoSQL е друга технология, която беше много по-популярна в началото на десетилетието, отколкото в края. Мисля, че има две причини за това.
Първо, NoSQL моделът, с липсата на схема, транзакции и по-слаби гаранции за последователност, се оказа по-труден за прилагане от SQL модела. IN със заглавие „Защо трябва да предпочитате силна последователност, когато е възможно“ (Защо трябва да изберете силна последователност, когато е възможно) Google пише:
Едно от нещата, които научихме в Google, е, че кодът на приложението е по-опростен и времето за разработка е по-кратко, когато инженерите могат да разчитат на съществуващо хранилище, за да обработват сложни транзакции и да поддържат данните в ред. За да цитираме оригиналната документация на Spanner, „Ние вярваме, че е по-добре за програмистите да се справят с проблеми с производителността на приложенията, дължащи се на злоупотреба с транзакции, когато възникнат тесни места, вместо постоянно да имат предвид липсата на транзакции.“
Втората причина се дължи на възхода на "мащабираните" разпределени SQL бази данни (като напр и ) в публичното облачно пространство, както и алтернативи с отворен код като CockroachDB (говорим и за нея - прибл. превод), които решават много от техническите проблеми, които караха традиционните SQL бази данни да „не се мащабират“. Дори MongoDB, някога олицетворение на NoSQL движението, сега е разпределени транзакции.
За ситуации, които изискват атомарно четене и запис в множество документи (в една или повече колекции), MongoDB поддържа транзакции с множество документи. В случай на разпределени транзакции, транзакциите могат да се използват в множество операции, колекции, бази данни, документи и фрагменти.
Тотален стрийминг
Apache Kafka без съмнение е едно от най-важните изобретения на последното десетилетие. Неговият изходен код беше отворен през януари 2011 г. и през годините Kafka революционизира начина, по който бизнесът работи с данни. Kafka е бил използван във всяка компания, за която съм работил, от стартиращи до големи корпорации. Гаранциите и случаите на използване, които предоставя (pub-sub, потоци, управлявани от събития архитектури) се използват в различни задачи, от съхранение на данни до мониторинг и стрийминг анализи, търсени в много области като финанси, здравеопазване, публичен сектор, търговия на дребно и др.
Непрекъсната интеграция (и в по-малка степен непрекъснато внедряване)
Непрекъснатата интеграция не се появи през последните 10 години, но през последното десетилетие се разпространи до такава степен, който стана част от стандартния работен процес (изпълнете тестове на всички заявки за изтегляне). Установяване на GitHub като платформа за разработване и съхраняване на код и, което е по-важно, разработване на работен процес, базиран на означава, че изпълняването на тестове преди приемане на заявка за изтегляне към master е единственото работен процес в разработка, познат на инженери, започнали кариерата си през последните десет години.
Непрекъснатото разгръщане (разгръщане на всеки комит, когато и когато достигне главния) не е толкова широко разпространено, колкото непрекъснатата интеграция. Въпреки това, с изобилието от различни облачни API за внедряване, нарастващата популярност на платформи като Kubernetes (които предоставят стандартизиран API за внедрявания) и появата на мултиплатформени, многооблачни инструменти като Spinnaker (изградени върху тези стандартизирани API), процесите на внедряване са станали по-автоматизирани, рационализирани и като цяло по-сигурни.
Контейнери
Контейнерите са може би най-нашумената, обсъждана, рекламирана и неразбрана технология на 2010-те. От друга страна, това е една от най-важните иновации на предходното десетилетие. Част от причината за цялата тази какофония се крие в смесените сигнали, които получавахме от почти навсякъде. Сега, когато шумът малко утихна, някои неща станаха по-остри.
Контейнерите станаха популярни не защото са най-добрият начин за стартиране на приложение, което задоволява нуждите на глобалната общност на разработчиците. Контейнерите станаха популярни, защото успешно се вписват в маркетингова заявка за определен инструмент, който решава съвсем различен проблем. Докер се оказа фантастично инструмент за разработка, който решава належащия проблем със съвместимостта („работи на моята машина“).
По-точно, революцията беше направена Докер изображение, защото реши проблема с паритета между средите и осигури истинска преносимост не само на файла на приложението, но и на всички негови софтуерни и операционни зависимости. Фактът, че този инструмент по някакъв начин стимулира популярността на „контейнерите“, които по същество са детайл от изпълнението на много ниско ниво, за мен остава може би основната загадка на последното десетилетие.
без сървър
Бих се обзаложил, че появата на изчисления без сървър е дори по-важна от контейнерите, защото наистина превръща мечтата за изчисления при поискване в реалност (По заявка). През последните пет години видях как подходът без сървър постепенно разширява обхвата си чрез добавяне на поддръжка за нови езици и времена за изпълнение. Появата на продукти като Azure Durable Functions изглежда е правилната стъпка към внедряването на функции със състояние (в същото време решаваща свързани с ограниченията на FaaS). Ще наблюдавам с интерес как се развива тази нова парадигма през следващите години.
Автоматизация
Може би най-големият бенефициент от тази тенденция е оперативната инженерна общност, тъй като тя даде възможност на концепции като инфраструктура като код (IaC) да станат реалност. Освен това, страстта към автоматизацията съвпадна с възхода на „SRE културата“, която има за цел да възприеме по-ориентиран към софтуера подход към операциите.
Универсална API-фикация
Друга интересна характеристика на последното десетилетие е API-фикацията на различни задачи за разработка. Добрите, гъвкави API позволяват на разработчика да създава иновативни работни процеси и инструменти, които от своя страна помагат при поддръжката и подобряват потребителското изживяване.
В допълнение, API-фикацията е първата стъпка към SaaS-фикацията на някаква функционалност или инструмент. Тази тенденция също съвпадна с нарастването на популярността на микроуслугите: SaaS се превърна в още една услуга, която може да бъде достъпна чрез API. Вече има много налични SaaS и FOSS инструменти в области като мониторинг, плащания, балансиране на натоварването, непрекъсната интеграция, предупреждения, превключване на функции (маркиране на функция), CDN, трафик инженеринг (напр. DNS) и т.н., които процъфтяха през последното десетилетие.
наблюдаемост
Заслужава да се отбележи, че днес имаме достъп до много по-напреднал инструменти за наблюдение и диагностика на поведението на приложенията от всякога. Може би може да се нарече системата за наблюдение Prometheus, която получи статут на отворен код през 2015 г най-доброто система за мониторинг от тези, с които съм работил. Не е перфектно, но значителен брой неща са внедрени по правилния начин (например поддръжка за измервания [дименсионалност] в случай на показатели).
Разпределеното проследяване беше друга технология, която навлезе в мейнстрийма през 2010 г., благодарение на инициативи като OpenTracing (и неговия наследник OpenTelemetry). Въпреки че проследяването все още е доста трудно за прилагане, някои от най-новите разработки дават надежда, че ще отключим истинския му потенциал през 2020 г. (Забележка: Прочетете също в нашия блог превода на статията “"от същия автор.)
Поглед към бъдещето
За съжаление, има много болезнени точки, които очакват решение през следващото десетилетие. Ето моите мисли за тях и някои потенциални идеи как да се отървете от тях.
Решаване на проблема със закона на Мур
Краят на закона за мащабиране на Dennard и изоставането спрямо закона на Moore изискват нови иновации. Джон Хенеси в обяснява защо проблемните наркомани (специфичен за домейн) архитектури като TPU може да са едно от решенията на проблема с изоставането спрямо закона на Мур. Комплекти инструменти като от Google вече изглежда добра стъпка напред в тази посока:
Компилаторите трябва да поддържат нови приложения, да бъдат лесно пренесени към нов хардуер, да свързват множество слоеве на абстракция, вариращи от динамични, управлявани езици до векторни ускорители и софтуерно контролирани устройства за съхранение, като същевременно осигуряват превключватели на високо ниво за автоматична настройка, осигурявайки просто- във функционалност - време, диагностика и разпространение на информация за отстраняване на грешки относно функционирането и производителността на системите в целия стек, като в повечето случаи осигурява производителност, която е сравнително близка до ръчно написан асемблер. Възнамеряваме да споделим нашата визия, напредък и планове за разработването и публичната достъпност на такава инфраструктура за компилиране.
CI / CD
Докато възходът на CI се превърна в една от най-големите тенденции на 2010 г., Jenkins все още е златният стандарт за CI.
Това пространство има остра нужда от иновации в следните области:
- потребителски интерфейс (DSL за кодиране на тестовите спецификации);
- подробности за изпълнението, които ще го направят наистина мащабируем и бърз;
- интеграция с различни среди (staging, prod и т.н.) за прилагане на по-напреднали форми на тестване;
- непрекъснато тестване и внедряване.
Инструменти за разработчици
Като индустрия ние започнахме да създаваме все по-сложен и впечатляващ софтуер. Въпреки това, когато става въпрос за нашите собствени инструменти, ситуацията може да бъде много по-добра.
Съвместното и отдалечено (чрез ssh) редактиране придоби известна популярност, но никога не се превърна в новия стандартен начин на разработка. Ако и вие като мен отхвърляте самата идея за нуждата постоянна връзка с интернет само за да можете да програмирате, тогава работата през ssh на отдалечена машина едва ли ще ви устройва.
Местните среди за разработка, особено за инженерите, работещи върху големи архитектури, ориентирани към услуги, все още са предизвикателство. Някои проекти се опитват да разрешат това и ще ми е интересно да знам как би изглеждал най-ергономичният UX за даден случай на употреба.
Също така би било интересно да се разшири концепцията за „преносими среди“ към други области на разработка като възпроизвеждане на грешки (или ), които възникват при определени условия или настройки.
Също така бих искал да видя повече иновации в области като семантично и чувствително към контекста търсене на код, инструменти за свързване на производствени инциденти със специфични части от кодовата база и т.н.
Компютър (бъдещето на PaaS)
След шума около контейнерите и без сървъра през 2010 г., гамата от решения в публичното облачно пространство се разшири значително през последните няколко години.
Това повдига няколко интересни въпроса. На първо място, списъкът с налични опции в публичния облак непрекъснато нараства. Доставчиците на облачни услуги разполагат с персонала и ресурсите, за да са в крак с най-новите разработки в света на отворения код и да пускат продукти като „безсървърни капсули“ (подозирам, че просто правят своите собствени FaaS изпълнения OCI съвместими) или други подобни фантастични неща.
Човек може само да завижда на тези, които използват тези облачни решения. На теория облачните предложения на Kubernetes (GKE, EKS, EKS на Fargate и т.н.) предоставят независими от доставчика на облак API за изпълнение на работни натоварвания. Ако използвате подобни продукти (ECS, Fargate, Google Cloud Run и др.), вероятно вече се възползвате максимално от най-интересните функции, предлагани от доставчика на услуги. Освен това, с появата на нови продукти или компютърни парадигми, миграцията вероятно ще бъде проста и без стрес.
Като се има предвид колко бързо се развива гамата от такива решения (ще бъда много изненадан, ако няколко нови опции не се появят в близко бъдеще), малки екипи за „платформи“ (екипи, свързани с инфраструктурата и отговорни за създаването на локални платформи за работещи компании за натоварвания) ще бъде невероятно трудно да се конкурират по отношение на функционалност, лекота на използване и цялостна надеждност. 2010-те видяха Kubernetes като инструмент за изграждане на PaaS (платформа като услуга), така че ми се струва напълно безсмислено да се изгради вътрешна платформа върху Kubernetes, която предлага същия избор, простота и свобода, налични в обществеността облачно пространство. Рамкирането на базиран на контейнер PaaS като „стратегия на Kubernetes“ е равносилно на умишлено избягване на най-иновативните възможности на облака.
Ако погледнете наличните днес изчислителни възможности, става очевидно, че създаването на ваш собствен PaaS, базиран единствено на Kubernetes, е равносилно на това да се притиснете в ъгъла (не е много далновиден подход, нали?). Дори ако някой реши да изгради контейнеризиран PaaS на Kubernetes днес, след няколко години той ще изглежда остарял в сравнение с облачните възможности. Въпреки че Kubernetes започна като проект с отворен код, неговият предшественик и вдъхновение е вътрешен инструмент на Google. Първоначално обаче е разработен в началото/средата на 2000-те, когато компютърната среда беше напълно различна.
Освен това, в много широк смисъл, компаниите не трябва да стават експерти в управлението на Kubernetes клъстер, нито изграждат и поддържат свои собствени центрове за данни. Осигуряването на надеждна компютърна основа е основно предизвикателство доставчици на облачни услуги.
И накрая, имам чувството, че малко сме регресирали като индустрия по отношение на опит за взаимодействие (). Heroku стартира през 2007 г. и все още е един от най-популярните лесен за използване платформи. Не може да се отрече, че Kubernetes е много по-мощен, разширим и програмируем, но ми липсва колко лесно е да започнете и да го внедрите в Heroku. За да използвате тази платформа, трябва само да знаете Git.
Всичко това ме води до следното заключение: имаме нужда от по-добри абстракции от по-високо ниво, за да работим (това е особено вярно за абстракции от най-високо ниво).
Правилният API на най-високо ниво
Docker е чудесен пример за необходимостта от по-добро разделяне на проблемите едновременно правилно внедряване на API от най-високо ниво.
Проблемът с Docker е, че (поне) първоначално целите на проекта бяха твърде широки: всичко в името на решаването на проблема със съвместимостта („работи на моята машина“) с помощта на контейнерна технология. Docker беше формат на изображение, среда за изпълнение със собствена виртуална мрежа, CLI инструмент, демон, работещ като root, и много повече. Във всеки случай размяната на съобщения беше още объркващи, да не говорим за "леки виртуални машини", cgroups, пространства от имена, множество проблеми със сигурността и функции, смесени с маркетинговия призив за "изграждане, доставяне, стартиране на всяко приложение навсякъде".
Както при всички добри абстракции, отнема време (и опит, и болка), за да се разбият различни проблеми на логически слоеве, които могат да се комбинират един с друг. За съжаление, преди Docker да достигне подобна зрялост, Kubernetes влезе в битката. Той монополизира цикъла на реклама толкова много, че сега всички се опитваха да бъдат в крак с промените в екосистемата на Kubernetes, а екосистемата на контейнерите придоби второстепенен статус.
Kubernetes споделя много от същите проблеми като Docker. Въпреки всички приказки за страхотна и композируема абстракция, разделяне на различни задачи на слоеве не е много добре капсулиран. В основата си това е оркестратор на контейнери, който управлява контейнери на клъстер от различни машини. Това е задача на сравнително ниско ниво, приложима само за инженери, работещи с клъстера. От друга страна, Kubernetes също е абстракция от най-високо ниво, CLI инструмент, с който потребителите взаимодействат чрез YAML.
Docker беше (и все още е) готино инструмент за разработка, въпреки всичките му недостатъци. В опит да бъдат в крак с всички „зайци“ наведнъж, неговите разработчици успяха да внедрят правилно абстракция на най-високо ниво. Под абстракция на най-високо ниво имам предвид подмножество функционалност, от която целевата аудитория (в този случай разработчици, прекарали по-голямата част от времето си в своите локални среди за разработка) наистина се интересуваше и която работеше чудесно извън кутията.
Помощна програма Dockerfile и CLI docker трябва да бъде пример за това как да се изгради добро „потребителско изживяване от най-високо ниво“. Един обикновен разработчик може да започне да работи с Docker, без да знае нищо за тънкостите внедрявания, които допринасят за оперативния опиткато пространства от имена, cgroups, ограничения на паметта и процесора и т.н. В крайна сметка писането на Dockerfile не се различава много от писането на shell скрипт.
Kubernetes е предназначен за различни целеви групи:
- клъстерни администратори;
- софтуерни инженери, работещи по инфраструктурни въпроси, разширяване на възможностите на Kubernetes и създаване на платформи, базирани на него;
- крайни потребители, взаимодействащи с Kubernetes чрез
kubectl.
Подходът на Kubernetes „един API пасва на всички“ представя недостатъчно капсулирана „планина от сложност“ без насоки как да бъде мащабирана. Всичко това води до неоправдано удължена учебна траектория. как Адам Джейкъб, „Docker донесе трансформиращо потребителско изживяване, което никога не е надминато. Попитайте всеки, който използва K8s, дали иска да работи като първия му docker run. Отговорът ще бъде да":
Бих казал, че повечето инфраструктурни технологии днес са на твърде ниско ниво (и следователно се считат за „твърде сложни“). Kubernetes е внедрен на доста ниско ниво. Разпределено трасиране в своя (много участъци, зашити заедно, за да образуват traceview) също се прилага на твърде ниско ниво. Инструментите за разработчици, които прилагат „абстракциите от най-високо ниво“, обикновено са най-успешни. Това заключение е вярно в изненадващ брой случаи (ако технологията е твърде сложна или трудна за използване, тогава „API/UI от най-високо ниво“ за тази технология все още не е открит).
В момента естествената облачна екосистема е объркваща поради фокуса си на ниско ниво. Като индустрия трябва да правим иновации, да експериментираме и да образоваме как изглежда правилното ниво на „максимална, най-висока абстракция“.
Търговия на дребно
През 2010 г. опитът с дигиталната търговия на дребно остава до голяма степен непроменен. От една страна, лекотата на онлайн пазаруването трябваше да удари традиционните магазини за търговия на дребно, от друга страна, онлайн пазаруването остава почти непроменено от десетилетие.
Въпреки че нямам конкретни мисли за това как тази индустрия ще се развие през следващото десетилетие, ще бъда много разочарован, ако през 2030 г. пазаруваме по същия начин, както през 2020 г.
журналистика
Все повече се разочаровам от състоянието на световната журналистика. Става все по-трудно да се намерят безпристрастни източници на новини, които да докладват обективно и педантично. Много често границата между самата новина и мненията за нея е размита. По правило информацията се представя пристрастно. Това е особено вярно в някои страни, където исторически не е имало разделение между новини и мнения. В скорошна статия, публикувана след последните общи избори в Обединеното кралство, Алън Ръсбриджър, бивш редактор на The Guardian, :
Основното е, че дълги години гледах американските вестници и съжалявах за моите колеги там, които единствено отговаряха за новините, оставяйки коментарите на съвсем други хора. С течение на времето обаче съжалението се превърна в завист. Сега мисля, че всички британски национални вестници трябва да разграничат отговорността си за новините от отговорността си за коментари. За съжаление е твърде трудно за обикновения читател - особено за онлайн читателите - да различи разликата.
Като се има предвид доста съмнителната репутация на Силиконовата долина, що се отнася до етиката, никога не бих се доверил на технологиите да „революционизират“ журналистиката. Като се има предвид това, аз (и много от моите приятели) ще се радвам, ако има безпристрастен, незаинтересован и надежден източник на новини. Въпреки че нямам представа как може да изглежда подобна платформа, аз съм уверен, че в епоха, в която истината става все по-трудна за разпознаване, нуждата от честна журналистика е по-голяма от всякога.
Социални мрежи
Социалните медии и новинарските платформи на общността са основният източник на информация за много хора по света, а липсата на точност и нежеланието на някои платформи да направят дори елементарна проверка на фактите доведе до катастрофални последици като геноцид, намеса в избори и др. .
Социалните медии са и най-мощният медиен инструмент, който някога е съществувал. Те коренно промениха политическата практика. Смениха рекламата. Те промениха поп културата (например основният принос за развитието на така наречената култура на отмяна [култури на остракизъм - прибл. превод] социалните мрежи допринасят). Критиците твърдят, че социалните медии са се оказали плодородна почва за бързи и капризни промени в моралните ценности, но също така са предоставили на членовете на маргинализирани групи възможността да се организират по начини, които не са имали досега. По същество социалните медии промениха начина, по който хората общуват и изразяват себе си през XNUMX век.
Но също така вярвам, че социалните медии изваждат наяве най-лошите човешки импулси. Внимателността и внимателността често се пренебрегват в полза на популярността и става почти невъзможно да се изрази аргументирано несъгласие с определени мнения и позиции. Поляризацията често излиза извън контрол, което води до това, че обществото просто не чува индивидуалните мнения, докато абсолютистите контролират проблемите на онлайн етикета и приемливостта.
Чудя се дали е възможно да се създаде „по-добра“ платформа, която насърчава по-качествени дискусии? В края на краищата това, което движи „ангажираността“, често носи основната печалба на тези платформи. как Кара Суишър в New York Times:
Възможно е да се развиват дигитални взаимодействия, без да се провокира омраза и нетолерантност. Причината повечето сайтове за социални медии да изглеждат толкова токсични е, че са създадени за скорост, вирусност и внимание, а не за съдържание и точност.
Би било наистина жалко, ако след няколко десетилетия единственото наследство на социалните медии беше ерозията на нюансите и уместността в публичния дискурс.
PS от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com