DevOps = one man army?

[Gunn4]

Ik zat even te twijfelen waar ik dit topic zou moeten plaatsen. Ik heb hem nu hier gezet omdat het vooral over carriereadvies ging, maar mocht het verkeerd staan, mea culpa.

De afgelopen jaren is alles DevOps wat de klok slaat. Elk bedrijf waar ik terecht ben gekomen is volledig over op DevOps. Geen loketjes, kortere lijntjes, niet meer simpelweg over-de-schutting-gooien, oftewel fantastisch. Echter… ik vind het in de praktijk maar ruk voor mij als ontwikkelaar.

Vroegâh, was ik "gewoon" software ontwikkelaar en hield ik me bezig met Java, object-oriented programming, design patterns, frameworks (Spring, Hibernate), applicatie servers, build-servers (Jenkins), databases, etc. Ik vond het super leuk om me hierin te verdiepen en mij deze kennis machtig te maken. Om steeds beter te worden. Om expert te zijn over deze onderwerpen en écht te snappen waar je mee bezig bent.

Tegenwoordig lijkt het wel alsof elk bedrijf DevOps interpreteert als “elk teamlid moet alles kunnen doen, van bouw tot beheer”. Naast alle bovenstaande dingen, moet je nu ook expert zijn op cloud infra, provisioning, gitops, kubernetes/docker, monitoring, logging, dashboards, etc. De benodigde kennisinvestering is echt enorm toegenomen en het ergste is nog dat bij een volgend project alle tools die je al kent alweer gedateerd zijn en je weer opnieuw kan beginnen.

Een veel gehoord tegenargument is dat je kennis niet geheel verloopt, maar dat de concepten die je hebt geleerd hetzelfde blijven. Dit is niet mijn ervaring: als je overgaat van AWS naar Azure ben je echt nog wel even zoet met leren.

Het is niet dat ik elk individueel onderdeel niet interessant zou vinden, maar het gaat erom dat het allemaal bij elkáár gewoon veels te veel is. Ik voel me overweldigd door de wirwar aan tools en acroniemen, en zodra je het een beetje door lijkt te hebben mag je weer opnieuw beginnen omdat ze zo nodig moeten migreren naar the-next-best-thing. Je kunt door de brede scope van technieken die je moet kennen alles maar oppervlakkig begrijpen, waardoor je nooit meer echt de expert kunt zijn op een gebied.

Ik zou me graag gewoon meer specialiseren op Java ontwikkeling, maar deze opdrachten zie ik (in zowel detachering / zzp) gewoon niet meer langskomen. Overal zijn ze op zoek naar de duizendpoot die alles kan waar voorheen een heel IT-afdeling mee bezig was.

Voor de software ontwikkelaars op dit forum: wat is jullie ervaring hiermee en hebben jullie nog tips?

[NimbleGenius]

Nee, sorry. Dit is zo herkenbaar! ik ben erg benieuwd naar de reacties.

[GarBaGe]

Bedrijven kunnen vragen wat ze willen, toch?
Ik zou me daar niet te druk om maken.
In de praktijk zie ik verschillende software engineers verschillende passies hebben.
De 1 meer in FE, de ander meer in infra of k8s.
Daarom is het hebben van een gemixed team altijd goed.
Niet iedereen kan alles, maar je wilt wel meerdere mensen hebben voor de individuele onderdelen.
Om te voorkomen dat als 1 persoon ziek is, de deployment naar productie ineens stil ligt....

[mannowlahn]

Welke tools zijn volgens jou dan zo snel gedateerd. Devops is redelijk stabiel. Idd Aws is andere koek dan azure dus logisch dat dit anders is. Maar je bent tegenwoordig niet alleen een developer, het is idd nu veel breder. In principe hoort devops bij een hoop technische functies.

[Devian]

Binnen de telecom heb ik ook in een DevOps model gewerkt.

Dit betekende echter niet dat ik alles moest kunnen. Bij ons betekende dat dat alle disciplines, van design naar bouw naar opleveren en daarna operationeel beheer, onder de zelfde afdeling viel.

Dus inderdaad geen eilandjes meer.

Er was vervolgens een onderscheid gemaakt in bvb een access afdeling, een core afdeling, etc etc. En zon afdeling was dan end to end verantwoordelijk voor alles.

Was erg fijn werken, en ik kon mij juist meer specialiseren.

[r.e.s]

DevOps wordt vaak matig geïmplementeerd, men schuift het beheerteam bij het ontwikkelteam laat ze een introductie agile doen en voile je hebt een agile DevOps team. Er is geen tijd om de functioneelbeheerder te leren ontwikkelen en de programmeur wordt doodongeluk van het oplossen van tickets. Gevolg, men houdt nog steeds hun oude primaire rollen aan en in de vakanties wordt er wat vanaf geprutst omdat de kennis ontbreekt.

[Frame164]

Gunn4 schreef op woensdag 17 juli 2024 @ 16:00:

Tegenwoordig lijkt het wel alsof elk bedrijf DevOps interpreteert als “elk teamlid moet alles kunnen doen, van bouw tot beheer”.

Dat is een verkeerde interpretatie van devops. Devops betekent dat alles door 1 team wordt gedaan waarin ieder teamlid z'n eigen specialisme heeft. Maar wel zodanig dat je ook zaken buiten je eigen specialisme kunt oppakken. Zo kan een developer ook wel eens worden ingezet als tester voor de code van een ander teamlid. Of help je met troubleshooten van operationele problemen. Maar je hoeft geen expert troubleshooter te zijn, maar als developer weet je hoe de code in elkaar zit dus je kunt bepaalde problemen waarschijnlijk eerder vinden dan als een operationeel beheerder dat moet gaan uitzoeken, een TT schrijven die jij dan weer moet begrijpen en omdat je elkaars competenties niet snapt er weer zaken tussen wal en schip vallen.

En het voordeel hiervan is dat je inderdaad kortere lijntje hebt en doordat je ook eens wat anders doet je snapt wat anderen (in feite je interne klanten) nodig hebben.

Als een bedrijf het zo heeft ingericht dat 1 persoon alles moet kunnen en overal expert in moet zijn hebben ze het niet begrepen.

[Gr4mpyC3t]

