Константин Спиров е част от компанията VMware България вече 11-та година. Там той стартира кариерата си на Senior Engineer в екипа на vRealize Orchestrator. След повишението си като Staff Engineer, се превръща един от основателите на продукта „Evo Rack”, който днес е основата на VMware Cloud Foundation. В момента Константин е софтуерен архитект във VMware Cloud on AWS.

Константин, завършили сте Националната природо-математическа гимназия, след което и ФМИ в Софийски университет. Как се породи интересът Ви към технологиите?

Аз съм типичен представител на поколението, което се запозна с компютрите в средата на 80-те години. Както много други, първо започнах с 8-битовите компютри, после преминах към 16-битовите. В гимназията се подготвях за олимпиади по Информатика и влязох в университета чрез състезателно програмиране. Това беше времето, когато още нямаше Интернет в България. Ползвахме други средства за комуникация, наречени BBS-и (бюлетин-борд системи). Това бяха малки сървърни компютри, които обслужваха потребители по телефонната линия. Аз бях последният системен оператор на първия български BBS, Микроком (разполагахме с цели две телефона, при това денонощни и  без дуплекс). В тази среда се оказах и основател на първия български e-zine (електронно списание). То се разменяше под формата на файлове между различните участници в мрежата FidoNet. От 1993-та година започнах да си изкарвам хляба с програмиране. 

Сега, като се замисля, ми е странно, че когато аз съм писал код, голяма част от днешните ми колеги все още не са били родени. Но в такива моменти се сещам за думите на Боб Мартин (Uncle Bob), че въпреки бруталната разлика при смяната на технологиите, основните принципи при разработка на софтуерните системи си остават същите. За мен е много окуражаващо да наблюдавам професионалното израстване на част от по-младите ми колеги, при което те преоткриват за себе си същите проблеми и решения, които аз самият съм налучквал преди 3 десетилетия.  

Работите като Staff Engineer във VMware и сте в компанията вече 11 години. Бихте ли ни разказали повече за Вашата позиция и за Вашия кариерен път? 

Докато бях в университета започнах работа в стартъп и останах там около 15 години. Платформата, която разработвахме, даваше възможност за бърза обработка на митнически документи. Движихме се преди Enterprise Java, и в крачка си измисляхме сами доста на брой подобни технологии. Но “”not invented here” синдрома ме притесняваше, затова въпреки успешния стартъп, взех трудното решение да напусна и да си сверя часовника с индустрията. В този момент разработената от нас система беше внедрена в повече от 50 държави по света.

Една година работих в чужбина и след това бях привлечен във VMware. Офисът на компанията беше  на 5 минути пеша от дома ми, в сграда на ул. „Г.М. Димитров“. Така преди 11 години започнах кариерата си като Senior Engineer в екипа на vRealize Orchestrator. Проектът започна от купен стартъп в Швейцария, впоследствие успяхме да пренесем цялата разработка и управление на продукта в България. Успешно „отвързахме“ ядрото от различни остарели и изоставени технологии (например MBеan, Struts, и дори целия JBoss), преминахме през сериозни одити на сигурността, вкарахме поддръжка за модерни стандарти за удостоверяване и упълномощаване. Оркестрацията често играе ролята на „тел“, усукана около различни софтуерни системи, които не си взаимодействат по достатъчно кохерентен начин. Времето, прекарано в анализ на стабилността (и нестабилността) на различните интеграции засили  интереса ми към софтуерно дефинирания център за данни и начините, по които трябва да бъде подготвян и поддържан целия софтуерен стек.

След повишението ми към Staff Engineer, станах един от основателите на продукта „Evo Rack”, който днес е основата на VMware Cloud Foundation. Първоначално се разработваше като конвергентно инфраструктурно решение. Ще обясня какво е това с една аналогия – когато си закупите нов ноутбук и го отворите за първи път, той вече е почти инсталиран,  вие допълвате само минимално количество информация като името си и мрежовите настройки. След това ноутбукът е готов. По същия начин, конвергентните решения дават възможност потребителят да си закупи цели ракове заедно със сървърите и суичовете и да му бъде предписано как точно да свърже мрежата в Leaf/Spine топология. След това с минимална първоначална конфигурация, чрез включване на ноутбук на един от сървърите на рака и бързи конфигурационни стъпки, потребителят получава целия стек на VMware – всичките взаимодействащи си продукти. Тъй като се движехме на гребена на вълната, решихме доста нови проблеми в оркестрацията. Това ми даде възможност да се сдобия и с първите си три патента. Получих и промоция в Staff Engineer II.

