IT-alan työpaikat

Liittynyt
17.10.2016
Viestejä
6 317
Terraform on kyllä hyvä työkalu, mutta tuo palveluntarjoajariippumattomuus ei toki valitettavasti tarkoita sitä, että samaa tai lähes samaa terraform-koodia voisi käyttää ristiin esim. Azuren ja AWS:n välillä.
Eri palveluntarjoajilla on omat providerinsa, joissa komennot tietysti vaihtelevat tarjolla olevien resurssien mukaan.

Eli samalla koodilla ei saa polkaistua pystyyn samanlaista infraa Azureen ja AWS:ään.
Olisiko tuohon jotain parempaa työkalua, vai kannattaako luottaa terraformiin jos haluaa mahdollisuuden deployata kumpaan tahansa + rakentaa vain kummallekin palveluntarjoajalle erilliset konffit joita ylläpitää erikseen?

Tietty jos kaipaa esim. S3 storagea, niin miten tuon kanssa kannattaisi toimia?
 
Liittynyt
17.10.2016
Viestejä
4 665
Eli samalla koodilla ei saa polkaistua pystyyn samanlaista infraa Azureen ja AWS:ään.
Joo, ei missään nimessä. Hyödyt mielestäni:
  • voi yhdistellä eri palveluntarjoajia samaan infraan, eikä tarvitse hirttäytyä yhteen vain siksi, että saisi IaC:n käyttöön (voi esim. siirtää hissukseen sitä infraa uuteen paikkaan)
  • voi käyttää IaC:tä
  • voi käyttää samaa syntaksia joka paikassa (eri tapa määritellä resurssit, mutta syntaksi sama)
Riippuu sitten palveluntarjoajasta, kuinka hyvä provider on käytettävissä, jos lainkaan. Aika kivasti noita onneksi on tarjolla:


Ja kun periaate on selvillä, niin perusjutut toimivat samalla tavalla eri palvelutarjoajien resursseilla/providerilla.
 
Liittynyt
17.10.2016
Viestejä
4 665
Olisiko tuohon jotain parempaa työkalua, vai kannattaako luottaa terraformiin jos haluaa mahdollisuuden deployata kumpaan tahansa + rakentaa vain kummallekin palveluntarjoajalle erilliset konffit joita ylläpitää erikseen?

Tietty jos kaipaa esim. S3 storagea, niin miten tuon kanssa kannattaisi toimia?
Vaatii tietenkin sen, että luo moduulit kummallekin palvelulle. Ja jos niiden moduulien rajapinta on samanlainen, niin sitten provisioiminen kumpaan tahansa menee aika kivuttomasti. Terraform on varmasti hyvä (paras?, ainoa?) ratkaisu tuollaiseen parin pilvipalvelun yhdistämiselle.

Sorry, OT. Kuuluis toiseen ketjuun tämä. Mutta hyvä näitä on opetella alaa silmällä pitäen!
 
Viimeksi muokattu:
Liittynyt
29.10.2016
Viestejä
681
Toinen hankalampi vaihtoehto on sitten opetella jokaiselle providerille niiden natiivit IaC työkalut, esim. CloudFormation AWS:lle. Terraformissa ei ole myöskään välttämättä kaikkia samoja ominaisuuksia kuin nuissa natiiveissa kielissä. Azureen en ole tutustunu, en tiedä sen konffausmenetelmiä. Itse käytän kyllä Terraformia, lähinnä AWS:ään ja OpenStackiin. Puppetilla sitten serverit.
 
Liittynyt
26.06.2018
Viestejä
200
Se on kyllä hyvä, että löytyy ihmisiä jotka tykkää vääntää dockeria ja tuunata Terraformia, Cloudformationia, yms. Itse joudun dockerin kanssa säätämään päivittäin ja onhan se hanurista ihmetellä mikä meni taas pieleen. No ehkä se ei ole yksin dockerin syy, vaan sen himmelin mitä porukka on sen päälle rakentanut.

Mitä enemmän voisin vetää serverlessiin tuon niin sitä parempi. Tai jos joku Devops sankari sen kaiken hoitaisi niin menisi se kai niinkin. IaC:n luulin joskus tarkoittavan, että ei enää tarvi infrasta niin huolehtia. Noh, se tarkoittikin että ei enää ehdi tehdä sitä itse softaa; koodaa, ylläpitää ja debuggaa jatkuvasti vain infrakoodia :)
 
Liittynyt
06.11.2018
Viestejä
358
Vain ihmiset jotka eivät ole oikeasti infrasta huolehtineet (siis päivystystä SLA’lla) kuvittelevat että IaC tai ylipäätänsä pilvi jotenkin tarkoittaa, ettei infrasta tarvitse huolehtia.

Se mitä IaC käytännössä tekee on, että ne samat tyypit kuin ennen ei välttämättä voi siitä huolehtia, ellei ne ollut apinoita jotka seuraa jonkun muun tekemää runbookkia.

Kyllä softa pilvessäkin kaatuu tai menee jumiin ihan niinkuin muuallakin. Sit vaan kun ympäristö on määritelty koodina niin ylläpitäjät ymmärtävät siitä suunilleen yhtä paljon kuin koodin kirjastoista aikaisemmin.

Meillä toi siirtyminen on tähän mennessä mennyt yllättävän kivuttomasti. Edelleen kyllä vuosienkin jälkeen ne IaC’n alkuperäiset hyödyt on musta toteuttamatta... ”Kato kun tää luo vaan automaattisesti uusia memcached instansseja kun kuorma kasvaa” -> tosin cloudformation määritysten, konffien, jobien ja putkien toteutukseen meni kuukaus kun sen olis tehnyt käsin parissa tunnissa... Eikä kasvua ole odotettavissa niin paljoa että koskaan tarvis skaalautua... Eikä säästöäkään tullut infralle kun ne ”kalliit” serverit on nyt korvattu AWS’llä jonka lasku on miljoonia vuodessa. :)
 
