ИТ фирми и пракси во Скопје

[zmej gorjanin]

Зошто би умирала кај големите фирми? Ако имаш потреба од специјалисти, ќе мора да најдеш специјалисти. Пример, во случајот што го опиша @zmej gorjanin , ако фирмата секој ден има devOps обврски, сигурно ќе вработи човек за тоа. Ако има devOps обврски неколку пати месечно, тогаш е нормално некој од BE инженерите да ги заврши.

Да се намалат трошкови. Еден програмер по проект.

 

[Amaterasu]

Да се намалат трошкови. Еден програмер по проект.

Тоа може ако девелоперот има време. Нормално е во криза луѓето што претходно работеле по 2-3 саати да пробаат да им дадат плус таскови, ама ако некој нема време, нема време. Не може наеднаш да почне дупло да работи

 

[Inglourious Basterd]

Зошто би умирала кај големите фирми? Ако имаш потреба од специјалисти, ќе мора да најдеш специјалисти. Пример, во случајот што го опиша @zmej gorjanin , ако фирмата секој ден има devOps обврски, сигурно ќе вработи човек за тоа. Ако има devOps обврски неколку пати месечно, тогаш е нормално некој од BE инженерите да ги заврши.

Затоа што 99% од времето на специјалистите од ДевОпс наместо во креирање на автоматизација на процесот, поминува во промена на параметри и редеплојмент на веќе постоечки ствари.

Тоа не бара никаква специјализација, туку може да го заврши буквално секој. Било кој рандом член од форумов да го собереме, ќе може да го научиме да го прави тоа за недела дена. Зошто тогаш инженерите не би го правеле кога им е потребно?

Истото важи и за day to day работата и на другите специјалности. Луѓето го имаат скилсетот, ама многу ретко го користат. Најчесто трошат време на тривијалности. И тоа ќе се искорени додека не влезат нови евтини пари во индустријата. Ако влезат. Ако не, исто како телекомите. Медениот месец заврши, работите ќе се стабилизираат.

 

[Amaterasu]

Затоа што 99% од времето на специјалистите од ДевОпс наместо во креирање на автоматизација на процесот, поминува во промена на параметри и редеплојмент на веќе постоечки ствари.

Тоа не бара никаква специјализација, туку може да го заврши буквално секој. Било кој рандом член од форумов да го собереме, ќе може да го научиме да го прави тоа за недела дена. Зошто тогаш инженерите не би го правеле кога им е потребно?

Истото важи и за day to day работата и на другите специјалности. Луѓето го имаат скилсетот, ама многу ретко го користат. Најчесто трошат време на тривијалности. И тоа ќе се искорени додека не влезат нови евтини пари во индустријата. Ако влезат. Ако не, исто како телекомите. Медениот месец заврши, работите ќе се стабилизираат.

Мислам дека тука пак имаме дискусија за типот на фирма. Во мали/средни компании, да, се согласувам со се што е напишано.

Ама ако имаш голем систем, постојано имаш нови работи за конфигурирање и автоматизација.
Ако работиш на некој cloud, тоа си е посебна наука, како да ја оптимизираш твојата инфраструктура внатре во самиот cloud.
Пример сакаш да правиш load testing. Лесно е да направиш копија на продукциска околина што ќе ти лапа исто ресурси како продукциската.
Ама ако сфатиш дека не треба да го скалираш целиот систем (пример не мора да се замараш со load balancer-и, load тест-от ќе ги подели подеднакво request-ите по инстанца директно) тогаш можеш да заштедиш многу. Ако ја наместиш околината да се крева само тогаш кога сакаш да го пуштиш тестот (со тоа што ќе ги рекреира сите потребни информации) ќе заштедиш уште повеќе. Ова второто е процес за којшто може да ти требаат месеци за да го средиш како што треба.

Да не зборам што колку е поголем системот, толку повеќе различни работи имаш за одржување. Ако имаш monolith, имаш една апликација, една база и еден фронт енд и тоа е тоа. Ова ќе го конфигурираш за 2 дена и после тоа немаш гајле.