Gunn4 schreef op woensdag 17 juli 2024 @ 16:00:
Ik zat even te twijfelen waar ik dit topic zou moeten plaatsen. Ik heb hem nu hier gezet omdat het vooral over carriereadvies ging, maar mocht het verkeerd staan, mea culpa.

De afgelopen jaren is alles DevOps wat de klok slaat. Elk bedrijf waar ik terecht ben gekomen is volledig over op DevOps. Geen loketjes, kortere lijntjes, niet meer simpelweg over-de-schutting-gooien, oftewel fantastisch. Echter… ik vind het in de praktijk maar ruk voor mij als ontwikkelaar.

Vroegâh, was ik "gewoon" software ontwikkelaar en hield ik me bezig met Java, object-oriented programming, design patterns, frameworks (Spring, Hibernate), applicatie servers, build-servers (Jenkins), databases, etc. Ik vond het super leuk om me hierin te verdiepen en mij deze kennis machtig te maken. Om steeds beter te worden. Om expert te zijn over deze onderwerpen en écht te snappen waar je mee bezig bent.

Tegenwoordig lijkt het wel alsof elk bedrijf DevOps interpreteert als “elk teamlid moet alles kunnen doen, van bouw tot beheer”. Naast alle bovenstaande dingen, moet je nu ook expert zijn op cloud infra, provisioning, gitops, kubernetes/docker, monitoring, logging, dashboards, etc. De benodigde kennisinvestering is echt enorm toegenomen en het ergste is nog dat bij een volgend project alle tools die je al kent alweer gedateerd zijn en je weer opnieuw kan beginnen.

Een veel gehoord tegenargument is dat je kennis niet geheel verloopt, maar dat de concepten die je hebt geleerd hetzelfde blijven. Dit is niet mijn ervaring: als je overgaat van AWS naar Azure ben je echt nog wel even zoet met leren.

Het is niet dat ik elk individueel onderdeel niet interessant zou vinden, maar het gaat erom dat het allemaal bij elkáár gewoon veels te veel is. Ik voel me overweldigd door de wirwar aan tools en acroniemen, en zodra je het een beetje door lijkt te hebben mag je weer opnieuw beginnen omdat ze zo nodig moeten migreren naar the-next-best-thing. Je kunt door de brede scope van technieken die je moet kennen alles maar oppervlakkig begrijpen, waardoor je nooit meer echt de expert kunt zijn op een gebied.

Ik zou me graag gewoon meer specialiseren op Java ontwikkeling, maar deze opdrachten zie ik (in zowel detachering / zzp) gewoon niet meer langskomen. Overal zijn ze op zoek naar de duizendpoot die alles kan waar voorheen een heel IT-afdeling mee bezig was.

Voor de software ontwikkelaars op dit forum: wat is jullie ervaring hiermee en hebben jullie nog tips?

Ja, ik snap heel goed waar je vandaan komt. Wat @Frame164 ook al aangeeft: de interpretatie van DevOps is nogal vloeibaar bij veel bedrijven. Een lekker buzz word en daarom ook zo populair.

Een DevOps team is in staat om op alle facetten te opereren, maar dat betekent niet dat iedereen alles moet kunnen. Daar gaat het mis. Het bedrijfsleven zou in zijn eigen context moeten bepalen wat een DevOps-team is en welke kennis & expertise er binnen het team nodig is. In mijn context is dat samen werken aan een gezamenlijk doel met gebundelde expertise. Maar je draait je hand er ook niet voor om ook 'af en toe' wat te doen buiten je expertisegebied.

Overigens lees ik wel iets typisch 'DevOps' terug in je tekst. Je geeft aan dat je met applicatie- en buildservers aan de gang bent geweest i.c.m. Jenkins. Hartstikke waardevol.

Mijn tip voor nu is om lekker het gesprek aan te gaan bij bedrijven die je interessant lijken. Vraag goed door op wat 'DevOps' nou betekent en welke werkzaamheden er bij horen. Als de antwoorden te vaag zijn of niet passen in jouw straatje, dan is het geen bedrijf voor jou.

[boxlessness]

r.e.s schreef op woensdag 17 juli 2024 @ 16:49:
DevOps wordt vaak matig geïmplementeerd, men schuift het beheerteam bij het ontwikkelteam laat ze een introductie agile doen en voile je hebt een agile DevOps team. Er is geen tijd om de functioneelbeheerder te leren ontwikkelen en de programmeur wordt doodongeluk van het oplossen van tickets. Gevolg, men houdt nog steeds hun oude primaire rollen aan en in de vakanties wordt er wat vanaf geprutst omdat de kennis ontbreekt.

Dat is optimistisch... er was uberhaupt een beheerteam om te schuiven?
Bij ons niet... wij moeten het maar zelf uitvogelen.

- alsjeblieft, hier is je cloud subscription, make stuff happen.
- wat? Je kunt alleen maar wat backend programmeren, Jenkins, en databases? Cloud is toch hetzelfde! Ook iets met computers! Komt goed! Frontendje kun je er ook wel ff bijpakken toch? Je hebt wel eens laten weten dat je UX wel interessant vindt.

... jaar later ...

- waarom duurt het allemaal toch zo lang? En lopen onze cloud kosten uit de klauwen? En ligt onze data op straat?

Het probleem is dat er soms een hele brede technische basis gevraagd wordt, en de (impliciete) verwachting is dat over die hele brede technische basis ook nog eens kwalitatief hoogwaardige projecten neergezet worden. En dat allemaal misschien ook nog eens onder tijdsdruk, en met minimale training.
De complexiteit wordt naar mijn ervaring niet gezien.
En full-stack/devops is gewoon heel veel. Wanneer je een 13-in-een-dozijn backend/frontend/service in elkaar klust wel te doen... maar wanneer er ook nog eens auth, andere API's, integratie met backoffice software, BI-tooling, monitoring, containers, microservices, kafka, VPN tunnels en data standaarden bij komen; dan is het gemakkelijk verzuipen... en laten we niet vergeten dat voldoen aan de AVG ook opgelost moet worden door het technische team. En vooral niet vragen wat de "actoren" en "interacties" met het systeem zijn... want dat moet het team maar uitzoeken in hun "architectuur"... oh, en kun je nog even die gebruiker toevoegen en mijn dashboard password resetten want dat ben ik weer vergeten.

