Овој хабрапост е интервју со Антон Вајс, косопственик на технолошки консалтинг Otomato Software, со повеќе од 15 години искуство во областа на високата технологија. Тој е експерт за техничка настава, иницијатор и коавтор на првиот курс за сертификација DevOps во Израел. Антон учествува на меѓународни конференции и е познат како кул говорник.
Ќе разговараме на следните теми:
Разлика меѓу Русија и Израел
Олег: Ве молиме кажете ни кој сте и што правите.
Антон: Јас сум Антон, роден во Санкт Петербург, но на 15 години се преселив во Израел и оттогаш живеам таму. Во последните дваесет години во Израел се занимавам со ИТ во нејзините различни обвивки. Од овие дваесет години, во последните десет сум специјализиран за сè што е поврзано со испорака на софтвер: интеграција, она што некогаш се нарекуваше управување со конфигурации и она што сега се нарекува DevOps. Работев во големи компании - во меѓународни претпријатија како AT&T, BMC. Работел во стартапи. Во последните четири години, имам своја консултантска компанија, наречена Otomato Software, каде што сме ангажирани да им помагаме на организациите да ги оптимизираат процесите на испорака и да совладаат нови алатки: односно, го правиме и техничкиот дел и сè околу него.
Олег: Има ли разлика меѓу Русија и Израел во однос на работата?
Антон: Речиси никогаш не сум работел со руски клиенти. Она што ме поврзува со Русија во последните 3 години се конференциите. И во неколку руски компании извршивме нешто како ревизија: дојдовме, погледнавме, сфативме, издадовме некои препораки и заминавме. Односно, немаше таква секојдневна работа, така што ми е тешко да кажам точно како се разликува. Мислам дека има различни работи насекаде. Односно, во Израел, на пример, имаме такви тешки корпоративни организации во кои луѓето работат 15 години, и сè се движи многу тешко. И како и да се обидуваат да направат некаква трансформација, да ги подобрат процесите: ќе разговараат и ќе разговараат, но... Имаме клиент со кој пред две години направивме сè и ги донесовме сите одлуки, ги развивме сите програми и во некој тој момент се запре, излеговме од таму. Пред само неколку дена ги запознав газдите од таму со кои работевме и реков:
- Па, како?
- Па, вака. Тешко е, велат тие, го правиме тоа, сега нешто почнува да се случува.
Две години подоцна. Има политика, има зони на влијание. Има луѓе кои не сакаат да ги испуштат овие зони на влијание, затоа, кога ќе се појави таква ситуација, многу е тешко да се промени нешто. Па, самите алатки некако одат напред. Од друга страна, во Израел има стартапи во кои сè се менува многу брзо, лесно е да се подигне нова алатка, а веќе сите се родени во облакот и се целосно во облакот. Ова, инаку, можеби е една од опипливите разлики меѓу Русија и Израел. Во Израел, јавниот облак е многу полесен. Од она што го видов. Во Русија, на пример, се чини дека на сите, освен на стартапите, им е многу тешко да одат на јавниот облак, но во Израел сепак е полесно. Денес, дури и банките и осигурителните компании веќе имаат разбирање дека барем дел од нивните работи може да се пренесат во јавниот облак. И никој овде не се плаши од договори со Гугл и Амазон. Според она што го слушнав на конференции во Русија, таму е сè уште покомплицирано, па дури и од гледна точка на санкции или несанкции и некои правни прашања.
Разликата помеѓу стартапите и гигантите
Олег: Разбирам. Патем, каде ви е поинтересно и попријатно да работите: во стартапи или во големи организации?
Антон: Попријатно е, се разбира, во стартапите, бидејќи големите организации... добро, навистина, само материјалот се движи многу тешко. Има свои предности, се разбира. Ако ги погледнете големите организации, тие, на пример, имаат многу повеќе од она што се нарекува различност. Големите компании, едноставно затоа што им требаат многу луѓе или затоа што се работи за некаква организациска култура која се развивала низ годините, се подготвени да вработат различни луѓе. Конкретно овде во Израел на пример во стартапи тешко дека ќе најдеш на пример Арапи, скоро и да ги нема. Во големите организации ова е многу полесно. Но, стартапите растат од некаква културна позадина, во која мнозинството учесници се во основа истите тие бели мажи. Таму постои култура дека треба да се работи напорно, а препорачливо е да се работи 10-12 часа на ден, а тоа исто така не е доволно. Се чини како да ја имаме Москва (т.е. Тел Авив) зад нас, нема каде да се повлечеме и затоа мора да крвариме овде и сега.
Олег: Што е со разликата во пристапот кон DevOps кај малите и големите компании? Односно, ако, на пример, работите за две лица, не мора да поставувате CI/CD за себе, туку да копирате артефакти користејќи SCP.
Антон: Од една страна, да. Од друга страна, денес поставувањето CI/CD не значи дека навистина вршите континуирана испорака. Но, поставувањето некаков цевковод за себе, ако сте компанија од две лица, е многу, многу едноставно. Ако порано требаше некако да се збуните, денес имате многу облак услуги. Напишав YAML и отидовме. Полесно е со ова. Всушност, предизвикот се состои од обраснати стартапи. Оние кои поминале подалеку од 20 луѓе, и тука почнуваат да имаат болки со лупење, бидејќи нема никакви процеси. Порано сè некако функционираше, но сега почнува целиот овој хаос и не е јасно како можеме да ја одржиме оваа поранешна динамика и во исто време да ги спроведеме процесите и да одлучиме кој друг ќе го прави сето ова.
И тогаш започнуваат сите работи „ќе имаме тим на DevOps кој ќе биде одговорен за DevOps“, знаеме каде води тоа во повеќето случаи. Се појавува тесно грло и постепено тие прераснуваат до местото каде што се сега големите компании. Во големите компании проблемот е сосема поинаков, тие веќе немаат ни тесно грло, туку едноставно порта толку моќна што се отвора еднаш дневно, а остатокот од времето таму се акумулира огромна количина ѓубре. И така тие мислат: „Како сега можеме да направиме многу мали порти од оваа порта што може многу полесно да се отворат? Односно, сосема различни проблеми. Стартапите имаат проблем со тоа што „не шмукаат во инка, како да излеземе?“, а големите компании имаат проблем - тие се веќе во инката, тие се веќе во подземното кралство, сега се размислувајќи за тоа како можат да пливаат назад.
Трендот кон зголемување на сложеноста и што да се прави во врска со тоа
Олег: Па, и плусот на техничкиот дел: кога имате малку луѓе, едноставни технологии, треба да знаете некои основни Linux, и тоа е тоа. И при најмало скалирање, треба да научите неколку Кубернети, а тоа изгледа како проблем.
Антон: И ова е несомнено проблем. Имавме конференција пред само два дена, и беше многу забележливо дека скоро сите што кажаа нешто таму спомнаа еден збор: „сложеност“. Ова стана некој вид дефинирачки збор во целиот дискурс на DevOps денес.
Олег: Дали беше вака пред една година?
Антон: Во обидот да направиме сè брзо, динамично, за да ја постигнеме озлогласената флексибилност, ние самите создадовме таква сложеност. Навистина, има многу мали цевководи кои работат одлично поединечно, а потоа се обидуваме да составиме некаква слика за светот од сето ова, и тука одеднаш се појавува сложеноста. Затоа што од сите овие мали цевководи сега градиме еден процес за целата компанија да работи како човечко суштество.
Олег: И кој е одговорот? Како да се справите со оваа сложеност?
Антон: Па, нема одговори, тие се раѓаат во процесот. Мојот извештај беше за една од овие одлуки. Во голема мера, до што води сето ова? Едно време бев заразен со системско размислување, тоа многу се споменува во DevOps. Се заинтересирав, ги читав книгите на Питер Сенге, Расел Акоф, Донела Медоус - луѓе кои едно време некако почнаа да размислуваат системски и, во голема мера, ги истакнаа неговите главни постулати. Една од главните леќи преку кои системското размислување гледа на светот е повратните врски. Со оваа сложеност, сега се појавуваат овие јамки за повратни информации, односно сложеноста станува многу, многу висока, почнуваме да бараме алатки за некако да ја контролираме оваа сложеност, добро, барем. Не велам да го намалите - да го ставите под контрола за да не се расплетува.
Се појавуваат централизирани решенија, дури и Kubernetes е нешто слично. Имате централизирана контролна рамнина, која, во моментот кога ќе ја контролирате, ќе ја контролира целата сложеност на оние услуги што се движат наоколу. Сервисното сито, истата сервисна мрежа, е ист тип на раствор. Велиме: „Имаме многу услуги, ни требаат да можат некако да разговараат меѓу себе, бидејќи не е јасно каде седат и не е јасно дали ќе им одговорат или не, а самите не можат да се справат. . Ајде да го направиме ова сега, во средината ќе вметнеме одреден универзален ум што ќе им каже со кого можат да разговараат и со кого не можат да разговараат и ќе ги заштити ако одеднаш кажат нешто грубо како одговор“. И има многу прашања со ова. Од една страна, ова е извесна неопходност, бидејќи организациите не можат да се справат. Помогнавме на неколку организации да се преселат во храбриот нов свет на Cloud Native во последните неколку години, особено кога станува збор кога компанијата расте, расте и луѓето едноставно се губат. Во средината на сето ова е мал тим од таканаречени DevOps кои треба да напишат илјадници линии YAML за некако да се справат со сето тоа, а сè само се распаѓа.
Cloud Native
Олег: Можеш ли малку да објасниш што е Cloud Native? Бидејќи стана некој вид на звучен збор, сега сите го пишуваат на секој ѕид. Како го гледате?
Антон: Во голема мера, сè започна со појавата на пристапот „платформа како услуга“, односно кога требаше да работиме многу повеќе софтвер и многу повеќе веб-услуги отколку што беше потребно претходно. Сфативме дека веќе не е возможно секоја услуга да ја нудиме одделно, како сакано милениче кое го знаеме по име и се грижиме цел живот, треба да се занимаваме со нив како еден вид стадо. За да го направиме ова, ни треба некаква хомогена платформа на која можеме да го фрлиме овој код и платформата ќе биде доволно паметна за да го опслужува. Автоматски пијалок, накратко, е авто-пијач-авто-хранител за сервисирање.
Пионерите на овој пристап беа Хероку. Тие рекоа дека за да можат овие услуги да ги користат нашите инфраструктури мора и тие да бидат крави. Тоа е, тие мора да имаат одредени квалитети. Вака се појави апликацијата со 12 фактори, која требаше да има што помалку стабилна состојба. Таквата апликација е нужно составена од некој вид гасовод, кој ја проверува неговата компатибилност со платформата. Мора да биде способен да биде отпорен - да знае дека ако нешто тргне наопаку, тогаш нема потреба веднаш да падне. Од друга страна, во извесна смисла, потпирајте се на платформата. Во принцип, тоа е еден вид хибрид. Разберете дека не сте сами, дека постои платформа и мора да ги почитувате нејзините ограничувања. Во голема мера, се започна од таму.
Но, поради некоја причина, овој пристап „платформа како услуга“ не се оправда себеси и ветениот бум не се случи. Тоа е, да, имаше Хероку, а потоа веднаш по нив сите големи момци, исто така, подигнаа аналози: Google App Engine, Amazon - Elastic Beanstalk. Морав многу да работам со компании кои започнаа со ова. Но, во моментот кога ќе направите нешто што оди малку подалеку од она што го дозволува платформата, тоа се претвора во ужасна главоболка. Затоа што почнуваш да налетуваш на ѕидови кои се насекаде. И како што луѓето имаат тенденција да прават, кога ќе наидат на ѕидови, почнуваат да бараат начин да го пресечат ѕидот.
Модерниот Cloud Native порасна оттаму: како да го направите да работи во облак, да користите некои услуги на платформата, но во исто време да обезбедите неверојатна флексибилност во сè што се случува. Постојано балансираме помеѓу флексибилноста и едноставноста. Флексибилноста предизвикува сложеност, а поедноставувањето и создавањето јасна платформа секогаш предизвикува ограничувања. Cloud Native, очигледно, е за наоѓање некаков баланс помеѓу ограничувањата на облак платформата и флексибилноста што ви ја овозможува облакот со неговото автоматско скалирање, а сето тоа има своја цена.
Олег: Веројатно, самата организација мора некако да научи да живее процесно со целата оваа работа.
Антон: Нормално, природно! Сето ова остава отпечаток. Микросервисите исто така важат за ова. Во голема мера, ова е идејата дека имаме мали услуги, мали апликации кои се расфрлани низ облакот и можат да се лоцираат каде било во секое време, и може да има 10 реплики сега, а утре - 1500, сето ова е исто така дел од мајчиниот облак. Идејата дека не сме ограничени со физичките граници на центарот за податоци. Во голема мера, целиот свет е мојот облак, ова е апсолутно прекрасна визија, прекрасен стремеж, но има цена, а оваа цена е сложеност, цената е што, генерално, никој не може да се вклопи во нивната глава што ќе се случи, кога нашата апликација наеднаш ќе порасне од 10 примероци на 1500. Никој не може да го замисли ова, а сите артефакти на скалирање почнуваат да се појавуваат. Ние како луѓе, како оператори, не можеме да направиме ништо друго освен да реагираме на хаосот што се случува. И така почнуваме да размислуваме: „Како можеме да ја изградиме нашата апликација и нашата инфраструктура на таков начин што кога ќе се појават овие артефакти, прво, тие можат да се предвидат, и второ, некако да се справиме со овие артефакти и да продолжиме да функционираме?
Мешање на технички и нетехнички вештини
Олег: Имате извештаи за технички работи, на пример, и има извештаи за лидерство, менаџмент и сето тоа. Дали сте генерално повеќе техничко лице, или сте менаџер, или вашата структура е некако различна?
Антон: Во одреден момент дури почнав да пишувам пост за ова, но сè уште не сум го завршил. Лично сум растргнат помеѓу овие две работи, бидејќи од една страна сакам да разбирам како функционираат работите, сакам да ги сфатам. Кога ќе успеете да решите технички проблем, ова само по себе едноставно ви дава неверојатно чувство за вашите способности, она што се нарекува моментално задоволство, моментална награда, брзање со допамин: „Ох, кул, можам да го направам тоа, решив. ” И тешко е да се откажеш, тешко е да се тргнеш од тоа. И бидејќи ова е таму, продолжувам да правам технички работи. Новите технологии ме возбудуваат: убаво е да се копа во нешто, да се разбере нешто. Поради ова, излегува дека бидејќи постои ова знаење, луѓето сакаат да го купат, а јас продолжувам да го продавам.
Од друга страна, разбирам дека ова е само мал дел од големата слика, работев во индустријата доволно долго и не можам а да не видам дека технологијата е само агол од поголем систем, само една од компонентите . Управував со тимови и разбирам колку е важно да се разгледа како технологиите и алатките комуницираат со луѓето кои ги користат. На крајот, информатичката технологија, всушност секоја технологија, постои за луѓето да ја користат. А создавањето технологии без размислување за тоа кој ги користи е сосема бесмислено. Самата технологија не е воопшто интересна освен ако не размислите за нејзината примена, а апликацијата секогаш се поврзува со луѓе кои некако имаат корист од неа. И затоа, сè околу технологијата исто така многу ме интересира. Чувствувам дека е неопходно да се зборува за ова, разбирам дека без тоа сè навистина го губи своето значење. До тој степен што понекогаш уживам да седам и да се пробивам два или три дена, понекогаш со недели. Можам да се занесам од некој проблем што не можам да го решам, можам да го решам и да добијам неверојатни придобивки од него. Но, тогаш ја кревам главата од тастатурата, гледам наоколу и сфаќам дека нешто се случува наоколу што никако не можам да го игнорирам. И тогаш кодирањето и гужвањето со Линукс ми стануваат сосема неинтересни и неважни, и сакам да почнам да ги решавам проблемите на друго ниво, на човечко ниво.
Како брзо да се разбере DevOps
Олег: Слушајте, дали имате некој совет за луѓето кои моментално се занимаваат со инженерство и истовремено учат практики на DevOps? Како да го натрупате сето тоа во себе и по кој редослед? Релативно кажано, како можете да ја планирате вашата кариера за да станете поуспешни за кратко време?
Антон: Ех... Па, нема универзален совет, повторно, од мое искуство. Доста долго време, веројатно првите 10 години од кариерата, бев незадоволен од моето место. Го барав она што не ми се допаѓа, се фокусирав на тоа, барав што ќе ми биде поинтересно да правам. Но, во голема мера, тој не направи ништо за тоа. Главниот совет е... Во кој момент мислам дека мојата кариера тргна во нагорна линија? Во моментот кога почнав да зборувам за работи кои ме интересираа. Областа на техничко знаење, дури и не само техничко знаење, генерално самата област на информатичката технологија е многу широка, односно можеш да бидеш техничар: развивач, тестер, интегратор и системски администратор - сето тоа се различни работи, секој може да ја најде својата ниша таму. Не сакате да бидете комплетен техничар, дали сте заинтересирани и за технички и за деловни работи? Вклучете се во работата на производи и проекти. Има многу ниши, пронајдете ја вашата ниша што ќе ви биде интересна.
Деновиве многу се зборува за професионалци во форма на Т. Треба да разберете каде е ногата на вашиот Т, изберете една работа и почнете да копате на ова место. Во моментот кога ќе копате, ќе се откријат неверојатни длабочини. Но, можете да копате насекаде. И јас сум добро свесен дека има многу области кои не сум ги ископал длабоко затоа што се обидов да погледнам и сфатив дека тоа не е за мене. Но, онаму каде што ве интересира да копате, продолжете да копате, и тука е многу важно да се зборува за тоа. Мислам, повторно разбирам дека ова не е за секого. Но, дури и овде секој има различни форми на изразување: за некои можеби е погодно да пишувате блогови, но ако не можете да пишувате литературни и смешни блогови, само пишувајте технички блогови, објавувајте Gists на GitHub. Ако решивте некој проблем, објавете го.
Во голема мера, денес развојот на кариерата се случува преку споделување. Има причина зошто споделувањето знаење е толку важна вредност во DevOps. Сите други имаат корист од ова, а вие самите секогаш имате корист ако го споделите вашето знаење. Секое лице кое го има отворено својот код знае совршено добро колку треба да го чешлате кодот, како треба да размислувате поинаку во моментот кога ќе го дадете на некој друг и разбирате дека некој друг ќе го користи. Веднаш влегуваат во игра истите социотехнички работи за кои зборував. Почнувате да мислите дека ова не е само код, туку код што друг ќе го прочита, можеби ќе сака да го смени, ќе треба да разбере што прави овој код. И кога ќе се појават овие интеракции, вие веќе почнувате да комуницирате со другите луѓе во вашиот мозок. И кариерата на една личност се развива само преку интеракција со други луѓе. Во голема мера, што е кариера? Кариерата значи дека станувам корисен за повеќе луѓе, корисен и потребен. Стекнувам знаење кое е потребно и корисно за повеќе луѓе. За да го направите ова, треба да разберете што сакаат овие луѓе и што им треба. Нешто како ова. Сè секогаш се сведува на луѓето.
Олег: Да речеме дека сме многу кул, правиме DevOps, секакви нови практики и така натаму. Но, има такви кои го знаат и почитуваат ова, а потоа ги има и сите други. И замисли да работиш тимски во некои, особено во некоја голема компанија, а таму е уште... да внимаваме, не се многу познати и не се многу почитувани. Дали постојат начини да се започне со спроведување на сите овие идеи? Ако не сте лидер. Јасно е дека ако сте менаџер, можете едноставно да кажете: „Ќе го спроведеме утре“. Што се случува ако сте обичен човек и сакате да се подобрите?
Антон: Прво, не е неопходно да функционира ако како шеф кажете: „Ќе го спроведеме утре“. Луѓето ќе извршуваат некои задачи, но тоа не значи дека од никаде ќе се појави длабоко разбирање зошто се спроведува. И тогаш, никој не сака никакви промени, особено кога ќе му кажат: „Треба да се промениш“.
Олег: Па што да правам?
Антон: Па, погледнете, јас бев на ова место и бев вклучен во спроведувањето на таквите процеси, всушност, одоздола, само како тимски работник, а потоа веќе како тим лидер. Единствениот пристап кој функционира е пристапот на дилерот на дрога. Ова е она што јас го нарекувам „соработка базирана на услуги“, односно соработка ориентирана кон услуги. Во голема мера, знаете дека имате некои луѓе околу вас кои можете да ги перцепирате како ваши клиенти. Ние правиме нешто, некој друг го користи. Во наједноставното сценарио, за кое еднаш зборуваше Agile: еве јас сум развивач, имам клиент и соодветно, морам да разберам што сака мојот клиент за ефикасно да развијам софтвер.
Во голема компанија често немам директна интеракција со клиентот, со корисникот. Но, има луѓе околу мене. На пример, пишувам библиотека - други луѓе се интегрираат со неа, пишувам некој вид на заднина - имам програмери од предниот дел кои треба да разговараат со неа, пишувам код - имам тестери кои или пишуваат тестови за мене, или, пак им давам верзии за да имаат што да тестираат. И во голема мера, само треба да размислите: „Еве јас сум давател на услуги, имам клиенти. Сè ќе функционира најдобро ако ги израдувам моите клиенти. Односно, ако моите клиенти се среќни, тогаш и јас ќе бидам среќен. Очигледно, ќе заработам, прво, одредена репутација за себе, ќе заработам добар став, ќе добијам позитивен фидбек“. И да се вратам на пристапот на дилерите на дрога, сакам овие клиенти да ми се вратат за повеќе од истото.
Односно, ако мислам дека некој пристап е правилен, на пример, континуирана интеграција со тестови... Има програмери на кои денес, на пример, им е тешко да си ја тестираат работата. Треба да се погрижиме тие навистина да не размислуваат премногу за тоа, за да ги добијат тие проверки што е можно полесно. Денес изгледа прилично тривијално, пред 10 години воопшто не беше тривијално: во моментот кога го турнав мојот код, за сè автоматски да се изгради некаде, да се распореди и само ако има грешка, ќе добијам порака, Во меѓувреме, можев мирно да одам да пијам кафе и да не размислувам за тоа дека сега треба да ја пуштам компилацијата на компјутерот за да ги имам сите потребни алатки, бидејќи и ова е главоболка. Односно, ако ја намалите количината на главоболки, луѓето се закачуваат на неа. Сите го гледаме: во моментот кога имате добро функционален гасовод, многу брзо секој што го користи веќе не може да го замисли животот без него. Ако сакам да сменам нешто, треба да создадам процес од кој луѓето ќе имаат одредена емоционална зависност.
Олег: Добро. Многу луѓе се надеваат дека некој крал, голем лидер или нешто друго ќе дојде и ќе им каже како да живеат, а после тоа сите, се разбира, ќе се преселат во храбар нов свет со DevOps или нешто друго. Дали е потребен таков крал?
Антон: Не, крал кој ќе ви каже како да живеете дефинитивно не е потребен. Шеф кој е подготвен да ги слуша своите вработени, подготвен да им верува и подготвен да ги поддржи да ја вршат работата на начин на кој се чувствуваат најудобно и најправилно за нив? Да, таква личност е неопходна, бидејќи без неа тоа ќе биде само борба. И борбата на подредените против нивните претпоставени не завршува со ништо добро. Како резултат на тоа, дефинитивно ќе заврши лошо за една личност, или за шефот или за подредените.
Но, проблемот е што е многу тешко да им се каже на луѓето што да прават, а што не. Тие завршуваат да го прават она на што ги наведува нивното културно потекло, его или моментална емоционална состојба.
Најкорисните практики и технологии од светот на DevOps
Олег: Патем, сега се проповедаат огромен број на секакви практики: има пристапи од Google, има пристапи од Нетфликс, од секакви говорници од конференции. Кажи ми, кои практики ви се најкорисни?
Антон: Проблемот со повеќето организации, без разлика колку се големи или мали (стартапите страдаат повеќе од ова), е тоа што немаат видливост на процесите - разбирање за тоа како генерално работиме, како испорачуваме софтвер, каде работите се заглавуваат. Обично предлагам вежба која доаѓа од пристапот на посно управување - наречено мапирање на протокот на вредност. Мапирање на протокот на испорачаната вредност. Ова бара одредена подготвеност да се соберат во една просторија главните играчи во организацијата, сите луѓе кои некако се вклучени во процесот на испорака: оние кои ги одредуваат потребните промени, производи, проекти, програмери, тестери, системски администратори, дури и луѓе за продажба. кои работат со клиенти. Земете ги сите заедно и разберете како се случува промена во софтверот, по кој пат обично оди.
Ова изгледа сосема тривијално: што има таму? Некој го смислил, некој го шифрирал, имаме цевковод, истрча и истрча. Па, да, знаеме дека нашата изградба овде одзема многу време, да, ние ќе одлучиме за тоа. Па, да, знаеме дека програмерите сега не можат да компајлираат на нивните компјутери, бидејќи имаат Java, бара многу меморија, знаеме и за ова, ќе одлучиме. И јас често доаѓам во организации, тие велат:
- Ова е местото каде што треба да го автоматизираме ова, да го решиме ова.
- Дали сте сигурни дека ова е она со што треба да започнете? Како го знаеш ова?
- Па, не знаеме со сигурност, но чувствуваме дека боли таму.
Постои , што вели дека во голема мера, решавањето на прашањето на кое било место кое не е ограничување не е ништо решавање, само ќе го усложни проблемот. Она што на многумина им недостига е концептот каде се заглавуваат работите и како течат.
Понекогаш наеднаш собираш различни луѓе, еден вели:
- Еве, во овој момент објавувањето оди таму на одобрување.
А другиот вели:
- Не, кај нас не е така, не ни оди. Овде ја чекаме околината за тестови на оптоварување.
Или, на пример, тестерите велат:
- Овде на ова место обично сето тоа го правиме со раце.
И програмерите им велат:
- Па, имаме автоматизиран процес за ова. Зошто не го користите?
И тестерите велат:
- Не знаевме што е тоа.
Секој тим го гледа само своето парче, а никој не ја гледа целата слика - тоа е она што често влијае на нашата способност за ефективно воведување софтвер многу повеќе од присуството или отсуството на алатка. Ова се работите. Вреди да се започне со мапирање на процеси. Јасно е дека ако компанијата моментално нема CI/CD, тоа е веќе минато. Јасно е дека и ова треба да се изгради. Но, прво вреди да се одговори на прашањето колку да се инвестира во тоа, какви проблеми ќе реши. Ова исто така бара луѓе кои разбираат како да го направат тоа правилно.
Олег: Од техничка гледна точка, на кои технологии вреди да се обрне внимание? Јасно е дека повеќе не можеме да зборуваме за едноставни CI/CD. Кои кул нови технологии вреди да се проверат?
Антон: Прво, на сите им е апсолутно очигледно дека контејнерите победиле. И затоа, ако некој сè уште не прави контејнери, дефинитивно треба да го погледнете и да го погледнете што е можно поскоро, бидејќи движењето оди во оваа насока, а големите компании веќе разбираат дека треба да го завиткаат својот софтвер во контејнери. . Па, на ниво на платформа, Kubernetes победи: не е важно дали е во облакот или не - ние ќе понудиме кутија со Kubernetes на клиентите. Сега VMware објави дека ќе имаат Kubernetes директно на хипервизорот. Се е јасно, Гугл победи. Што, генерално, не беше изненадување за никого.
Олег: Google победи?
Антон: Па, ако погледнеме наназад пред само неколку години, сè уште не беше многу јасно дали Swarm или Kubernetes ќе бидат убиени и дали Docker ќе биде убиен. Докер е убиен, сосема очигледно. Односно, сите се навлекоа заедно, а Мајкрософт и Амазон исто така помогнаа - „ајде сите заедно да го убиеме Докер“. Убиен Докер! Но, во голема мера, самите Докер беа виновни. Дали очекуваа дека ќе дојдат, ќе го скршат калапот за сите, нема да сакаат да продаваат на никого и ќе ги победат сите наеднаш и веднаш ќе ги совладаат Гугл, Мајкрософт и Амазон? Имаше многу мали шанси ова да се случи. Тие очигледно не можеле да најдат со кого да се дружат. Кога не се дружите со никого, на крајот ќе бидете отфрлени. И така се случи.
Па еве го. Затоа, треба да ги погледнете контејнерите. Контејнерите и оркестрацијата полека стануваат секојдневие денес. Односно, сега извештаите на конференциите се „Никогаш не е доцна да се започне со Кубернетес, дури и ако сте пензионер“. Значи потребно е. И многу интересни работи сега почнуваат да се случуваат околу Кубернетес. Бидејќи една од одличните карактеристики на Kubernetes е, во голема мера, создавањето на некој вид универзално API што ни овозможува да опишеме сè што се случува во нашата инфраструктура. Во текот на изминатата година, видовме обиди да се завиткаат многу други работи околу ова API. Еве го сервисното сито - еден од овие обиди, скоро сите имплементации на сервисното сито што постојат сега, тие во извесна смисла велат: „Тука ќе го прошириме API, ќе додадеме интелигенција, ќе опишеме објекти надвор од Кубернетес, но ќе читаме предмети од Кубернетс и така натаму како да знаеме што да правиме“.
Друг таков пример е она што се случува сега со фондацијата за континуирана испорака, која беше организирана пред околу година и половина, повторно, ова е Google, ова е CloudBees, GitLab. Постои проект на Google Tekton, неговата главна идеја е создавање на еден вид универзален API за опишување на процесот на континуирана испорака. Во голема мера, тие се обидуваат сето тоа да го поделат на одредени објекти кои мора да бидат присутни во системот за континуирана интеграција / континуирана испорака и на некој начин да овозможат да се запишат овие работи во Kubernetes, за подоцна да има секакви различни компоненти кои можат да ги прочитаат овие дефиниции и да решат што да прават со нив. Истите работи се случуваат и со сервисните сита, за ова зборував во мојот . Мајкрософт сега се обидува да направи спецификации за тоа што треба да прави сервисното сито, таканаречениот SMI Spec. Со идејата дека секоја имплементација на сервисното сито ќе може да изврши се што е напишано во оваа специфика плус нешто друго.
Ова е причината зошто Кубернетес победи. Во моментот кога стануваш платформа за понатамошни иновации, многу е тешко да те исфрлиш некаде подоцна, затоа што веќе порасна на него, сега да го фрлиш Кубернетес е да го исфрлиш бебето со водата за капење.
Кои извештаи вреди да се посетуваат?
Олег: Какви извештаи одите кај себе, што ви е интересно?
Антон: Прво, ако има некоја нова технолошка карактеристика, гаџет што едноставно немав време да се видам, а има говорник кој може јасно да зборува за тоа, тогаш мислам дека ова е генерално дива предност, бидејќи наместо сега читај, и копај, и, можеби, со тешкотии да разбереш, можеш да дојдеш и да слушаш за половина час како што ти кажува некој човек. Повторно, ова бара одредена вештина и желба да може да се зборува за технологија. И јас разбирам дека ова исто така не доаѓа од никаде, треба да работите на тоа. И мене ми требаше многу време. Инаку, за ова многу ми помогна фактот што се занимавам со техничка настава. Кога имаш клас пред тебе, треба да им објасниш нешто на луѓето, а сфаќаш дека како и да објаснуваш, тие се глупави - тогаш сфаќаш дека очигледно проблемот е во тоа како објаснуваш, а не во фактот дека луѓето се глупави.
Олег: Каква техничка настава? Што правиш?
Антон: Веќе околу 7-8 години предавам чисто технички дисциплини. Започна со тоа што една година учам работи како Мејвен и скриптирање школки. Бидејќи работев многу тесно со Џенкинс и го знаев тоа длабоко, ги научив луѓето како да работат со Џенкинс и администрацијата. Во последниве години - сè што е поврзано со мајчин облак: Кубернети, контејнери и сè околу него. Наскоро одам во Лондон да направам мастер клас на Истио. Ова не е главниот дел од мојата активност, но околу еднаш месечно или два спроведувам мастер класи.
Олег: Одите главно по извештајот, темата или личноста?
Антон: Ако знам дека говорникот е добар, тогаш одам кај личноста едноставно затоа што сепак ми е многу важно да научам од другите луѓе како да зборувам добро. Учењето е секогаш важно. Ако има тема, но не го познавам говорникот, тогаш ќе одам да ја гледам, но исто како и обично, како да одам на стенд-ап: ги гледав првите 10-15 минути, не не ми се допадна и си замина. Или има звучници на кои навистина ќе одам сепак, затоа што секогаш кажуваат интересни работи, дури знаат да покажат работи што ги знаете од нивен агол, тоа е едноставно и за вас го врти целото прашање од нов агол. . Од оние што ми се допаѓаат во последно време... Прво, тука е Сајмон Вардли - консултант, тој има свој трик со цртање мапи, тој користи мапи за да објасни како компаниите можат правилно да ја градат својата стратегија, некогаш бил некаков ... потоа има CTO, извршен директор на стартапи, тој зборува многу за ова, за технологијата. Патем, тој постојано се залага за без сервери и вели дека оние кои денес не работат без сервер имаат големи проблеми.
Олег: Ова е другарот кој ? Тоа го направи во форма на објави. Невообичаен формат.
Антон: Тој навистина зборува на многу смешен начин. Најмногу се сеќавам на неговите предавања во изминатите 2-3 години. Па, еве го Џон Вилис, кој дојде на DevOops минатата година - едноставно затоа што тој . Има некаков проблем со него, бидејќи многу зборува за американската реалност, работи кои понекогаш едноставно не важат ниту за руската, ниту за израелската реалност. Сега имаат некаква војна со некои одбори за одобрување промени, за кои постојано зборуваат. Ова, очигледно, е одредена работа што постои во американските претпријатија, постои процес за спроведување и одобрување промени во ИТ;
Олег: Но, ние го немаме тоа - дури и не разбирам за што зборувате сега.
Антон: Ниту јас навистина не разбирам ова не се случува ниту во Израел. И таму зборуваат за тоа. Ако ги слушате сите овие другари, како ДОРА, која , и тие пишуваат многу за ова. Во принцип, мислам дека луѓето зборуваат за некој проблем што го имаат само тие, а тоа воопшто не ви е интересно.
Олег: Бевте на претходниот DevOops, на кои разговори вреди да одите и да ги прегледате снимките?
Антон: Види . Малку ме интересира темата - оди.
Олег: Има некој Антон Вајс таму, мислам. Веројатно вреди да се погледне.
Антон: Не, не одете на ова, досадно е :)
Олег: Добро, ви благодарам многу. Беше кул! Гледам дека веќе сте испратиле труд на следната конференција, па се гледаме на следниот DevOops!
Конференција ќе се одржи од 29 до 30 април, овој пат во Москва. Во соопштението ја опишавме суштината на конференцијата за Хабре . Програмата активно се формира (има уште многу месеци до конференцијата), но првите говорници веќе се . Таму можеш .
Извор: www.habr.com