Ако имаш микросервиси, со kubernetes, кешови, брокери итн, инфраструктурата станува многу позаебана за одржување.
Може секој БЕ девелопер може да се снајде да deployuva monolith, ама не секој може да ги среди работите што ги набројав погоре.

 

[Down]

Кои глупости се изнапишани на темава, сениор дев не бил ако не знаел продукциска околина да сетира

Ако работиш у фирма со 5 луѓе тогаш да, али ако работиш у озбилна фирма се знае што е работа на девелопери што е на девопс што е на тестери, продукт менаџер итн.

Убаво е да знаеш се да, али има разлика од да знаеш да чепнеш, до да разбираш што правиш.

Ајде нека седне тогаш девопс да ја напише апликацијата кога девелоперот е на одмор

 

[Inglourious Basterd]

Мислам дека тука пак имаме дискусија за типот на фирма. Во мали/средни компании, да, се согласувам со се што е напишано.

Ама ако имаш голем систем, постојано имаш нови работи за конфигурирање и автоматизација.
Ако работиш на некој cloud, тоа си е посебна наука, како да ја оптимизираш твојата инфраструктура внатре во самиот cloud.
Пример сакаш да правиш load testing. Лесно е да направиш копија на продукциска околина што ќе ти лапа исто ресурси како продукциската.
Ама ако сфатиш дека не треба да го скалираш целиот систем (пример не мора да се замараш со load balancer-и, load тест-от ќе ги подели подеднакво request-ите по инстанца директно) тогаш можеш да заштедиш многу. Ако ја наместиш околината да се крева само тогаш кога сакаш да го пуштиш тестот (со тоа што ќе ги рекреира сите потребни информации) ќе заштедиш уште повеќе. Ова второто е процес за којшто може да ти требаат месеци за да го средиш како што треба.

Да не зборам што колку е поголем системот, толку повеќе различни работи имаш за одржување. Ако имаш monolith, имаш една апликација, една база и еден фронт енд и тоа е тоа. Ова ќе го конфигурираш за 2 дена и после тоа немаш гајле.

Ако имаш микросервиси, со kubernetes, кешови, брокери итн, инфраструктурата станува многу позаебана за одржување.
Може секој БЕ девелопер може да се снајде да deployuva monolith, ама не секој може да ги среди работите што ги набројав погоре.

Се што наброја се вика on demand computing. Работам во фирма што има над 80 продукти, од монолити од 80ти (не се зезам) до микросервисни апликации направени вчера. Се што наброја имаме, дополнително имаме и чуда што и да ги изгуглаш нема да најдеш што се.

И повторно најголем дел од времето луѓето трошат на тривијални работи. Микросервисната инфраструктура не е посложена од монолит. Кубернетес кластер не е потежок за оддржување од он премис сервер. Напротив. Затоа се измислени тие технологии. Да ги направат оперативните работи полесни, не потешки.

 

[Imperatorot]

Кои глупости се изнапишани на темава, сениор дев не бил ако не знаел продукциска околина да сетира

Ако работиш у фирма со 5 луѓе тогаш да, али ако работиш у озбилна фирма се знае што е работа на девелопери што е на девопс што е на тестери, продукт менаџер итн.

Убаво е да знаеш се да, али има разлика од да знаеш да чепнеш, до да разбираш што правиш.

Ајде нека седне тогаш девопс да ја напише апликацијата кога девелоперот е на одмор

Во една претходна фирма, дев-опсот/сис админ или што и да му беше позицијата, мене ме прашуваше како да ја крене апликацијата т.е како да пушти миграции, сидери, мејл сервер.

 

[Lester Freamon]

Мислам дека тука пак имаме дискусија за типот на фирма. Во мали/средни компании, да, се согласувам со се што е напишано.

Ама ако имаш голем систем, постојано имаш нови работи за конфигурирање и автоматизација.
Ако работиш на некој cloud, тоа си е посебна наука, како да ја оптимизираш твојата инфраструктура внатре во самиот cloud.
Пример сакаш да правиш load testing. Лесно е да направиш копија на продукциска околина што ќе ти лапа исто ресурси како продукциската.
Ама ако сфатиш дека не треба да го скалираш целиот систем (пример не мора да се замараш со load balancer-и, load тест-от ќе ги подели подеднакво request-ите по инстанца директно) тогаш можеш да заштедиш многу. Ако ја наместиш околината да се крева само тогаш кога сакаш да го пуштиш тестот (со тоа што ќе ги рекреира сите потребни информации) ќе заштедиш уште повеќе. Ова второто е процес за којшто може да ти требаат месеци за да го средиш како што треба.