Maar, zoals gezegd hierboven is de definitie van Devops over bedrijven heen nogal vloeibaar. Mijn ervaring is vooral dat het Devops team de dumpplek is voor alles wat ook maar enigsinds technisch/complex is.

Zelf heb ik de strategie om steeds minder variatie in tech te gebruiken, tenzij strikt noodzakelijk. Dat geeft mij meer focus. Zo gebruik ik steeds meer Linux containers/registries (e.g. Docker, ga binnenkort eens kijken naar Podman) om mijn development, build pipeline, deployment en versioning mee te regelen. Mijn doel is in plaats van iedere keer kort/oppervlakkig met allerlei cloud/services/tools te werken, dat ik met containers dan meer diepgaande kennis kan opbouwen omdat ik er dagelijks mee werk.

Men roept vaak "use the best tool for the job", maar ik ben er inmiddels uit dat "the best tool for the job, is the tool that you know". En de enige manier om je tools goed te leren kennen is door ze (bijna) dagelijks te gebruiken. En wanneer je te dun bent uitgesmeerd over alle tools/technieken, leer je er geen één. Dus ik ben vanalles uit mijn gereedsschapskist aan het smijten.

En specifiek het functioneel beheer gedeelte van Devops probeer ik zo ver mogelijk van weg te blijven. Tot nu toe lukt dat redelijk.

[dhr.robert]

In principe moet DevOps ook inhouden dat het team veel autonomie heeft. Dat betekent dus dat het team tools selecteert (binnen bepaalde kaders uiteraard), een eigen rolverdeling kan afspreken, zelf het werk visualiseert en inschat, werk weigert wat niet bij het team past etc. De scrum master of agile coach is daarin faciliterend. De Product Owner bepaalt wat er gemaakt moet worden, niet hoe het team dat moet doen.

Op het moment dat anderen (vaak managers) dingen gaan opleggen aan dergelijke teams wordt het concept niet goed ingevuld. Hoe gaat dat nu precies? Kan je voorstellen doen met het team? Zijn er mensen van buiten het team die zaken opleggen?

[useruser]

Een bedrijf zoekt altijd iemand die alles kan, en het liefste gratis. Gewoon niet te druk om maken en lekker solliciteren bij een mooie toko en werk doen waar je blij van wordt.

[Ahrnuld]

Ik denk dat de mensen bij de bedrijven waar de TS kijkt eens het boek Team Topologies moeten lezen, daar staat e.e.a. vrij netjes uitgewerkt in een taal die ook niet-devs moeten snappen.

Want ja, je moet zuinig zijn op tijd/leervermogen/cognitieve capaciteiten van je developers. Dat is imo een beetje het centrale issue waar het managen van development teams om draait: zorgen dat mensen op zo'n manier bezig zijn dat ze zoveel mogelijk waarde kunnen toevoegen met zo min mogelijk moeite.

Maar het is wel zo dat cloud/infra een vast onderdeel is geworden van de gereedschapskist van een developer. In ieder geval op conceptueel niveau zal je containerization en serverless en alles wat daarbij hoort moeten snappen. Dieper ingaan op AWS, Azure of alle specifieke tools voor in je pipelines of monitoring lijkt me dan meer iets voor individuele teamleden om zich in te specialiseren.

Ik werd overigens zelf ook niet gelukkig van de inhoud van devops vacatures, ook al geef ik er les in. 90% van wat ik langs heb zien komen lijkt mij echt niet leuk om te doen als werk. Het is inderdaad wat anderen ook al zeggen: de verwachtingen in vacatures zijn vaak onrealistisch. Terwijl wat ik in de praktijk zie veel simpeler is.

[ Voor 19% gewijzigd door Ahrnuld op 18-07-2024 10:27 ]

[gr8-jen]

Gunn4 schreef op woensdag 17 juli 2024 @ 16:00:

....

Hier een ontwikkelaar die na 13 jaar overging naar alleen DevOps

Ik herken wel een beetje wat je bedoelt, maar dat is niet wat de bedoeling is. Het zou als team opgelost moeten worden, waarbij minstens 2 mensen ergens heel veel vanaf weten en de rest ergens basiskennis van heeft. Dat heb ik eigenlijk maar op 1 plek gezien en dan vanaf de zijlijn bij een ander bedrijf

Mocht je geen zin hebben in het fixen van een langzame build of waarom een pod crashed of hoe je nu weer dat kubernetes cluster moet updaten, geen probleem daar ben ik voor.
Maar als ik Redis wil updaten naar een andere versie, ga ik niet alle deprecations langs in alle repo's. Dan maak ik een story aan en mag een ontwikkelaar uitzoeken of het in de applicatie wordt gebruikt.

In het ideale geval ga ik mij wat meer bezighouden met wat er intern draait in de applicatie en proberen ze globaal te snappen hoe de CI/CD straat globaal werkt, maar alles 100% snappen nee.

Ik weet ook even niet waar je het vandaan haalt dat alles direct naar een andere provider gaat zodra je het snapt. Dit heb ik nog niet meegemaakt en ik weet ook niet waarom een bedrijf zoveel geld zou willen weggooien. Bij een multinational heb ik wel gezien dat ze het gedeelte dat cloud specifiek is loshalen van de rest zodat ze 2 of meer providers kunnen gebruiken voor hosten. Maar ook dan zijn er meerdere mensen met kennis van de ene provider en andere mensen van de andere. Dat mix je gewoon niet.

En waar ik nu werk ben ik ook begonnen met 0% kennis van de tools die ze gebruikten en wilden gaan gebruiken. Toch kon ik gewoon soliciteren en ben ik aangenomen. Ze zoeken het het schaap met 5 poten maar die bestaat niet.

[Sito]

Het hele nadeel van DevOps is dat het echt een buzzword is. Bedrijven horen prachtige verhalen van andere bedrijven die DevOps succesvol hebben geïmplementeerd met een verhoging van KPI x en y.

Vervolgens willen ze dat zelf ook, maar in plaats van het fatsoenlijk aanpakken en eventueel een consultant in te huren die een plan maakt hoe DevOps het beste geïmplementeerd kan worden, gooien ze er een smak geld tegenaan in de vorm van een cloud subscription en dopen ze een team om tot Agile team.