Liittynyt
29.10.2016
Viestejä
681
Vain ihmiset jotka eivät ole oikeasti infrasta huolehtineet (siis päivystystä SLA’lla) kuvittelevat että IaC tai ylipäätänsä pilvi jotenkin tarkoittaa, ettei infrasta tarvitse huolehtia.

Se mitä IaC käytännössä tekee on, että ne samat tyypit kuin ennen ei välttämättä voi siitä huolehtia, ellei ne ollut apinoita jotka seuraa jonkun muun tekemää runbookkia.

Kyllä softa pilvessäkin kaatuu tai menee jumiin ihan niinkuin muuallakin. Sit vaan kun ympäristö on määritelty koodina niin ylläpitäjät ymmärtävät siitä suunilleen yhtä paljon kuin koodin kirjastoista aikaisemmin.

Meillä toi siirtyminen on tähän mennessä mennyt yllättävän kivuttomasti. Edelleen kyllä vuosienkin jälkeen ne IaC’n alkuperäiset hyödyt on musta toteuttamatta... ”Kato kun tää luo vaan automaattisesti uusia memcached instansseja kun kuorma kasvaa” -> tosin cloudformation määritysten, konffien, jobien ja putkien toteutukseen meni kuukaus kun sen olis tehnyt käsin parissa tunnissa... Eikä kasvua ole odotettavissa niin paljoa että koskaan tarvis skaalautua... Eikä säästöäkään tullut infralle kun ne ”kalliit” serverit on nyt korvattu AWS’llä jonka lasku on miljoonia vuodessa. :)
Kyllä suurin hyöty pilveen siirtymisessä on se että sulla ei tuu käytännössä koskaan enää "sori joudutte odottamaan, meidän resurssit on käytetty". Tuota on tullut nähtyä ja jos devaajat joutuvat odottamaan esim. 15 min ylimääräistä koska pull request jonottaa niin se tulee aika saatanan kalliiksi pitemmän päälle. Toisekseen fyysisissä servereissä sulla saattaa tulla paljon helpommin single-point-of-failure pisteitä joka on aina todella huono homma. Puhumattakaan siitä server management säädöstä joka vie helvetisti aikaa. Esimerkiksi pelkkä kernelien päivitys fyysisissä laitteissa vaatii aika tarkan suunnitelman ja käyttökatkovälit. Puhumattakaan tietoturvasäädöistä, palomuurista, laiterikoista, monitoroinnin rakentamisesta, jne. Kaikki em. asiat helpompaa/ei tarvitse huolehtia pilvipalveluissa.

IaC:ista eri mieltä myös. Ensinnäkin, sä tiedät aina mitkä konffit sulla on käytössä. Kun esimerkiksi tulee ongelmatilanteita, tiedät tasan tarkkaan minkälaiset ne sun konffit on siinä koko sun stäkissä, ongelmanratkonta on esimerkiksi huomattavan paljon helpompaa niihin törmätessä. Toisekseen IaC mahdollistaa että infra menee lähemmäksi devaajia, jolloin pienemmissä projekteissa sä et tarvi erikseen ylläpitäjiä, eikä serverituusaajia lainkaan joka on taas aika iso säästö. Infra koodiksi ei myöskään ole mikään valtava urakka jos sun tiimissä on edes hieman asiaa osaavia jannuja hommissa.
 
Liittynyt
17.10.2016
Viestejä
2 951
Kyllä suurin hyöty pilveen siirtymisessä on se että sulla ei tuu käytännössä koskaan enää "sori joudutte odottamaan, meidän resurssit on käytetty".
Microsoft tässä taannoin juuri ilmoitti että "sori, Azure on loppu", aiheuttaen juuri kaikenlaista vastaavaa. Ja sitten kun siellä pilvessä ollaan niin kovin herkästi ei enää lähdetä fyysisiä koneita pystyttelemään.
 
Liittynyt
29.10.2016
Viestejä
681
Microsoft tässä taannoin juuri ilmoitti että "sori, Azure on loppu", aiheuttaen juuri kaikenlaista vastaavaa. Ja sitten kun siellä pilvessä ollaan niin kovin herkästi ei enää lähdetä fyysisiä koneita pystyttelemään.
Sitte sä voit skaalata AWS:ään. Veikkaan että noi pilvikatkokset ovat huomattavan harvinaisia silti vrt. omien servereiden mahdollisiin ongelmiin.
 
Liittynyt
29.10.2016
Viestejä
681
Teknisesti voisikin skaalata. Reaalielämässä ei. Ja kyllä, katkokset on harvinaisempia, ei siitä mihinkään pääse.
Tietysti voit myös rakentaa hybridiratkaisun jossa sulla on sekä on-prem- ,että pilviresursseja. Tällöin molemmat tukevat toisiaan. Ja kustannustehokkaimman ratkaisun saat sillä että aina ensin skaalataan fyysiset resurssit täyteen ja vasta sitten skaalataan pilveen.
 
Liittynyt
17.10.2016
Viestejä
2 951
Tietysti voit myös rakentaa hybridiratkaisun jossa sulla on sekä on-prem- ,että pilviresursseja. Tällöin molemmat tukevat toisiaan. Ja kustannustehokkaimman ratkaisun saat sillä että aina ensin skaalataan fyysiset resurssit täyteen ja vasta sitten skaalataan pilveen.
Nää vaihtoehdot on kyllä hyvin tiedossa. Mutta monissa (useimmissa?) paikoissa ei oo realismia se että tehdään multicloudia tai hybridiä. Ei vaan oo kustannustehokasta palkata sitä osaamista että kaikki rullaisi kunnolla, vaan fiksumpaa keskittyä yhteen alustaan. Se sitten toki välillä saattaa aiheuttaa ongelmia, mutta ei se multi/hybrid-cloudikaan mitään pelkkää juhlaa ole. Ja etenkään se että sulla on yksi yksittäinen ongelma nyt, ei ole peruste lähteä pystyttämään multicloudia tai hybridiratkaisuja, kun niidenkin kanssa menee oma aikansa että ne saadaan sellaiseen kuntoon että niistä on apua.

