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

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

Amaterasu

123123113
Член од
17 април 2012
Мислења
1.174
Поени од реакции
1.156
Да се намалат трошкови. Еден програмер по проект.
Тоа може ако девелоперот има време. Нормално е во криза луѓето што претходно работеле по 2-3 саати да пробаат да им дадат плус таскови, ама ако некој нема време, нема време. Не може наеднаш да почне дупло да работи :D
 
Член од
24 март 2010
Мислења
15.217
Поени од реакции
25.977
Зошто би умирала кај големите фирми? Ако имаш потреба од специјалисти, ќе мора да најдеш специјалисти. Пример, во случајот што го опиша @zmej gorjanin , ако фирмата секој ден има devOps обврски, сигурно ќе вработи човек за тоа. Ако има devOps обврски неколку пати месечно, тогаш е нормално некој од BE инженерите да ги заврши.
Затоа што 99% од времето на специјалистите од ДевОпс наместо во креирање на автоматизација на процесот, поминува во промена на параметри и редеплојмент на веќе постоечки ствари.

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

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

Amaterasu

123123113
Член од
17 април 2012
Мислења
1.174
Поени од реакции
1.156
Затоа што 99% од времето на специјалистите од ДевОпс наместо во креирање на автоматизација на процесот, поминува во промена на параметри и редеплојмент на веќе постоечки ствари.

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

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

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

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

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

Down

Boozer
Член од
4 мај 2012
Мислења
3.603
Поени од реакции
6.074
Кои глупости се изнапишани на темава, сениор дев не бил ако не знаел продукциска околина да сетира :pos:

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

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

Ајде нека седне тогаш девопс да ја напише апликацијата кога девелоперот е на одмор :pos:
 
Член од
24 март 2010
Мислења
15.217
Поени од реакции
25.977
Мислам дека тука пак имаме дискусија за типот на фирма. Во мали/средни компании, да, се согласувам со се што е напишано.

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

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

Ако имаш микросервиси, со kubernetes, кешови, брокери итн, инфраструктурата станува многу позаебана за одржување.
Може секој БЕ девелопер може да се снајде да deployuva monolith, ама не секој може да ги среди работите што ги набројав погоре.
Се што наброја се вика on demand computing. Работам во фирма што има над 80 продукти, од монолити од 80ти (не се зезам) до микросервисни апликации направени вчера. Се што наброја имаме, дополнително имаме и чуда што и да ги изгуглаш нема да најдеш што се.

И повторно најголем дел од времето луѓето трошат на тривијални работи. Микросервисната инфраструктура не е посложена од монолит. Кубернетес кластер не е потежок за оддржување од он премис сервер. Напротив. Затоа се измислени тие технологии. Да ги направат оперативните работи полесни, не потешки.
 
Член од
9 февруари 2016
Мислења
1.321
Поени од реакции
3.307
Кои глупости се изнапишани на темава, сениор дев не бил ако не знаел продукциска околина да сетира :pos:

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

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

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

Lester Freamon

A man of focus, commitment, sheer will...
Член од
14 јануари 2015
Мислења
15.969
Поени од реакции
35.924
Мислам дека тука пак имаме дискусија за типот на фирма. Во мали/средни компании, да, се согласувам со се што е напишано.

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

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

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

Amaterasu

123123113
Член од
17 април 2012
Мислења
1.174
Поени од реакции
1.156
Во многу ситуации поефтино е да плати поскапо на неоптимизиран клауд, отколку уште 30к евра за човек (бруто плата е толку за девопс што разбира), особено ако немаат повеќе проекти на кои може да го користат. Гратис и тие 30к се за 10 месеци (1 месец одмор, 1 месец државни празници), па во тој период ако испадне нешто или ќе треба да покриваат девелоперите, или ќе треба да бараш консултант.
Фирмата каде што работам плаќа помеѓу 2 и 3 милиони $ на Амазон месечно, така да не би се согласил со овој statement :D

Се што наброја се вика 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

A man of focus, commitment, sheer will...
Член од
14 јануари 2015
Мислења
15.969
Поени од реакции
35.924
Фирмата каде што работам плаќа помеѓу 2 и 3 милиони $ на Амазон месечно, така да не би се согласил со овој statement :D


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

На крај ако имате инженери кои можат ем да развиваат софтвер ем да ги оптимизираат сите овие сервиси/алатки, тогаш спуштам капа и би сакал да испијам некое пиво со нив.
Сигурно не ја одржува цела инфраструктура еден човек :)
Немој да го дупни паметот некој да почне да бара начини да ве оптимизира, оти не постои проект и фирма каде што не може да се крати ако се заменат одредени луѓе и процеси.
 
Член од
24 март 2010
Мислења
15.217
Поени од реакции
25.977
Фирмата каде што работам плаќа помеѓу 2 и 3 милиони $ на Амазон месечно, така да не би се согласил со овој statement :D


Види, не ги знам проектите што ги имате. Можеш да имаш 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 менуваат параметри.

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

Како што имаме инженери што немаат поим кај се наоѓаат. Не ми е поентата девопс не треба, девелоперите се гении.
 
Член од
26 јануари 2009
Мислења
11.826
Поени од реакции
18.514
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?
 
Член од
17 август 2011
Мислења
9.967
Поени од реакции
17.799
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.
 
Член од
26 јануари 2009
Мислења
11.826
Поени од реакции
18.514
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?
 

Kajgana Shop

На врв Bottom