Het team heeft geen idee wat ze moeten doen en wat er van hun verwacht wordt. Het management heeft geen idee wat DevOps nou écht is en verwacht dat het team dit zelf oppakt. Conclusie: frustratie aan beide kanten, want DevOps werkt niet en het slaat nergens op.

Als je DevOps goed weet op te pakken is het enorm waardevol. Maar daar is effort en commitment voor nodig. Wellicht zelfs tijdelijk minder productiviteit of omzet. En dat is wat veel bedrijven niet willen.

[Furion2000]

Wat @Sito zegt is denk ik waarom zoveel werksoorten zo hard falen. Een wij vs zij cultuur, technici vs spreadsheet management, directe kosten/winst vs lange termijn denken. Mijn n=1 is dat het dus daar echt aan allebei de kanten ligt waarom 'iets' fout gaat. Toxic werkcultuur wat mij betreft. Meest gevaarlijke mensen zijn diegene die het hoogst van de toren blazen en de sterkste mening hebben. Je hebt ze veel in management, maar evengoed ook van die one man army profeet devs (vaak een clubje aanbidders er rondom heen) die echt heel goed zijn en magische code schrijven maar als een kaartenhuis in elkaar valt zodra de profeet verder gaat.

Management moet niet besluiten om DevOps te gaan doen, Devvers moeten dat zelf niet doen, maar iedereen moet bij het plan aanwezig zijn om iets te doen. Als iedereen het begrijpt en er winst uit haalt dan is er eigenlijk geen reden meer om het niet te doen. Daarnaast zijn er bijv. ontwikkelaars en managers die excelleren met een DevOps werkwijze maar als je daar 5 jaar lang verkeerde poppetjes bij zet dan kan het weer helemaal mis gaan. Daarom is HR toch ook weer best belangrijk.

Ik vind DevOps geen buzzword, DevSecOps vind ik ook interessant en het kan mij niet breed genoeg omdat jack of all trades master of none bij mij past. Ik bouw graag complete applicaties en wil het graag begrijpen. Het is veel, erg veel soms om het allemaal te bevatten, maar de nieuwsgierigheid wint steeds. We hebben ook een aantal specialisten op de afdeling en die zijn ook erg waardevol, maar de focus bij dit alles ligt op automatiseren zodat er meer tijd over blijft voor verdere verbeteringen. Dat automatiseren gaat gewoon enorm snel als je controle/inzicht hebt over de gehele keten.

Waar ik nu op de release button druk dan doe ik dat zonder enige vorm van angst en kan ik zelf debuggen waar nodig en snel handelen. Ik heb ook ervaring dat ik iets releastte en het compleet mis ging en een week lang met een $#@gevoel rondliep en op een technisch beheerder zat te wachten

Bij ons kan een senior teamlid gewoon bij een pipeline story zeggen - daar snap ik niks van en kan henk dat niet beter doen. Vice versa doet henk dat bij een frontend story. De werkcultuur accepteert dat gewoon.

Daarnaast heeft iedereen zijn uitdagingen, want onze afdeling gaat weer heel slecht op lange termijn visie van architecten die soms ook de tooling willen bepalen. Dan krijg je exact hetzelfde probleem als wat @Sito zegt (een wij - zij verhouding) en zodra 'zij' verdwijnen verdwijnt het idee met hen mee. Dit soort dingen moet van iedereen zijn.

Op elk potje past een dekseltje en ik denk dat TS als backend dev ook prima kan functioneren in een DevOps team waar ook wat manusjes van alles in zitten. En het word dus 'prima' wanneer men goed communiceert en verwachtingen managed. Natuurlijk moet je dan wel begrijpen dat je in gesprek met een HR miep ietwat moet overdrijven over je hele brede kennis zodat je daar doorheen komt en vervolgens in het gesprek met de developers zorgen dat je het bovenstaande helder krijgt

[ Voor 12% gewijzigd door Furion2000 op 18-07-2024 11:52 ]

[SPee]

gr8-jen schreef op donderdag 18 juli 2024 @ 10:19:
[...]
Ik herken wel een beetje wat je bedoelt, maar dat is niet wat de bedoeling is. Het zou als team opgelost moeten worden, waarbij minstens 2 mensen ergens heel veel vanaf weten en de rest ergens basiskennis van heeft. Dat heb ik eigenlijk maar op 1 plek gezien en dan vanaf de zijlijn bij een ander bedrijf

Het is pas een goede mix als dat wisselt tussen onderwerpen.
Maar als er ergens 2 mensen alles afweten van de gebruikte tooling en de rest maar bij basiskennis blijft, dan gaat er ergens iets mis. Die 2 zouden ook bij bepaalde onderwerpen een hulplijjn moeten kunnen gebruiken.
Als alleen die 2 bij elk probleem mogen opdraven, dan heb je een SPOF met hoog risico dat je die in de nabije toekomst kwijt raakt.
Je merkt ook vaak dat het "steeds weer dezelfde" zijn. En dan heb je niet echt een team.

[Kwistnix]

Organisaties zijn altijd wel opzoek geweest naar eenhoorns en de volledig uitwisselbare FTE. Voor "DevOps" was het "'full-stack". Wanneer je als organisatie op die manier naar je IT personeel kijkt, dan begrijp je maar bar weinig van hoe softwareontwikkeling en beheer werkt. Het landschap is te breed en er zijn over de hele linie teveel (met recht) specialismen.
Met DevOps zonder aanhalingstekens vind ik persoonlijk niet zo veel mis. Ik hou wel van korte lijntjes en alle kennis in een team om ontwikkeling en beheer te doen, zonder zuilen, muren en papierwinkel, is wat mij betreft redelijk ideaal.

[Furion2000]

SPee schreef op donderdag 18 juli 2024 @ 12:18:
[...]

Het is pas een goede mix als dat wisselt tussen onderwerpen.
Maar als er ergens 2 mensen alles afweten van de gebruikte tooling en de rest maar bij basiskennis blijft, dan gaat er ergens iets mis. Die 2 zouden ook bij bepaalde onderwerpen een hulplijjn moeten kunnen gebruiken.
Als alleen die 2 bij elk probleem mogen opdraven, dan heb je een SPOF met hoog risico dat je die in de nabije toekomst kwijt raakt.
Je merkt ook vaak dat het "steeds weer dezelfde" zijn. En dan heb je niet echt een team.