Mutta joo, yleisesti ottaen kannattaa opetella noita pilvialustoja. Jos kontitat sovelluksesi niin hyvin samankaltaisella pilviarkkitehtuurilla ne pyörii ympäristössä kuin ympäristössä.
 
Liittynyt
17.10.2016
Viestejä
4 665
Mutta joo, yleisesti ottaen kannattaa opetella noita pilvialustoja. Jos kontitat sovelluksesi niin hyvin samankaltaisella pilviarkkitehtuurilla ne pyörii ympäristössä kuin ympäristössä.
Juuri näin. Noiden osaaminen jollain tasolla on ihan hyvä valttikortti kun hakee uuteen työpaikkaan. Ja onneksi noita voi harjoitella halvalla/ilmaiseksi. AWS:n Free Tier antaa vuodeksi aika kivat eväät treenailuun. Muilla pilvipalveluilla on varmaan vastaavia. Domain maksaa sen 9e/vuosi. Pelkän VPS:nkin (Terraform-tuella) saa parilla eurolla kuussa. Eli onneksi kätensä saa upotettua saveen ilman isoa laskua.
 
Liittynyt
29.10.2016
Viestejä
681
Nää vaihtoehdot on kyllä hyvin tiedossa. Mutta monissa (useimmissa?) paikoissa ei oo realismia se että tehdään multicloudia tai hybridiä. Ei vaan oo kustannustehokasta palkata sitä osaamista että kaikki rullaisi kunnolla, vaan fiksumpaa keskittyä yhteen alustaan. Se sitten toki välillä saattaa aiheuttaa ongelmia, mutta ei se multi/hybrid-cloudikaan mitään pelkkää juhlaa ole. Ja etenkään se että sulla on yksi yksittäinen ongelma nyt, ei ole peruste lähteä pystyttämään multicloudia tai hybridiratkaisuja, kun niidenkin kanssa menee oma aikansa että ne saadaan sellaiseen kuntoon että niistä on apua.

Mutta joo, yleisesti ottaen kannattaa opetella noita pilvialustoja. Jos kontitat sovelluksesi niin hyvin samankaltaisella pilviarkkitehtuurilla ne pyörii ympäristössä kuin ympäristössä.
Kuten perustelin aikaisemmin syitä:

"Kyllä suurin hyöty pilveen siirtymisessä on se että sulla ei tuu käytännössä koskaan enää "sori joudutte odottamaan, meidän resurssit on käytetty". Tuota on tullut nähtyä ja jos muutama sata devaajaa joutuu odottamaan esim. 15 min ylimääräistä koska pull request jonottaa niin se tulee aika saatanan kalliiksi pitemmän päälle. Toisekseen fyysisissä servereissä sulla saattaa tulla paljon helpommin single-point-of-failure pisteitä joka on aina todella huono homma. Puhumattakaan siitä server management säädöstä joka vie helvetisti aikaa. Esimerkiksi pelkkä kernelien päivitys fyysisissä laitteissa vaatii aika tarkan suunnitelman ja käyttökatkovälit. Puhumattakaan tietoturvasäädöistä, palomuurista, laiterikoista, monitoroinnin rakentamisesta, jne. Kaikki em. asiat helpompaa/ei tarvitse huolehtia pilvipalveluissa."

Lisätään myös vielä se että sun omia fyysisiä servereitä sä et saa koskaan hyödynnettyä 100% koska nekin idlaavat paljon aika ajoin. Silti sä maksat räkkimaksuja, sähkömaksuja ja palvelumaksuja mitä lie niistä servereistä.

Se yks/kaks pilvijamppaa palkattuna/ja/tai koulutettuna nykyiset infrajampat maksaa itsensä hyvin nopeasti takaisin. Toki hybridimallissa sä et pääse serverisäädöstä eroon, ellet paketoi niitä johonkin sisäpilveen(esim. OpenStack) ja annat IT-osaston hoitaa sen fyysisen infran siellä alla.
 
Liittynyt
06.11.2018
Viestejä
358
Joo, toki yksinkertaistin yllä. Lisäksi, ei kai kukaan ole ajanut fyysisiä servereitä aikoihin vaan vmwarea yms (ainakin jos on tuhansia servereitä).

Se mikä on ollut harvinaisempaa on ehkä ollut vmwaren apien / SDK’n tehokas käyttö, koska vmware on ollut IT’n takana.

Mä leikin joskus vmwaren SDK’n kanssa ja sehän oli tosi hauska ja helppo. En vaan koskaan nähnyt että sitä olis annettu devaajille.

Enkä mä todellakaan ole vastaan AWS’ää. Mulla on mun ”omistamia” tuotteita ajossa siellä ja erityisesti natiivisti suunnitellut palvelut toimivat loistavasti.
 

Lexy

BANNATTU
BANNED
Team R&T
Liittynyt
17.10.2016
Viestejä
420
Side notena ja ihan jokaiselle infra/pilvikaverille ettei mene liian offtopiciksi (tietoturva kun mainittu):
Pilvessä tietoturva ei saisi olla se mörkö millä siirtymää lykätään. Ne mahdollisuudet mitä eri pilvialustat tarjoaa (AWS, Azure, Google) on lähtökohtaisesti ihan eri tasoa kuin mihin ne Pertti-Saarat niiden fyysisten kanssa pystyy. Nuo firmat lisäksi puskee kyvykkyyksiä sellaista vauhtia, että siinä ei pysy edes mukana.