Днес работя в организацията за облачни решения.  От края на 2016 година софтуерно дефинирания център за данни на VMware е достъпен инфраструктурата на AWS, в днешни дни и  в почти всички големи облачни доставчици – от Google до Alibaba Cloud. Екипът в който работя, много бързо се разрасна, имаше моменти, когато почти всеки ден имах интервюта в календара си, и в момента продължаваме да наемаме нови хора.

Разкажете ни за прехода от Software Engineer към Staff Engineer – за какъв период от време се стига до тази позиция, през какви етапи на развитие се преминава?

На този въпрос има два отговора – кратък и дълъг. Краткият e – “не знам”. В повечето компании от Силициевата долина няма очакване, че програмистите трябва задължително да се стремят към позицията на Staff Engineer.

А сега е време за дългият ми отговор – когато преминах от стартъпа в голяма компания, едно от притесненията ми беше, че  западното „корпоративно мислене“ често стресира и противопоставя хората. Трудно е, ако служителите биват карани непрекъснато да се издигат по кариерната стълбица под благовидното оправание за „непрекъснато усъвършенстване”. В една пирамидална структура това е практически невъзможно. Много хора нямат големи кариерни амбиции и не желаят някой непрекъснато да ги убеждава, че тяхната кариера е едва ли не каузата на живота им. В културата на VMware този проблем е решен и то по доста естествен начин. От всеки програмист, индивидуален контрибутор, се очаква да надобрява в професията си през годините, докато не стигне Senior позиция. Но достигне ли ниво Senior MTS,(по нашенски „майстор в занаята“), може да си остане на тази позиция и до пенсия, стига това да го удовлетворява. 

За тези, които имат възможност и мотивация да продължат нататък, съществуват два варианта за развитие. Единият е мениджърската стълбица. Тя е за тези, които притежават изключително добри организационни умения. В кръга на шегата, от мениджърите ще се очаква да останат със сърце на програмист, но скрито в буркан в някое дълбоко подземие. Имам и доста колеги, които тръгнаха по този път, но бързо се отказаха, най-вече, защото не им остава време да програмират. Важно уточнение – да станеш мениджър не означава да престанеш да се занимаваш с технологии. От мениджъра се очаква не само да колаборира добре с техническия лидер и архитекта, но когато има нужда да може да ги замества в някои срещи, да намалява тежестта върху тях.  Добрият мениджър служи на екипа си, а не обратното.

Добрият мениджър служи на екипа си, а не обратното.

Другият вариант за развитие е израстване по техническата стълбица и там са staff позициите.  За хора като мен, които държат на личния си принос в проектите (както в архитектурата, така и в дълбочина), това е чудесен вариант.  Аз също имам начини да намирам хора, които да ми помагат, но при всеки проект водеща е техническата кауза, а не организационната структура. Нямам точна рецепта как се става Staff, но мога да дам насока. В една голяма организация разликата между правилното и грешното техническо решение може да струва изключително скъпо. От една страна, трябва да покажете с професионалното си поведение, че имате здрав разум – не само че мечтаете, но че може да се разчита на вас,  че спазвате обещанията си. Но другата страна, която не се подразбира, е, че е важно да изследвате областите, които не са очевидни за тези покрай вас, които нямат време да инвестират в техническата дълбочина. В тази дълбочина трябва да търсите подводни камъни и да откривате неочаквани решения. Успявате ли да правите и двете неща, мога да ви уверя че сте на една крачка от Staff.

Какъв опит имате с Java?

Така се случи в кариерата ми, че от 1996-та, та чак до днес се занимавам с проекти, основно писани на Java. Имам достатъчно задълбочен поглед в някои части на платформата и това доста ми помага в работата.  През годините Java се развиваше заедно с нас. Затова е като огледало на всичките проблеми и парадигми, през които премина индустрията.  В отделни случаи става въпрос дори за въртене на 360 градуса (макар в спирала, не в затворен кръг), помислете си само за Project Loom и всички изоставени API, които той ще съживи. Понякога, за да освежа знанията си и да получа алтернативен поглед, издирвам колегите, които програмират на Java с неохота, защото харесват повече други платформи и езици. Така  научавах пръв за различни „еретични“ фреймуърци като Java Poet или Lоmbok.