Ik denk dat een goed op elkaar ingespeeld team toch altijd wel neigt naar 'jij doet dit en ik doet dat' en daar hoeven we niet over te communiceren. Dat is wat mij betreft een groot deel van teamwork. Natuurlijk moet er ook een gevoel heersen van als henk dood neer valt kunnen we het schip nog steeds laten varen. Misschien even wat langzamer, maar het blijft varen.

Zelfde met SPOF. Ik gebruik het argument ook vaak om even tijd te pakken voor wat kennisoverdracht - maar voor echte SPOF ben ik eigenlijk nooit bang. Iemand moet even wat tijd pakken om het uit te gaan zoeken vanaf scratch, maar het blijft code. Soms doen we net alsof het een black box is waar je nooit meer uit gaat komen. Als we dat doen om een product owner een bepaalde keuze te laten maken, afijn

[SPee]

Het is niet (altijd) code.
Het is ook configuratie, authenticatie en processen. En juist daar wordt te weinig van gedocumenteerd. Of rechten zijn enkel aan die specifieke personen gegeven. Voor code heb ik geen problemen, wel meer met "hoe deed Henk dit" of "enkel Henk mag sudo-en".

[defiant]

Het probleem is dat DevOps net zoals Agile als een abstract concept een eigen invulling krijgt in organisaties. Het was ooit bedoelt om een communicatie en afstemming problemen op te lossen tussen het ontwikkelen en beheren van software. Het heersende probleem was dat beheerders het "over de schutting" gooien van software terwijl aan de andere kant developers juist weinig wisten van infrastructuur het proces verstoord.

In principe is met die observatie niets mis, het was een probleem in veel organisaties, maar er zit nogal een verschil tussen deze visies op DevOps:

1. Developers werken in een continuous deployment omgeving en deployen zelf naar productie. Beheerders onderhouden nog steeds de infrastructuur en hebben daar kennis van.
2. Van developers wordt verwacht dat ze niet alleen programmeren, maar ook kennis hebben hoe infrastructuur werkt en dit zelf kunnen beheren en onderhouden. Er zijn geen beheerders meer.

Natuurlijk is er met 2 niet zoveel mis als het een eenvoudige en kleine omgeving betreft zoals een simpele CRUD SAAS applicatie, voor simpele software had je vroeger ook niet of weinig beheerders nodig. Maar naarmate de complexiteit toeneemt wordt het (imho) wel steeds meer een probleem, zeker ook als het beveiligingsaspect erbij komt kijken.

Uiteindelijk zie je dat 2 toch vaak gedreven wordt uit kostenbesparing, maar brede kennis roept uiteindelijk weer nieuw problemen op. Hoe breder de kennis is die iemand moet bezitten, des te minder kan die zich specialiseren. En die specialisatie is misschien juist nodig op cruciale vlakken.

Hetzelfde zag je met het verdwijnen van database experts en beheerders bij veel organisaties, met specialistische kennis valt er heel wat performance winst te behalen. Maar ik heb veel software gezien waar de oplossing was om de database steeds maar meer resources te geven. De uitspraak die in die trant hoorde: Moore's law is de redding van ons software product.

[alex3305]

In de organisatie waar ik zat had ik het idee dat het vooral vanuit kostenbesparing werd gedaan. Terwijl eigenlijk van onderaf het idee was om ontwikkelaars wat meer controle te geven over hun applicatie en hoe deze uitgerold werd. Wat ik vooral merkte is dat pure ontwikkelaars steeds meer petjes kregen vanuit de organisatie. Primair was je developer, maar ook operator. Later kwam daar, door agile, ook een meewerkende scrum master bij. En in het laatste jaar dat ik daar zat moesten developers ook tijdens kantoortijden eerste- en tweedelijns helpdesk doen. En uiteindelijk was het ook de bedoeling dat er consignatiediensten gedraaid werden door developers. Mijn hoofd was niet groot genoeg voor al die petjes.

Ik had ook het idee dat het kwam omdat het voor managementlagen niet altijd zichtbaar is hoeveel kennis een developer nou eigenlijk nodig heeft om bepaalde taken uit te voeren. Als je het vergelijkt naar een timmerman moet dat ook ineens een constructeur zijn en een loodgieter en een tegelzetter en een elektricien en een dakdekker. Het is allemaal technisch, maar het zijn specialisme en ik heb het idee dat dat bij een slechte implementatie van DevOps verloren gaat. De term "Maar persoon X kan dat wel", kwam dan ook veelvuldig voor. Waarop na een paar keer de dooddoener kwam, "dan ga je het lekker aan persoon X vragen" . Met als resultaat dat persoon X overspoeld werd met vragen.

Maar puur over DevOps. Ik vind DevOps als developer ontzettend fijn omdat het mij de kracht geeft om controle uit te oefenen over mijn applicatie. Onder andere hoe deze uitgerold en beheerd wordt. Maar dan moet het wel vanuit het perspectief van de developer zijn. Ook moet je niet alle verantwoordelijkheid bij een developer neerleggen. Kubernetes opzetten is leuk, maar moet een developer niet willen doen. Er is ook maar zoveel tijd op een dag.

Het is m.i. ook vergelijkbaar met agile. Het is een mooi concept, maar je moet als developer wel grenzen en voorwaarden stellen anders word je bordje langzaam leeggegeten. En dat heb je pas in de gaten als het te laat is.

[Tuxie]

Hey, leuk topic! Ik coach bedrijven en SWEs bij de implementatie van Dev(Sec)Ops....

Waar ik het in de praktijk vaak fout zie gaan is mindset. DevOps is in de basis een mindset, een manier van werken en kent vele implementaties afhankelijk van type domein, bedrijfsstructuur en kennis / personeel. Ik begin altijd bij de teams zelf, waarom wil je DevOps gaan doen? Hoe wordt een team aangestuurd? Wat betekent succes voor het bedrijf? Vaak zie je dat veel zaken niet gedefinieerd zijn en het gevolg is een situatie die de TS o.a. omschrijft: alleen maar aandacht voor tooling & technologie, over de schutting gooien en 'red je er maar mee'.....