Да не зборам што колку е поголем системот, толку повеќе различни работи имаш за одржување. Ако имаш monolith, имаш една апликација, една база и еден фронт енд и тоа е тоа. Ова ќе го конфигурираш за 2 дена и после тоа немаш гајле.

Ако имаш микросервиси, со kubernetes, кешови, брокери итн, инфраструктурата станува многу позаебана за одржување.
Може секој БЕ девелопер може да се снајде да deployuva monolith, ама не секој може да ги среди работите што ги набројав погоре.

Во многу ситуации поефтино е да плати поскапо на неоптимизиран клауд, отколку уште 30к евра за човек (бруто плата е толку за девопс што разбира), особено ако немаат повеќе проекти на кои може да го користат. Гратис и тие 30к се за 10 месеци (1 месец одмор, 1 месец државни празници), па во тој период ако испадне нешто или ќе треба да покриваат девелоперите, или ќе треба да бараш консултант.

 

[Amaterasu]

Во многу ситуации поефтино е да плати поскапо на неоптимизиран клауд, отколку уште 30к евра за човек (бруто плата е толку за девопс што разбира), особено ако немаат повеќе проекти на кои може да го користат. Гратис и тие 30к се за 10 месеци (1 месец одмор, 1 месец државни празници), па во тој период ако испадне нешто или ќе треба да покриваат девелоперите, или ќе треба да бараш консултант.

Фирмата каде што работам плаќа помеѓу 2 и 3 милиони $ на Амазон месечно, така да не би се согласил со овој statement

Се што наброја се вика on demand computing. Работам во фирма што има над 80 продукти, од монолити од 80ти (не се зезам) до микросервисни апликации направени вчера. Се што наброја имаме, дополнително имаме и чуда што и да ги изгуглаш нема да најдеш што се.

И повторно најголем дел од времето луѓето трошат на тривијални работи. Микросервисната инфраструктура не е посложена од монолит. Кубернетес кластер не е потежок за оддржување од он премис сервер. Напротив. Затоа се измислени тие технологии. Да ги направат оперативните работи полесни, не потешки.

Види, не ги знам проектите што ги имате. Можеш да имаш 80 продукти, ако сите се со average complexity, лесно се конфигурираат. За simple инфраструктура, можеш да го автоматизираш процесот па и 1000 да одржуваш.
Еве да излеземе со некои бројки. Колку пораки во секунда имате во peak time на Kafka (или друг брокер)? Peak на query/рансакции во база? Зборам за peak load што издржува една конфигурација.
Идејата ми е дека да, лесно е да конфигурираш Kafka сервер. Ама ако сакаш да издржува голем load, тогаш работите се комплицираат. Исто е и со бази, со мрежна инфраструктура и се што може да ти текне.
И микросервис архитектура можеш лесно да направиш ако не ти е гајле дали request-oт трае 50 или 500ms.

На крај ако имате инженери кои можат ем да развиваат софтвер ем да ги оптимизираат сите овие сервиси/алатки, тогаш спуштам капа и би сакал да испијам некое пиво со нив.

 

[Lester Freamon]

Фирмата каде што работам плаќа помеѓу 2 и 3 милиони $ на Амазон месечно, така да не би се согласил со овој statement


Види, не ги знам проектите што ги имате. Можеш да имаш 80 продукти, ако сите се со average complexity, лесно се конфигурираат. За simple инфраструктура, можеш да го автоматизираш процесот па и 1000 да одржуваш.
Еве да излеземе со некои бројки. Колку пораки во секунда имате во peak time на Kafka (или друг брокер)? Peak на query/рансакции во база? Зборам за peak load што издржува една конфигурација.
Идејата ми е дека да, лесно е да конфигурираш Kafka сервер. Ама ако сакаш да издржува голем load, тогаш работите се комплицираат. Исто е и со бази, со мрежна инфраструктура и се што може да ти текне.
И микросервис архитектура можеш лесно да направиш ако не ти е гајле дали request-oт трае 50 или 500ms.