Като Staff Engineer не просто си сътрудничите, но и подпомагате сътрудничеството между бизнес лидерите и техническите екипи. Какви правила следвате, за да поддържате добрата комуникация?

Софтуерният архитект трябва да бъде авторитет относно нефункционалните изисквания на системата и да се грижи за тяхната правилна идентификация. Няма система, в която всички “illity”-та да бъдат удовлетворени. Това е практически невъзможно. Архитектурата трябва да отговаря на специфични характеристики на продукта. Не съществува и чиста, и стерилна архитектура, винаги става въпрос за диалог и компромис, който архитектът трябва да подпомогне. Софтуерният архитект трябва да бъде и медиатор. Грегор Хоп го оприличава на някой, който постоянно пътува в асансьора на висока сграда, като минава през всичките етажи: от подземието, където бучат сървърите, до мансардата, от където се виждат облаците. В една организация, платформата, продуктовите екипи и групата, която комуникира с клиентите могат да са на различни етажи. Ако този асансьор не съществува, различите етажи на сградата ще заживеят в собствен ритъм и собствен затворен свят. “Неработещият асансьор” може да бъде видян дори в кода на програмните продукти, в частите, пълни с локална оптимизация. Това е пример, в който законът на Конуей ще се прояви в тъмната си страна.

Софтуерният архитект трябва да бъде и медиатор.

Софтуерната архитектура трябва да дава насока, която може да спести на екипите проблеми като затъване в блатото на слабашкия Scrum, за който говори Мартин Фолуър, или пък мениджърския ад, в който различните екипи си подхвърлят горещия картоф един на друг и никой не го желае. Попитахте за комуникация, каква може да бъде комуникацията, ако сме си позволили да стигнем до подобна ситуация? Ние не искаме да подпомагаме подобна комуникация. Ние се стремим  да я предотвратим. 

Проектите трябва да имат изчистена, ясна крайна цел, но дори при поставянето на целта прагматичността в никакъв случай не е порок. За пример мога да дам езерото с костенурките  в кампуса на VMware в Пало Алто, Калифорня. Архитектът, който преди години е правил ландшафтния дизайн на това място, е можел да изравни всичко със земята с булдозери, да засипе дупките с инертен материал, да отсече всички дървета и да започне наново. Вместо това, той е решил да запази много от растенията и естествените форми на терена включително и едно езерце, където по първоначални планове е трябвало да има брокатен шаран. Планът обаче се променя, когато наш колега намира самозаселила се костенурка в един контейнер наблизо. Сега на алеята в кампуса има табела „Внимавайте! Преминават костенурки.”, а в езерото живеят 14 броя от тях. От време на време дори си гледам на web камера, кампусът на VMware един от най-красивите в Силициевата долина. Та така така трябва да се постъпва и при създаването на софтуерна архитектура – не само чрез  намиране на крайна цел, но и с отчитане на вече съществуващите дадености, достижения и с очакването, че промяна винаги ще има и трябва да сме готови да реагираме на нея.  

С какви предизвикателства се сблъсква един Java разработчик в ежедневието си? Какъв технологичен стек използвате? По какви проекти работите в момента? 

Въпросът Ви е относно специфичните проблеми на Java разработчиците, нещата се промениха много през последните години. Слава Богу, вече не ми се налага да се боря с йерархични classloader-и и EAR файлове. За нови версии чакаме по 6 месеца, а не 5 години, както с Java 7.  

Много колеги по различни причини са „заседнали“ със стари версии на JDK и това едно от най-честите оплаквания. При нас повечето проекти са под JDK 11 и в момента сме в процес на преход към на JDK 17, последната LTS версия. Имаме добри pipeline-и и това ни дава сигурност, че евентуалните несъвместимости ще бъдат открити навреме.  

Производителността на Java е често споменавана от начинаещите колеги, които в последствие обикновено откриват, че проблемите им идват от лош код или лош системен дизайн, а не от платформата. Все пак е истина, че въпреки всички оптимизации, HotSpot не може да достигне компилирания код на C++, тук е добре да се следи развитието на Spring Native за GraalVM.