Gelukkig zijn er ook veel goed functionerende teams met happy developers...Hoe mooi is het als je het aantal features in productie met de week ziet toenemen, dat je canary releases op orde hebt, je het aantal defects ziet verminderen en je dit allemaal meetbaar en begrijpbaar kunt communiceren zodat het ook direct duidelijk wordt van de immense business waarde van zo'n team kan zijn? Hint: het ligt meestal niet aan het team, maar aan het management er omheen......

[CH4OS]

Gunn4 schreef op woensdag 17 juli 2024 @ 16:00:
Het is niet dat ik elk individueel onderdeel niet interessant zou vinden, maar het gaat erom dat het allemaal bij elkáár gewoon veels te veel is. Ik voel me overweldigd door de wirwar aan tools en acroniemen, en zodra je het een beetje door lijkt te hebben mag je weer opnieuw beginnen omdat ze zo nodig moeten migreren naar the-next-best-thing. Je kunt door de brede scope van technieken die je moet kennen alles maar oppervlakkig begrijpen, waardoor je nooit meer echt de expert kunt zijn op een gebied.

Wat mij betreft is het gewoon een mentaliteits dingetje. Ik was voorheen ook Software Engineer, daarbij ook wel redelijk wat "DevOps" gedaan bij diverse bedrijven, waar dat overal anders was. Maar wat ik ergens wel vreemd vind: je vind het niet erg om te verdiepen in diverse zaken, maar nu er opeens ook andere zaken bij komen, is het opeens "teveel"? Is het niet gewoon desinteresse?

[boxlessness]

CH4OS schreef op donderdag 18 juli 2024 @ 14:48:
[...]
Wat mij betreft is het gewoon een mentaliteits dingetje. Ik was voorheen ook Software Engineer, daarbij ook wel redelijk wat "DevOps" gedaan bij diverse bedrijven, waar dat overal anders was. Maar wat ik ergens wel vreemd vind: je vind het niet erg om te verdiepen in diverse zaken, maar nu er opeens ook andere zaken bij komen, is het opeens "teveel"? Is het niet gewoon desinteresse?

Da's wel heel kort door de bocht. Dat jij met gemak in 20 applicaties de juiste vinkjes weet te vinden, wil niet zeggen dat je beter/geinteresseerder bent dan iemand die in één tech het onderste uit de kan weet te halen. Op een gegeven moment is het kopje vol, en bij de een is dat vol met kennis in de diepte, en bij de ander is dat vol met kennis in de breedte.

Daarbij is niks mis met desinteresse. Interesse vloeit deels voort uit behoeftes van bijvoorbeeld focus, flow, resultaatgedrevenheid, kwaliteitgedrevenheid, gevoel van controle, gevoel van vrijheid, etc.

Als je de "old skool, stereotype" developer kijkt dat heeft DevOps een aantal aspecten die daar schuren:

1) De balans tussen "lekker bezig zijn" en "de shit bij elkaar googlen omdat ik vergeten ben hoe ik dit een half jaar geleden ook alweer gedaan heb" verschuift, en dat drukt op het gevoel van werkgeluk. Het wordt moeilijker om goed in de flow te komen.
Nieuwe dingen leren hoort er inderdaad gewoon bij, maar continue in een steile learning curve zitten put mensen uit. Alles met mate.

2) Er is vaak toch wel een drive om kwaliteit op te leveren, maar door te dun uitgesmeerd te zijn over te veel taken/tech heb je niet langer de diepgang om met een zeker gevoel iets in elkaar te steken. Dat werkt onzekerheid en stress in de hand. Zeker wanneer het gaat over zoiets als security.

Dus er is niet zoiets als "gewoon desinteresse"... het is complexer dan dat.

[CH4OS]

boxlessness schreef op donderdag 18 juli 2024 @ 15:49:
Da's wel heel kort door de bocht. Dat jij met gemak in 20 applicaties de juiste vinkjes weet te vinden, wil niet zeggen dat je beter/geinteresseerder bent dan iemand die in één tech het onderste uit de kan weet te halen. Op een gegeven moment is het kopje vol, en bij de een is dat vol met kennis in de diepte, en bij de ander is dat vol met kennis in de breedte.

Dat snap ik, maar daar hoor je mij ook niet over...

Daarbij is niks mis met desinteresse. Interesse vloeit deels voort uit behoeftes van bijvoorbeeld focus, flow, resultaatgedrevenheid, kwaliteitgedrevenheid, gevoel van controle, gevoel van vrijheid, etc.

Ook hier is niks mis mee inderdaad, maar dat betekend aan de andere kant ook niet dat DevOps maar slecht is, omdat het voor hemzelf niet (goed) werkt. Het kan dus wel degelijk desinteresse zijn, omdat iemand bijvoorbeeld het niet interessant vindt om kennis in de breedte te hebben. Ik kan mij echter wel voorstellen dat iemand niet zit te wachten op DevOps, omdat de interesse er niet is, vandaar de vraag of het wellicht desinteresse kan zijn, want dat geeft sowieso geen enthousiasme of werkgeluk en -energie.

Als je de "old skool, stereotype" developer kijkt dat heeft DevOps een aantal aspecten die daar schuren:

1) De balans tussen "lekker bezig zijn" en "de shit bij elkaar googlen omdat ik vergeten ben hoe ik dit een half jaar geleden ook alweer gedaan heb" verschuift, en dat drukt op het gevoel van werkgeluk. Het wordt moeilijker om goed in de flow te komen.
Nieuwe dingen leren hoort er inderdaad gewoon bij, maar continue in een steile learning curve zitten put mensen uit. Alles met mate.

2) Er is vaak toch wel een drive om kwaliteit op te leveren, maar door te dun uitgesmeerd te zijn over te veel taken/tech heb je niet langer de diepgang om met een zeker gevoel iets in elkaar te steken. Dat werkt onzekerheid en stress in de hand. Zeker wanneer het gaat over zoiets als security.

Dus er is niet zoiets als "gewoon desinteresse"... het is complexer dan dat.

En dit is precies hetgeen wat ik bedoel met desinteresse.

[ Voor 5% gewijzigd door CH4OS op 18-07-2024 17:33 ]

[CVTTPD2DQ]

Kwistnix schreef op donderdag 18 juli 2024 @ 13:03:
Organisaties zijn altijd wel opzoek geweest naar eenhoorns en de volledig uitwisselbare FTE. Voor "DevOps" was het "'full-stack".