Mutta...tämä vaatii syvää ymmärrystä mitä kaikkea on mahdollista käyttää. Tietoturva on muutakin kuin palomuureja, konfiguraatioita tai haavoittuvuuksien skannauksia. Aivan helvetin usein näkee kuinka pilviasiantuntija on kyllä palvelut saanut päälle ja nätisti pyörimään mutta ne kyvykkyydet mitä tietoturvanäkökulmasta on kytketty on aivan umpisurkeita verrattuna siihen mitä voisi tai tulisi olla. Isoin syy on osaamattomuus ja ihan se, että niitä tietoturvakilkkeitä tulee jatkuvasti lisää. Osa syyllinen on myös, se että tietoturvakaverit on jääneet pahasti jälkeen.

Dilemma kaksi mitä tulee vastaan aivan liikaa on se, että kuvitellaan että vastuu tietosuojasta/tietoturvasta katoaa koska pilvi. Ei se mihinkään katoa, mutta muoto vaan muuttuu. Ei se MS, AWS tai esim. Google sinulle niitä asetuksia laita vastaamaan teidän riski-/tavoitetasoa. He vastaavat fyysisen ja osittain laite-/verkkotason tietoturvasta mutta tämän on heidän itsensä suojaksi - ei asiakkaan. Palvelun pystyttäjä on vastuussa siitä ympäröivästä tietoturvasta.

Eli kun pilvestä puhutaan niin ottakaa mukaan/palkatkaa/lainatkaa konsulttia joka on pilvitietoturvan asiantuntija (ja ei, ei ole sellaistakaan joka tietää AWS:stä, Azuresta ja GCP:stä kaiken - myös se mihin on fokusoitunut sanelee paljon). Se, että on infratietoturvan syväosaaja ei ole tae, että pilvitietoturvalu onnistuu. Nöyrä pyyntö onkin antaa tietoturva tietoturvasta vastaavien harteille eikä yrittää "säätää vähän sinne päin".

Jos firmassa muutenkin puhutaan ns. tietoturvan yleismiehestä joka hoitaa kaiken sovellustietoturvasta "strategiseen" suunnitteluun niin suosittelen vaihtamaan firmaa nopeasti - nämä tulee jossakin viaheessa epämukavasti vastaan kaikille hommien parissa tekeville koska ei ole sellaista superjumalaa joka hoitaa kaiken mitä kunnolinen tietoturva pitää sisällään.
 
Liittynyt
26.06.2018
Viestejä
200
IaC:ista eri mieltä myös. Ensinnäkin, sä tiedät aina mitkä konffit sulla on käytössä. Kun esimerkiksi tulee ongelmatilanteita, tiedät tasan tarkkaan minkälaiset ne sun konffit on siinä koko sun stäkissä, ongelmanratkonta on esimerkiksi huomattavan paljon helpompaa niihin törmätessä. Toisekseen IaC mahdollistaa että infra menee lähemmäksi devaajia, jolloin pienemmissä projekteissa sä et tarvi erikseen ylläpitäjiä, eikä serverituusaajia lainkaan joka on taas aika iso säästö. Infra koodiksi ei myöskään ole mikään valtava urakka jos sun tiimissä on edes hieman asiaa osaavia jannuja hommissa.
Niin. Onhan se AWS varmaan kokonaisuutena järkevämpää kuin itse hostata servereitä. Silti en itse koe mielekkääksi tuota, että siirretään Ops käytännössä kokonaan Deville ja sanotaan niitä trendikkäästi DevOpsiksi. Tottakai säästät kun pistät puolta pienemmän porukan tekemään samat työt.

Monimutkaisemmassa softassa on ihan tarpeeksi tekemistä, ettei kiinnosta siihen konttiverkkojen, VPC yhdistelmien, DNS:n, security grouppien, serverless palvelujen, cloudwatch monitoroinnin, RDS:n, load balancerien, skaalausparametrien, verkkolevyjen (EBS, EFS), kaikkien näiden yhdistelmien ja konffailujen, Terra/Cloudform skriptien vääntämiseen ja jokaisen parametrin tuunaamiseen lisäksi hukata lopulta rajallista kapasiteettiaan. Ja nämähän on siis vain siinä varsinaisten hommien lisänä.

Tietenkin joku muu voi tykätä. Ja hyvä ne on ymmärtää, että voisi sen infra-spesialistin kanssa miettiä niitä ja miten kaiken laittaa toimimaan yhteen. Kun oletus on, että devaaja voi sen tehdä siinä sivussa niin tiedän kyllä mitä itse varmistan että en seuraavassa duunissa ainakaan oletettavasti joudu tuunaamaan. Mutta tosiaan, toinen tykkää muhkummasta :)
 
  • Tykkää
Reactions: hmb
Liittynyt
17.10.2016
Viestejä
4 665
Ja nämähän on siis vain siinä varsinaisten hommien lisänä.
Sanoisin, että infran luominen, konffaaminen, ylläpitäminen ja kehittäminen on myös ns. varsinaista hommaa.

Tietenkin joku muu voi tykätä
Kuulostaa lähinnä siltä, että olet ihan väärässä työtehtävässä tekemässä jotain, mistä et lainkaan pidä? Tuossa tilanteessa ehdottomasti kannattaa tuulettaa ja päästä kiinnostavien hommien ääreen.
 
Liittynyt
26.06.2018
Viestejä
200
Sanoisin, että infran luominen, konffaaminen, ylläpitäminen ja kehittäminen on myös ns. varsinaista hommaa.

Kuulostaa lähinnä siltä, että olet ihan väärässä työtehtävässä tekemässä jotain, mistä et lainkaan pidä? Tuossa tilanteessa ehdottomasti kannattaa tuulettaa ja päästä kiinnostavien hommien ääreen.
Kyllähän nuo on oikeaa homma ja työlästä sellaista. Siksi toki arvosta sitä joka tekee sitä. Itse en siihen hommaan varsinaisesti lähtenyt, vaan kehittämään itse softaa. Kun se IaC sitten nähdään, että kyllä se softankehittäjä voi sen hoitaa niin näinhän se menee. Toki tuuletan muihin hommiin tästä sopivassa välissä, ennemmin kuin myöhemmin. Onhan se hyödyllistä oppia tietenkin tietää näistäkin, ettei se nyt ihan hukkaan mene.
 