Друг „традиционен“ проблем в Java света е по-трудната инкрементална синхронизация по време на разработка. Java решенията работят с по-тежък стек, услугите се рестартират по-бавно.  Ако работя с Node.js или Python, аз мога да вляза в сървъра, който тествам и директно да „пипна“ там, без да рестартирам нищо, в Java това е невъзможно, без да се използват екзотични решения като JRebel или Spring Boot Devtools. Поголовната „докеризация“ и увеличаване броя на услугите, които разработваме в рамките на продуктите усложни още картината, но две неща са ясни. Първо, екипите с по-добра култура на автоматизирано тестване на кода са много по-продуктивни. Второ, цената за неправилно поставените архитектурни демаркационни линии се вижда точно при тестването.

Относно технологичния стек – това е важен въпрос, но в никакъв случай не бива да се надценява. Нека отново дам строителен пример. Тухлите или изолацията от добър производител не правят задължително една къща стабилна и здрава. В момента платформата ни се състои от множество малки услуги, базирани на Spring Boot. Контейнерите ни отиват в Kubernetes. Скелетът на проектите ни се съставя от собствен engine за шаблони. Така може да се започне от нулата малък сървис, който да се интегрира с цялостния workload,  без да е необходимо да се минават от начало всички стъпки за интеграция с решенията ни за мониторинг, локализация, кеш, телеметрия, брокера на събщения, базата от данни. За разлика от други подобни решения, имаме възможност и за обновление на шаблона във вече съществуващите услуги.

От къде черпите нова информация за случващото се в света на технологиите – подкасти, книги, медии и прочие?

За новини използвам Slashdot и InfoWorld. Чета всичко на Мартин Фаулър (остана ни само четенето, след като той обяви, че изпитва паника всеки път преди да води лекция и повече няма да се явява публично). 

Във VMware всеки разполага със собствен бюджет за образование, който може да употреби, както желае. С този бюджет ходя на конференции по свой избор, а  последното, за което го използвах, беше един bootcamp с шаблони за дистрибутирани данни на Крис Ричърдсън. 

Тъй  като напоследък водя доста интервюта за работа, започнах да научавам много и от колегите, които интервюирам.  

Какъв съвет бихте дали на програмистите, които тепърва стартират своята кариера и биха искали да достигнат Вашето ниво?

Преди всичко нека открият своя кариерен път за развитие. От една страна всеки от нас трябва да се занимава с нещо, което да удовлетворява жаждата му за смисъл. Колкото и да иска бояджията да рисува картини, ако клиентът очаква от него просто да боядиса стените в бяло, той ще трябва да реши дали да си смени професията или не. Не бива да пренебрегват професионалното си самоуважение. Един майстор може да направи компромис и да не спази всички технологични правила, но има компромиси, които в никой случай не трябва да прави.  Бих дал съвет на младите професионалисти  да си открият този баланс, който ще ги кара едновременно да имат успешен живот и успешна кариера.

Как се справяте с work-life баланса? Имате ли конкретни правила, които следвате?

Много ми харесва аналогията, дадена от нашият бивш изпълнителен директор Пат Гелсингер (сега изпълнителен директор на Интел) който нарича този феномен не „баланс“, а „жонглиране“ между три неща: работата, личния живот и вярата. Защо жонглиране, а не баланс: има моменти, когато едната страна в живота ни се нуждае повече от внимание и трябва да направим компромис с останалите. Балансът предполага нещо статично, а жонгльорът може и да залитне малко, но това е част от играта.

За всеки човек трудностите са различни. Моето лично предизвикателство е голямото ми любопитство. Когато работех в стартъпа, проблемът ми беше, че често нямах достатъчно информация, за да удовлетворя любопитството си, а сега е обратното, заобиколен съм от множество интересни проекти, всеки екип желае да демонстрира и покаже нещо интересно. Важен е опитът и разумната преценка.

В този смисъл много е важно умението да се казва „не” – както на себе си, така и на другите.  Да се казва „не”, когато те канят на срещи, където си излишен. Да се казва „не” на работата. Необходимостта да се поставят граници е важна, както в софтуерната архитектура, така и в личния живот.