Natuurlijk, het is niet zo lang geleden dat bij kleine bedrijven de webdeveloper van de jaren '00 ook in z'n Peugeot 206 naar het datacentrum reed als er op zondag een outage was. Dat noemde toen niemand "devops".

defiant schreef op donderdag 18 juli 2024 @ 14:27:
Uiteindelijk zie je dat 2 toch vaak gedreven wordt uit kostenbesparing, maar brede kennis roept uiteindelijk weer nieuw problemen op. Hoe breder de kennis is die iemand moet bezitten, des te minder kan die zich specialiseren. En die specialisatie is misschien juist nodig op cruciale vlakken.

Of misschien juist niet. De IT in Nederland loopt tegen scherp afnemende meerverdiensten aan. Door de grote beschikbaarheid van Open Source / Cloud componenten stelt software development niet zoveel meer voor. Tegelijkertijd zijn loonkosten astronomisch.

Oh, en de tijd dat het internet het Wilde Westen was, waar je een fortuin kunt verdienen, ligt echt achter ons. De meest winstgevende activiteiten zijn ingenomen door grote partijen waarmee je op schaal en kosten niet kunt concurreren. Innovatiekracht in Nederland is beperkt,

Het is niet gek dat men die duurbetaalde developer zo effectief mogelijk wil inzetten. Je ziet dat men sectorbreed zoveel mogelijk gaat richten op één leverancier, en dat van werknemers verwacht wordt dat ze zich zoveel mogelijk bekwamen in de standaardtools van die leverancier, zodat ze zich op allerlei manieren nuttig kunnen maken.

Uiteindelijk zullen natuurlijk de ontslagrondes komen, waarna de sector eindelijk kostengericht gaat werken, net zoals (bijvoorbeeld) de bouw.

[boxlessness]

CVTTPD2DQ schreef op donderdag 18 juli 2024 @ 20:54:
[...]


Of misschien juist niet. De IT in Nederland loopt tegen scherp afnemende meerverdiensten aan. Door de grote beschikbaarheid van Open Source / Cloud componenten stelt software development niet zoveel meer voor. Tegelijkertijd zijn loonkosten astronomisch.

Oh, en de tijd dat het internet het Wilde Westen was, waar je een fortuin kunt verdienen, ligt echt achter ons. De meest winstgevende activiteiten zijn ingenomen door grote partijen waarmee je op schaal en kosten niet kunt concurreren. Innovatiekracht in Nederland is beperkt,

Het is niet gek dat men die duurbetaalde developer zo effectief mogelijk wil inzetten. Je ziet dat men sectorbreed zoveel mogelijk gaat richten op één leverancier, en dat van werknemers verwacht wordt dat ze zich zoveel mogelijk bekwamen in de standaardtools van die leverancier, zodat ze zich op allerlei manieren nuttig kunnen maken.

Uiteindelijk zullen natuurlijk de ontslagrondes komen, waarna de sector eindelijk kostengericht gaat werken, net zoals (bijvoorbeeld) de bouw.

Ik ben het met je eens... maar ook weer niet.
Als je standaard dingen wilt, voor je standaard gebruikers, koop dan inderdaad standaard tools. Maar wanneer je je wilt onderscheiden in de markt dan zul je de extra mile moeten gaan.
De homepage van een schroefjesfabriek hoeft inderdaad niet custom made te zijn, noch de ERP software (waarschijnlijk). Maar wanneer je als schroefjesfabriek de schroefjes draait met standaard staal, en standaard machines, op een standaard manier... dan krijg je standaard schroefjes. Je bedrijfsrisico is dan dat iemand anders met diezelfde standaard dingen je uit de markt kan duwen.

Het is in softwareland met de enorme beschikbaarheid van standaard tooling en integraties steeds lastiger om onderscheidend te zijn (de wild-west dagen zijn inderdaad voorbij), maar ik vind de reflex naar "gebruik standaard dingen" te kort door de bocht: je maakt je misschien ongewild kwetsbaar en vervangbaar.

Ook door alles te sourcen van 1 leverancier maak je jezelf kwetsbaar voor de nukken van die ene leverancier. Ik zie het bij ons gebeuren: onze licentiedeal met een grote partij loopt af, en nu we na jaren zowat ALLES met hun software gebouwd en geintegreerd hebben zitten we er stevig in vast. En nu schrikt men van het nieuwe kostenplaatje en is men her-en-der aan het overwegen om over te gaan op open source. Straks gaan er misschien weer tonnen (of nog meer) aan development- en beheer-werk door het putje.

Standaard dingen gebruiken is misschien goedkoop, maar kijk uit dat je goedkoop geen duurkoop wordt. Dit is meer algemeen mijn aversie van de "race to the bottom" en is niet software-specifiek.

[CVTTPD2DQ]

boxlessness schreef op vrijdag 19 juli 2024 @ 09:20:
Ik ben het met je eens... maar ook weer niet.
Als je standaard dingen wilt, voor je standaard gebruikers, koop dan inderdaad standaard tools. Maar wanneer je je wilt onderscheiden in de markt dan zul je de extra mile moeten gaan.

Maar de markt hoeft dat niet te waarderen. Ooit hadden we in Nederland een innovatieve autofabrikant. Het laatste restant daarvan is een paar maanden geleden ter ziele gegaan. We hebben in Nederland hoge loonkosten en bijna geen schaalvoordelen. Het is niet aannemelijk dat software-ontwikkeling hier op termijn concurrerend kan zijn. In specifieke niches misschien nog wel.

boxlessness schreef op vrijdag 19 juli 2024 @ 09:20:
Ook door alles te sourcen van 1 leverancier maak je jezelf kwetsbaar voor de nukken van die ene leverancier. Ik zie het bij ons gebeuren: onze licentiedeal met een grote partij loopt af, en nu we na jaren zowat ALLES met hun software gebouwd en geintegreerd hebben zitten we er stevig in vast. En nu schrikt men van het nieuwe kostenplaatje en is men her-en-der aan het overwegen om over te gaan op open source.

Nou ja, je ziet nu dat bedrijven die meer in-house doen of open source gebruiken, geen contracten met overheidspartijen of grote bedrijven kunnen binnenhalen, omdat ze niet de vijf negens uptime en het pakket security-certificaten kunnen overleggen dat je bij de grote leveranciers cadeau krijgt. Ik denk dat het een aflopende zaak is, hoe dan ook.