Liittynyt
13.11.2016
Viestejä
435
Meillä on ainakin tuo devops vs. tuotteiden devaustiimien välinen vastuu jakautunut hyvin määritellyillä järjestelmän laajuisilla ei-toiminnallisilla vaatimuksilla. Niin pitkään kuin kaikkien tuotetiimien kilkkeet toteuttavat kaikki mikropalveluita koskevat NFR:t, on niitä mahdollista laittaa ajoon devops jengin tuottamien deployment-palikoiden kautta.

Tuotteita vääntävien tiimien vastuulle jää siis käytännössä toimivan microservice-infran edellyttävät vaatimukset (health checkit, backpressure, horizontal scalability, service discovery, configurability, ...) sekä jonkinlainen suorituskykytestaus ajoympäristön sizingia varten. Devops porukka kehittää työkaluja sulavaa devausta sekä sovellusten / konfiguraatioiden hallintaa varten.
 
Liittynyt
17.10.2016
Viestejä
2 951
Monimutkaisemmassa softassa on ihan tarpeeksi tekemistä, ettei kiinnosta siihen konttiverkkojen, VPC yhdistelmien, DNS:n, security grouppien, serverless palvelujen, cloudwatch monitoroinnin, RDS:n, load balancerien, skaalausparametrien, verkkolevyjen (EBS, EFS), kaikkien näiden yhdistelmien ja konffailujen, Terra/Cloudform skriptien vääntämiseen ja jokaisen parametrin tuunaamiseen lisäksi hukata lopulta rajallista kapasiteettiaan. Ja nämähän on siis vain siinä varsinaisten hommien lisänä.
Kukaan muu kuin softan kehittäjä ei tiedä mitä sen core ja muistivaatimukset on. Se että kehittäjät pystyy sen käytännössä yhtenä konffi-filuna määrittelemään on vain plussaa.
 
Liittynyt
02.06.2017
Viestejä
186
Kukaan muu kuin softan kehittäjä ei tiedä mitä sen core ja muistivaatimukset on. Se että kehittäjät pystyy sen käytännössä yhtenä konffi-filuna määrittelemään on vain plussaa.
Ei, softan kehittäjällä ei tyypillisesti ole hajuakaan suorituskyky ja muistivaatimuksista. Ne on hallussa teoriassa, mutta käytännön tietää sitten QA osasto - ja siellä suorituskykytestaajat.
Tämä on vain yksi syy siihen, miksi devopsin pitäisi mielestäni olla QA taustaista, ei Dev taustaista, tärkein syy on toki se, että QA taustaisilla ihmisillä on toistettavuus ja järjestelmällisyys hallussa ja Devops on ennenkaikkea tätä. Lisäksi Devopsin ydintä on nimenomaan testaus.

Mutta meitä on toki moneen junaan, ymmärrän kyllä, että monesti softan laatu ei ole top3 kriteereissä, nopeus markkinalle, myytävyys ja hype menevät melkein aina ohi. Tällöin voi laittaa ne devit tekemään opsia ja deploymenttiäkin.
 
Liittynyt
17.10.2016
Viestejä
2 951
Ei, softan kehittäjällä ei tyypillisesti ole hajuakaan suorituskyky ja muistivaatimuksista. Ne on hallussa teoriassa, mutta käytännön tietää sitten QA osasto - ja siellä suorituskykytestaajat.
Tämä on vain yksi syy siihen, miksi devopsin pitäisi mielestäni olla QA taustaista, ei Dev taustaista, tärkein syy on toki se, että QA taustaisilla ihmisillä on toistettavuus ja järjestelmällisyys hallussa ja Devops on ennenkaikkea tätä. Lisäksi Devopsin ydintä on nimenomaan testaus.

Mutta meitä on toki moneen junaan, ymmärrän kyllä, että monesti softan laatu ei ole top3 kriteereissä, nopeus markkinalle, myytävyys ja hype menevät melkein aina ohi. Tällöin voi laittaa ne devit tekemään opsia ja deploymenttiäkin.
Kuulostaa aika pahasti päälle liimatulta QA:lta jos sitä ei lasketa softan kehitykseen. Jos sen irrottaa tuolla tavalla täysin irralliseksi kokonaisuudekseen, niin voi olla varma että jatkossakin tulee paskaa.
 
Liittynyt
17.10.2016
Viestejä
4 665
Ei, softan kehittäjällä ei tyypillisesti ole hajuakaan suorituskyky ja muistivaatimuksista.
Wut? Softan kehittäjä ei tyypillisesti tiedä, millaisia vaatimuksia softalle on asetettu? Tuo kuulostaa todella oudolta. Miksei devaaja ota tästä selvää? Miksei vaatimuksia kommunikoida devaajille, jos sellaiset on olemassa?

Vai meinasitko, että kehittäjällä ei ole hajua, mitä vaatimuksia softalla on (millaisen ympäristön vaatii toimiakseen kunnolla)? Tämäkin kuulostaa aika oudolta. Toki jos homma on ulkoistettu testaajille, niin noin varmaan voi käydä. Eli ensin tehdään peli, sitten joku alkaa testata ja katsotaan, millaisissa koneissa se oikein pyörii? Vähintään outo tapa toimia. Luulisi, että kehitysvaiheessa on jonkinlainen ajatus siitä, missä sitä softaa tullaan käyttämään, mikä on sen käyttäjäryhmä, ja sen mukaan sitten asetetaan vaatimuksia.

Tai sitten tarkoitit jotain ihan muuta, mitä en tajua, joten avaatko lisää.
 