На крај ако имате инженери кои можат ем да развиваат софтвер ем да ги оптимизираат сите овие сервиси/алатки, тогаш спуштам капа и би сакал да испијам некое пиво со нив.

Сигурно не ја одржува цела инфраструктура еден човек
Немој да го дупни паметот некој да почне да бара начини да ве оптимизира, оти не постои проект и фирма каде што не може да се крати ако се заменат одредени луѓе и процеси.

 

[Menethil]

Mislam otidovte u losa nasoka, od nego ne se baralo nikakva optimizacija, tuku bazicna infrastrruktura. Spored mene sekoj senior treba da go znae ova, potocno da ima pretstava kako funkcionira i ako im potreba(mal tim bez devops) da go naprai/ nauci ova.

 

[Inglourious Basterd]

Фирмата каде што работам плаќа помеѓу 2 и 3 милиони $ на Амазон месечно, така да не би се согласил со овој statement


Види, не ги знам проектите што ги имате. Можеш да имаш 80 продукти, ако сите се со average complexity, лесно се конфигурираат. За simple инфраструктура, можеш да го автоматизираш процесот па и 1000 да одржуваш.
Еве да излеземе со некои бројки. Колку пораки во секунда имате во peak time на Kafka (или друг брокер)? Peak на query/рансакции во база? Зборам за peak load што издржува една конфигурација.
Идејата ми е дека да, лесно е да конфигурираш Kafka сервер. Ама ако сакаш да издржува голем load, тогаш работите се комплицираат. Исто е и со бази, со мрежна инфраструктура и се што може да ти текне.
И микросервис архитектура можеш лесно да направиш ако не ти е гајле дали request-oт трае 50 или 500ms.

На крај ако имате инженери кои можат ем да развиваат софтвер ем да ги оптимизираат сите овие сервиси/алатки, тогаш спуштам капа и би сакал да испијам некое пиво со нив.

На најзахтевната апликација имаме ~милион конкурентни јузери, што креираат неколку милиони (7-8) реквести кон API во минута, кон база немам проверено, ама знаејќи ја технологијата сигурно е бар 10-15 кверија по АПИ реквест.

И целата таа инфраструктура е сложена. Има реплики, сегментација по географија, кеширање, балансирање. И секако дека имаме дев опс луѓе што го работат тоа. Ама од 60, секогаш се истите тројца што знаат да средат нешто. Другите 57 менуваат параметри.

И да, имаме инженери што го разбираат се тоа што е иссетирано. Како би триажирале проблем инаку?

Како што имаме инженери што немаат поим кај се наоѓаат. Не ми е поентата девопс не треба, девелоперите се гении.

 

[zmej gorjanin]

A ako brojot na konkurentni rekvesti se zgolemi, ete developerot naucil da setira i load balancer i ima povekje instanci shto kje gi hendlaat, ali db ta mora da ostane single source of truth, togash shto praime? Kje vrabotime db admin ili developerot treba da nauci da setira/da znae i nivoa na izolcija na transakcii na databaza?

 

[Menethil]

A ako brojot na konkurentni rekvesti se zgolemi, ete developerot naucil da setira i load balancer i ima povekje instanci shto kje gi hendlaat, ali db ta mora da ostane single source of truth, togash shto praime? Kje vrabotime db admin ili developerot treba da nauci da setira/da znae i nivoa na izolcija na transakcii na databaza?

Ako e isplatlivo, kje zemat. Ako nemaat drugo care, kje zemat i speciializiran db admin. Ako nema, kje rabotat so toj kadar so go imaat. Ne e nekoja filozofija ova.

 

[zmej gorjanin]

Ako e isplatlivo, kje zemat. Ako nemaat drugo care, kje zemat i speciializiran db admin. Ako nema, kje rabotat so toj kadar so go imaat. Ne e nekoja filozofija ova.

A ako ne e, kje ostavat povekje kverinja da pravat update na eden record od db vo ist moment? Da receme cena na proizvod ili balance na smetka?