Om terug te komen bij de vraag van de TS: Ja, het is (afhankelijk van de inrichting en formaat van de werkgever) niet zo fijn als een eigen specialisatie hebben, maar ik denk dat je jezelf bedriegt als je denkt dat er op termijn veel ruimte is voor mensen die "alleen maar" software kunnen ontwikkelen in Nederland.

[Gunn4]

CH4OS schreef op donderdag 18 juli 2024 @ 14:48:
Maar wat ik ergens wel vreemd vind: je vind het niet erg om te verdiepen in diverse zaken, maar nu er opeens ook andere zaken bij komen, is het opeens "teveel"?

Ja, precies dat. Het is niet dat ik het allemaal an sich niet interessant vind, het is dat er altijd alleen maar dingen bij komen, maar er nooit iets vanaf gaat. Zoals Ahrnuld eerder aangaf, het voelt gewoon alsof ik continue boven de max van mijn cognitieve capaciteiten moet werken.

Van bepaalde dingen is het ook moeilijk om het echt voldoende te snappen, omdat je het ook maar zelden moet doen: als je slechts 1x per jaar aan de Ingress/Traefik configuratie hoeft te sleutelen, kun je volgend jaar weer opnieuw beginnen met je kennisopbouw. Ik heb nou eenmaal (helaas) geen fotografisch geheugen.

Maar goed, ik begrijp dat de meningen hierover verdeeld zijn, maar laten we even aannemen dat dit voor mij wel een probleem is. Wat zou dan een mooie oplossing voor mij zijn? Is er een bepaald carrièrepad of technische stack waarin specialisatie meer mogelijk is dan mijn huidige? (Ter referentie: ik ben nu Java/Kotlin developer in een fullstack/devops team).

[CH4OS]

Gunn4 schreef op maandag 22 juli 2024 @ 12:08:
Ja, precies dat. Het is niet dat ik het allemaal an sich niet interessant vind, het is dat er altijd alleen maar dingen bij komen, maar er nooit iets vanaf gaat. Zoals Ahrnuld eerder aangaf, het voelt gewoon alsof ik continue boven de max van mijn cognitieve capaciteiten moet werken.

Als het je niet lukt, kun je toch ook gewoon hulp vragen? Lijkt me ook niets mis mee. Lijkt me dat je dat op de oude manier ook gewoon deed, toch? Waarom zou dat met "DevOps" opeens heel anders zijn? Bij mijn huidige werk, doen we ook eea "DevOps", maar iedereen heeft wel zijn eigen "specialiteit". We zijn maar een klein team (met 3 ITers) en vooralsnog werkt dat op zich prima. Als ik iets niet weet (ik ben het groentje in het team zal ik maar even zeggen) dan vraag ik dat. Als iemand direct het antwoord weet dan wordt dat gedeeld, of gaan er wegen gezocht worden waarop we het te weten gaan komen bijvoorbeeld. En andersom ook; ik heb ook mijn specialiteiten, die ook gewoon binnen het team benut worden wanneer nodig.

Van bepaalde dingen is het ook moeilijk om het echt voldoende te snappen, omdat je het ook maar zelden moet doen: als je slechts 1x per jaar aan de Ingress/Traefik configuratie hoeft te sleutelen, kun je volgend jaar weer opnieuw beginnen met je kennisopbouw. Ik heb nou eenmaal (helaas) geen fotografisch geheugen.

Ik heb ook geen fotografisch geheugen, maar kan wel redelijk makkelijk dingen onthouden. Als ik dan vaak de code weer zie, dan denk ik vaak ook "Oh ja, dat deed ik toen zo...". Soms denk ik dan wel weer dat het beter kan, maar goed, destijds niet aan gedacht. Een improvement erop kan dan weer niet altijd om diverse redenen.

Maar goed, ik begrijp dat de meningen hierover verdeeld zijn, maar laten we even aannemen dat dit voor mij wel een probleem is. Wat zou dan een mooie oplossing voor mij zijn? Is er een bepaald carrièrepad of technische stack waarin specialisatie meer mogelijk is dan mijn huidige? (Ter referentie: ik ben nu Java/Kotlin developer in een fullstack/devops team).

Ligt er natuurlijk ook maar aan wat je zelf wilt. Als het bedrijf meer van jou verwacht dan je wilt of kunt, dan lijkt me de keuze simpel. Maar ga je in gesprek met het team of de werkgever, kijken wat er mogelijk is, dan kan er wellicht ook wel iets geregeld worden, toch? Uitkijken naar een ander bedrijf kan dan altijd nog, maar we kennen ook de situatie niet, of wat je wilt.

Ik kan mij niet voorstellen dat je iets moet doen omdat het "boven de cognitieve capaciteiten" is. Als dat zo is en men houdt er stevig aan vast, dan lijkt het mij dat je niet echt meer op je plek zit, maar dat zal het bedrijf dan waarschijnlijk net zo ervaren, lijkt me en dan zou ik zeker even in gesprek gaan, kijken hoe de vork in de steel zit, of het echt een groot probleem is bijvoorbeeld, misschien wordt de soep niet zo heet gegeten als hij wordt opgediend.

Al lijkt dit mij een heel ander vraagstuk dan "DevOps = one man army?".

[ Voor 8% gewijzigd door CH4OS op 22-07-2024 13:49 ]

[Furion2000]

@Gunn4 Ik denk dat er genoeg DevOps mensen hetzelfde voelen of er (soms) zo tegenaan kijken. Hell, ik denk dat er heel veel mensen in heel veel branches zich zo voelen na x jaar in het vak.

Over DevOps durf ik te zeggen dat de meeste teams het helemaal prima (zouden moeten) vinden als je aangeeft liever zoveel mogelijk java/kotlin werk op te pakken omdat daar je passie ligt en je ops werk lastig of niet leuk vind. Persoonlijk zou ik het zelfs fijn vinden als mensen veel meer vertellen dan dat ze stilletjes zich bezwaard voelen. Dat gesprek probeer ik vaak op gang te brengen door mijzelf te bestempelen als 'master of none' en dan als snel komt de volgende met 'frontend sucked' op de proppen

Wat al meermaals is gezegd, DevOps moet een team zijn van verschillende specialismen