Liittynyt
17.10.2016
Viestejä
6 317
Wut? Softan kehittäjä ei tyypillisesti tiedä, millaisia vaatimuksia softalle on asetettu?
Ei kai tässä ollut vaatimuksista puhetta vaan siitä, että (kaikilla) devaajilla ei ole välttämättä kovinkaan hyvää näppituntumaa, että miten erilaiset ratkaisut käyttäytyvät testijärjestelmien ulkopuolella ihan vaan koska heillä ei ole kokemusta ylläpitäämisestä tai ongelmanratkaisusta tuotantojärjestelmissä. Tietty kokeneilla on enemmän kokemusta, kun ovat saaneet uransa aikana mitä erikoisempia bugirapsoja ja tukipyyntöjä.

Usein vaatimukset on asetettu tasolle X, mutta sitten myyjä menee myymään tuotteen käyttöön Y, jossa joku osa-alue voi olla ihan eri tavalla skalautuva.

Esim. itse tullut joskus pähkäiltyä ongelmia kun myytiin jotain venäläisille ja alkuperäiset suunnittelijat eivät olleet keksineet, että synkroniset kirjoitukset Moskovassa olevaan tietokantaan Vladivostokista ovat "hieman" hitaampia kuin testiympäristöissä kahden 100km etäisyydellä toisistaan olevan datacenterin välillä. Tai että joku windows-levyjako johon joku workflow perustuu, toimii hienosti datacenterin sisällä tai kahden lähekkäin olevan datacenterin välillä, mutta tiedonsiirtonopeus romahtaa ihan täysin kun latenssia on tarpeeksi tjsp.

Joo joo, on georedundancy suppport ja tuetaan hajautettua infraa. Ja kohta Elon Musk soittaa, että eihän tää paska toimi kun etäkonttori on Marssissa. Ja huoltomiestäkään ei voi lähettää kahteen vuoteen.

Eikä tämä ole sinänsä kenenkään vika.
 
Liittynyt
26.06.2018
Viestejä
200
Jos se järjestelmä on niin yksinkertainen, että core määrä ja muisti määrä yhteen tiedostoon riittää niin kyllä kai sellaisen määrittää. Vähän monimutkaisempi järjestelmä vaatii sitten kyllä kokonaisuudessaan aika paljon enemmän konffia, jatkuvaa tuunaamista, osien riippuvuuksien säätöä, erinäisiä näkökulmia (tietoturva, yhteydet, ...), yms. Hyvähän se on kehittäjän olla niitä miettimässä, mutta ei se tarkoita että pitäisi ne konffit rakentaa, ylläpitää ja hallinnoida siinä sivussa.

Tuo kehittäjän tietoisuus, ja näiden konffien yms. hoitokin, varmaan riippuu aika paljon järjestelmistä, toimintaympäristöistä, organisaatiorakenteesta ja toimintatavoista. Asiakkaastakin. Jostain Venäjältä tai Kiinasta voi olla vaikea edes saada kovin hyvää speksiä missä se järjestelmä lopulta toimii. Siinä on tietysti vaikea suunnitella sitä kehittäjän tai kenenkään muunkaan sitten.

QA, yleinen laatutietoisuus, kattava suorituskykytestaus, ja sen saaminen vastaamaan oikeaa ympäristöä on taas sitten oma haasteensa. Varsinkin jos organisaatiossa pihdataan jokaisesta pienimmästä investoinnista. Optimissahan olisi kovia tekijöitä joilla nämä kaikki hallussa ja kiinnostaa, ja resursseihin panostettaisiin kunnolla. Sitten on taas se tosielämä, missä asiat on toisin.
 
Liittynyt
02.06.2017
Viestejä
186
Wut? Softan kehittäjä ei tyypillisesti tiedä, millaisia vaatimuksia softalle on asetettu? Tuo kuulostaa todella oudolta. Miksei devaaja ota tästä selvää? Miksei vaatimuksia kommunikoida devaajille, jos sellaiset on olemassa?

Vai meinasitko, että kehittäjällä ei ole hajua, mitä vaatimuksia softalla on (millaisen ympäristön vaatii toimiakseen kunnolla)? Tämäkin kuulostaa aika oudolta. Toki jos homma on ulkoistettu testaajille, niin noin varmaan voi käydä. Eli ensin tehdään peli, sitten joku alkaa testata ja katsotaan, millaisissa koneissa se oikein pyörii? Vähintään outo tapa toimia. Luulisi, että kehitysvaiheessa on jonkinlainen ajatus siitä, missä sitä softaa tullaan käyttämään, mikä on sen käyttäjäryhmä, ja sen mukaan sitten asetetaan vaatimuksia.

Tai sitten tarkoitit jotain ihan muuta, mitä en tajua, joten avaatko lisää.
Tyypillisesti koodarin näkemys rajoittuu siihen moduuliin tai sen osaseen jota oltiin säätämässä. Tämän osan vaatimukset ovat varmasti hyvin hanskassa, mutta dependenssit sitten muualle ovat hämärän peitossa. Jos puuhaillaan vähänkin monimutkaisemman softan kanssa hiemankaan isommassa organisaatiossa, niin tämä on arkipäivää.
Siksi on QA. QA voi toki olla (ja pitääkin olla) osa kehitystä siten, että osallistuvat koodin tekemiseen, mutta kyllä tuotteen laadun varmistukseen pitää olla vastuullinen organisaatio (vaikka yksi ihminen vaihtuvalla hatulla jos ei muuta).
Monessa paikassa lisäksi kehittäjien testausvastuu tuntuu rajoittuvan yksikkötestaamiseen. Onhan tämä toki tärkeää, mutta ei sillä kokonaisuutta testata. Kun mennään monimutkaisempiin kokonaisuuksiin, aikaa rupeaa palamaan ihan eri tavalla verraten aiempaan, joten monesti on ihan järkevääkin laittaa testaamisen ammattilainen asialle ja käyttää sen kehittäjän ammattitaitoa sitten johonkin, jossa tämä on tuottavimmillaan.

Ja ei QA:n olemassaolo tarkoita mitään vesiputousmallia. Tuotetta voi kyllä testata vaikkei se olisi valmiskaan.
 
Liittynyt
25.10.2016
Viestejä
120
Osaako kukaan sanoa onko Kela millainen työnantaja IT-puolella? Nihkeästi löytyy netistä tietoa nimenomaan IT puolesta. Onko millaiset työolot/palkkaus?
 
Liittynyt
21.09.2017
Viestejä
352
Wut? Softan kehittäjä ei tyypillisesti tiedä, millaisia vaatimuksia softalle on asetettu? Tuo kuulostaa todella oudolta. Miksei devaaja ota tästä selvää? Miksei vaatimuksia kommunikoida devaajille, jos sellaiset on olemassa?
Yleensä sellaisia ei ole edes olemassa, jos tehdään usealle asiakkaalle. Tällöin tehdään vain oletuksia "no kai se asiakas nyt käyttää edes läppäritasoista rautaa". Lopputuloksena on jotain aivan muuta, itsekin olen useamman bugiraportin käynyt läpi ettei jokin operaatio koskaan valmistu. Sitten kun katsotaan logia niin siellä on tapauksia kuten SAN-ympäristö tai AWS jossa saadaan diskettiaseman vauhdilla luettua dataa. Ei ihme että tietokantaoperaatioissa kestää.

Aina pitäisi toki olettaa että hakee 80-luvun raudan kaapista ja softan pitää silläkin toimia. Se tosin ei kiinnosta niitä jotka odottavat että softa tulee myyntiin. Jotain yleensä näissäkin asioissa mennään olettamuksilla, jotka jokaisella osapuolella on erilaiset. Eikä kyse ole ikinä pelkästään suorituskyvystä, vaan kaikesta softaan liittyvästä - suurin osa spekseistä sisältää aina oletuksia ja epämääräisyyksiä.
 
Liittynyt
19.12.2016
Viestejä
62
Osaako kukaan sanoa onko Kela millainen työnantaja IT-puolella? Nihkeästi löytyy netistä tietoa nimenomaan IT puolesta. Onko millaiset työolot/palkkaus?
Pari tuttua vaihtanut hektisestä konsulttimaailmasta Kelalle. Jos konsulttielämä on tuttua, niin Kela on sitten päinvastainen: palkka huonompi, kiirettä ei ole, mennään by-the-book, byrokratian määrä on huima, kankea, pitkät lomat...

Eli on hyvää ja on huonoa. Ilmeisen tyypillinen virkamiesmeininki.

Pikaedit: nuo siis tuttujen kommentteja mitä ovat kertoneet. Omakohtaista kokemusta ei ole.
 
Liittynyt
30.04.2019
Viestejä
35
Pari tuttua vaihtanut hektisestä konsulttimaailmasta Kelalle. Jos konsulttielämä on tuttua, niin Kela on sitten päinvastainen: palkka huonompi, kiirettä ei ole, mennään by-the-book, byrokratian määrä on huima, kankea, pitkät lomat...

Eli on hyvää ja on huonoa. Ilmeisen tyypillinen virkamiesmeininki.

Pikaedit: nuo siis tuttujen kommentteja mitä ovat kertoneet. Omakohtaista kokemusta ei ole.
Samanlaista olen kuullut. Joskin etätyömahdollisuudet vissiiin aika hyvät jos semmosta halajaa
 
Liittynyt
03.11.2016
Viestejä
328
Missä it-työssä ylipäätään on vuonna 2020 huonot etätyömahdollisuudet? Taitaa olla harvinaisempaa että etätyö ei onnistuisi, kuin että onnistuu
Omassa tämänhetkisessä työpaikassa (50+ ihmistä) oltiin ennen koronaa hieman nihkeitä etäilyä kohtaan ja kaverini firma (500+ ihmistä) ei ennen koronaa sallinut etäilyä hänen osastollaan ollenkaan. Kyllä Suomestakin löytyy vielä monta vanhoihin ajatuksiin jämähtänyttä yritystä.

Omassa firmassa ollaan ilmeisesti nyt avaamassa etämahdollisuudet yleisemmin, koska huomattiin, että sairauspoissaolot vähenivät ja laskutettujen tuntien määrä kasvoi. Tämä tuli yllätyksenä varmasti vain johdolle.
 
Liittynyt
18.10.2016
Viestejä
1 610
Missä it-työssä ylipäätään on vuonna 2020 huonot etätyömahdollisuudet? Taitaa olla harvinaisempaa että etätyö ei onnistuisi, kuin että onnistuu
Riippuu mitä etätyöllä tarkoittaa. Jos kyse on siitä että joskus voisi ottaa etäpäivän niin lienee onnistuu melkein aina, mutta itse en ole vielä koskaan nähnyt suomalaista softafirmaa jossa voisi säännöllisesti etäillä esim. 1-2 päivää joka viikko tai kokonaan.
 
Liittynyt
26.06.2018
Viestejä
200
Omassa tämänhetkisessä työpaikassa (50+ ihmistä) oltiin ennen koronaa hieman nihkeitä etäilyä kohtaan ja kaverini firma (500+ ihmistä) ei ennen koronaa sallinut etäilyä hänen osastollaan ollenkaan. Kyllä Suomestakin löytyy vielä monta vanhoihin ajatuksiin jämähtänyttä yritystä.
Myös minun nykyisessä työpaikassa oltiin hyvin nihkeitä. Meni pitkään, että edes korona-aikana sai tehdä etänä. Nyt jo palattu de-facto tilaan, kaikki toimistolla. Tiukin linja mihin itse olen törmännyt. Ylintä johtoa harvoin näkyy (nyt ei ollenkaan), mutta muiden pitäisi puuhata reippaina konttorilla.

Satunnaisesti päivä silloin tällöin on ollut aika yleinen muualla. 1-2 säännöllistä päivää vähän kuin erikoistapauksina sovittuna joissain paikoissa. Pääasialliseen etäilyyn en ole missään itse törmännyt. Joitain tunnen jotka tehneet ison osan viikosta esim. etänä pääkaupunkiseudulle ja kulkeneet paikalle osaksi viikkoa. Mutta nämä harvinaisia tapauksia.

Sitten on tietenkin kaverit jotka on olleet sen 10+ vuotta samoissa hommissa ja oppineet pyörittämään kuvioita siinä ympäristössä. Manageri enimmät ajat mökillä tms, seniori setämies pari päivää viikossa "etänä", yms, yleisiä kuvioita.

Tuota satunnaisen etäilyn selkeää integroimista työkulttuuriin ja siihen hyviä mahdollisuuksia toivoisi enemmänkin. Korona-aikaan kyllä huomasin, että kaikille ei oikein jatkuva etäily sovi ja pitäisi istua konttorilla. Toisten kanssa menee OK, mutta jatkuva viikkojen etäily menee vaikeaksi. Edes se päivä viikossa olisi hyvä samalla konttorilla jos ei muuten.
 
Liittynyt
02.08.2018
Viestejä
595
Ainakin näissä pienemmissä "kuumissa" IT-alan paikoissa etätyö onnistuu ja saa tehdä niin paljon kuin itse parhaaksi näkee. Siis Reaktori, Vincit, jne.
 
Liittynyt
18.10.2016
Viestejä
35
Ainakin näissä pienemmissä "kuumissa" IT-alan paikoissa etätyö onnistuu ja saa tehdä niin paljon kuin itse parhaaksi näkee. Siis Reaktori, Vincit, jne.
Työnantajan puolesta toki, mutta sitten asiakkailla saattaa joskus olla täysin eri mentaliteetti ja silloin ei välttämättä etäillä yhtään, tai ainakin vaatii paljon pelisilmää
 
Liittynyt
05.02.2017
Viestejä
4 277
Itse olen ollut kahdessa työpaikassa, joissa etätyö on ollut laajasti käytössä aiemminkin. Itse en aiemmin nykytyöpaikassa tehnyt etätyötä ollenkaan, ja konttorilla oli ehkä 33% täyttöaste, koska väki oli etänä (osa oli toki palavereissa tai eri toimipisteessä). Kyseessä iso kotimainen konserni.
 
Liittynyt
19.10.2016
Viestejä
306
Näinpä, jos asiakas haluaa että konsultti on heidän toimistollaan niin sitten on, tai jää sopimus tekemättä.
 
Liittynyt
03.11.2016
Viestejä
328
Näinpä, jos asiakas haluaa että konsultti on heidän toimistollaan niin sitten on, tai jää sopimus tekemättä.
Tätä työtä jonkin verran tehneenä, ihmettelin aina että miksi ihmeessä minut halutaan sinne paikanpäälle kököttämään. Minun kannalta se oli tietysti hyvä diili, koska sain palkan matka-ajalta, kilometrikorvaukset ja päivärahat.
 
  • Tykkää
Reactions: hmb
Liittynyt
18.10.2016
Viestejä
1 610
Ainakin näissä pienemmissä "kuumissa" IT-alan paikoissa etätyö onnistuu ja saa tehdä niin paljon kuin itse parhaaksi näkee. Siis Reaktori, Vincit, jne.
Olin itse aikoinaan Reaktorilla töissä ja työn luonne on aika pitkälti "projekteja tehdään asiakkaan toimistolla asiakkaan tiimeissä", joten säännöllinen etäily oli käytännössä mahdottomuus ellei se asiakkaalle kelvannut.
 
  • Tykkää
Reactions: hmb
Liittynyt
15.04.2020
Viestejä
8
Jotkut asiakkaat myös haluavat että työt tehdään kotoa käsin eikä tulla asiakkaan toimistolle.

Itse en ole tänä vuonna työpaikalla käynyt ja viime kerrasta asiakkaalla on kulunut viisi kuukautta.

Viime vuonna kävin työpaikalla viisi kertaa palaverissa. Turha käyttää puolta tuntia aikaa keskustaan ajeluun ja pysäköintipaikan etsimiseen.
 
Liittynyt
17.10.2016
Viestejä
4 665
Riippuu myös täysin tilanteesta. Joskus säännöllinen kommunikointi asiakkaan kanssa on pelkkää plussaa, joskus on selvät sävelet kaikilla ja tehokkuuden kannalta on parempi tehdä hommat kotona rauhassa. Paras tilanne, jos sekä työnantaja että asiakas ovat siinä määrin joustavia, että etäily onnistuu tarvittaessa ilman kummempaa byrokratiaa. Mä veikkaan, että korona on ollut hyvä oppitunti tässä mielessä ja niinpäin, että on huomattu, että hommat etenee vaikka fyysisesti ollaan koko ajan eri paikoissa.
 
Liittynyt
25.01.2018
Viestejä
187
Itselläni on tuttuja koodiorjina ja heillä on kaikilla lupa tehdä jatkossakin etätöitä useampi päivä viikossa. Mutta he eivät olekaan töissä missään muodikkaassa alihankintaputkassa vaan yrityksissä joissa kehitetään omia tuotteita. Eräs näistä on pörssiraketti ja toinen muuten vain kaikkien tuntema. Eli etätyömahdollisuudet riippuvat firmasta ja ansaintamallista. Se joka loppupeleissä maksaa palkan päättää miten toimitaan.
 
Liittynyt
06.11.2016
Viestejä
81
Viimeksi helmikuussa olen ollut toimistolla ja ainoa haaste on minusta Scrumin Retrospektiivien pitaminen. MS Whiteboardilla on etana vaikea porukkaa saada innomoimaan parannuksia tyon tekemiseen samalla tavalla kuin neukkarissa kovassa ryhmapaineessa post-titseja revitellessa.
Etana oleminen ei ole kylla sitten vaikuttanut mihinkaan muuhun.
 
Toggle Sidebar

Statistiikka

Viestiketjut
89 832
Viestejä
1 838 319
Jäsenet
39 065
Uusin jäsen
Nik_kari

Hinta.fi

Ylös Bottom