Transportman schreef op zaterdag 20 juni 2020 @ 21:39:
[...]
Ik heb vooral bij bedrijven gezeten waar de wettelijke verplichtingen er in ieder geval voor zorgen dat de data zoveel mogelijk in house moet staan (AVG, dus zomaar even in een cloud gaan draaien kan lastig zijn), en dat zorgt er vervolgens weer voor dat een heleboel dingen in house gewenst worden. Want omdat de data in house staat, wil je eigenlijk je servers die dingen met die data doen ook in house hebben. En dan komt ook weer de hele discussie die we hier hebben over standaardisatie om de hoek kijken, ga je je personeel in een andere omgeving stoppen dan je servers? Je krijgt overhead op beheer, je moet toegangen tussen de twee omgevingen regelen, dus dan volgt eigenlijk uit de wettelijke verplichting dat heel veel ook in house komt te staan.
"In de cloud draaien" kan natuurlijk van alles betekenen. Stel dat je het over AVG hebt, of over banken en verzekeraars, en zorginstellingen, dan kan je dat allemaal prima afvangen met client-side encryptie. Vaak is het niet zo zeer dat wel misschien wel/misschien niet kan, maar dat het gewoon een gebrek aan kennis en/of wil is. Dat zie je vooral veel bij bedrijven die nooit een positieve feedback loop in het leven geroepen hebben om beter te worden en beter te blijven. De kans is ook groot dat je als losse instelling nooit dezelfde beveiliging, garanties en operationele kundigheid gaat hebben als een dedicated provider. Stel dat je AWS of Azure of GCP neemt, dat ga je nooit zelf beter kunnen doen. Wat je wel kan doen is splitsen waar mogelijk; wat ik vaak zie is dat de (geemuleerde) mainframe software alleen nog als backend gebruikt wordt en dat nog in een private on-prem cloud draait, vooral als het op Power architectuur draait. Met verschrikkelijk oude spullen zoals COBOL applicaties hebben we dan vaak een JSON I/O gateway over een setje dedicated verbindingen naar zo'n provider lopen, en daar doen we dan de normale development zaken en productie voor bijv. backoffice en user-facing systemen.
In de praktijk kan je eigenlijk stellen dat je in elk geval qua wendbaarheid en kennis pooling toch wel een cloud-achtige opzet (denk aan on-prem private cloud op basis van OpenStack, VMWare of Hyper-V) moet hebben, al is het maar om betaalbaar personeel te houden en qua development iteraties competitief te blijven. Dat is natuurlijk niet voor iedereen hetzelfde; als je weinig druk van de concurrentie ervaart is er ook minder druk om je als bedrijf te ontwikkelen. Vaak ziet men het niet aan komen en ligt je bedrijf opeens zo ver achter dat je bestaan in gevaar komt. Dat zie je ook als er dan een overname komt en alle tech en business product na een kort overgangsperiode in de prullenbak beland.
Transportman schreef op zaterdag 20 juni 2020 @ 21:39:
[...]
Dat is inderdaad als je NU zou kiezen om versiebeheer in te richten, en zeker nu cloud aanbieders daar groot zijn geworden, zijn er maar weinig redenen om het zelf te doen als je NU de keuze moet maken. Het probleem zit meer in als het vroeger anders is gedaan, dat dat gigantisch lang kan blijven liggen, zeker bij grote organisaties. Niemand hakt de knoop door dat het oude over moet naar het nieuwe, de teams die hun dingen over moeten zetten krijgen er geen budget voor omdat het oude systeem toch blijft draaien en zo eindig je met allemaal oude omgevingen in de lucht omdat alles uit verschillende potjes moet komen. En zo gaat dat met gigantisch veel, zolang niemand zegt dat het MOET gebeuren, gaat het niet snel gebeuren.
Nouja, ik voer dat altijd door, anders wordt een opdracht niet eens aangenomen. Ontwikkelaars afremmen om dat verandering eng is lijkt me toch wel een van de dommere dingen die je als bedrijf kan doen. Hetzelfde geldt ook hier: je moet jezelf blijven verbeteren als je concurrenten hebt. Het laagste bod is een SCM bridge zodat je bijv. oude meuk als SVN via git kan gebruiken, net als VSTS/SS. Leuk dat zo'n 90's concept nog gebruikt wordt, maar dat betekent niet dat het nog steeds een goed idee is ;-) Tenzij je nog klassieke fat clients aan het bouwen bent is dat sowieso iets wat ook helemaal niet meer door recente tooling ondersteund wordt.
Qua tijdspad denk ik dat het ook wel goed is om in het achterhoofd te houden dat mensen die nu nog niet een breed gedragen VCS als git draaien zo'n 10 jaar te laat zijn. Nieuwe ontwikkelaars komt niet af op slechte tooling en oude ontwikkelaars sterven uit (letterlijk en figuurlijk). Natuurlijk probeert een bedrijf dat altijd te compenseren door meer geld aan te bieden, maar dat gaat ook maar beperkt mensen aantrekken om met legacy bezig te gaan. En van de detacheer-stoelendans worden veel projecten niet beter.
Transportman schreef op zaterdag 20 juni 2020 @ 21:39:
[...]
In de ideale wereld zou dat zo zijn, en voor de werkomgevingen van gebruikers zal dat zeker werken, maar voor servers zou ik er niet teveel op rekenen, maar dat heeft meer te maken met alle andere ongein die waarschijnlijk beter op een andere manier geregeld zou kunnen worden (externe verbindingen op basis van IP-adressen toestaan i.p.v. op hostname).
Hangt van je eigen regels af, ik (en een aantal klanten en een werkgever) hebben ongeveer dezelfde regels:
- Er is 1 omgeving waar je met de hand spullen mag bouwen, en die omgeving is niet extern benaderbaar, wordt elke dag geleegd
- Alle andere omgevingen kan je alleen benaderen met provisioning tooling
- Wijzigingen vinden via diezelfde tooling plaats
- De configuratie van die wijzigingen staan in git
Die configuraties bepalen bijv. ook welke hosts met elkaar kunnen praten, welke containers, welke lambdas enz. maar ook welke systemen met on-prem subnets kunnen praten, denk aan telefooncentrales (yuck), printservers, gebouwautomaitsering, ICS. Dat wordt bij de source gecontroleerd, en bij de destination (allebei op netwerkniveau). Als een host zelf dan nog lokale restricties heeft mag de owner dat zelf weten of dat nog ingezet wordt.
Op die manier zijn je systemen niet 'speciaal', en als er wat stuk is draai je je tooling opnieuw en staat het precies in de gedefinieerde staat terug op z'n plek. Qua storage is dat net wat anders, buckets, databases en message stores hebben CRU maar geen D zodat je niet per ongeluk data kan verwijderen van uit je tooling. En om dat de data zelf ook PITR heeft kan je ook als je terug moet rollen in je data meerollen. Dat is de laatste 9 jaar nog nooit nodig geweest, maar tijdens tests als we een productie verstoring genereren werkt het prima. (dat is ook een ding, net als backups moet je ook je disaster recovery testen, anders weet je nog steeds niet of je dat afgevangen hebt)
Werkplekken kunnen via MDM voorgeconfigureerd worden (model 1 en 2 uit mijn eerdere post), maar tot zo ver heeft geen enkele developer daar voor gekozen en doen ze het zelf naar smaak. Mocht je geen laptop bij de hand hebben kan je in elk geval via VDI ook alles doen, maar dan dus niet met je eigen aangepaste spullen. Ook een reden waarom eigenlijk alleen klassieke staf functies dat spul gebruiken en de rest niet.
Let wel: al deze dingen klinken nieuw en spannend, maar dat is het niet. Je komt nog steeds veel wanbeleid tegen, of beleid op basis van niet-realistische scenarios, terwijl dat in de praktijk niet beschermt tegen diefstal/lekken/performance. Bedrijven die om wat voor reden dan ook moesten versnellen, flexibeler moesten worden (en dus sneller moeten schakelen) of greenfield konden beginnen doen dit allemaal eigenlijk al, net als bedrijven die te groot zijn om nog praktisch in 90's beheer te draaien (bijv. om dat het uitrollen van een enkele patch al tot het equivalent van een broadcast stom leidt). Als je dat ook maar 1x meegemaakt hebt ga je je toch behoorlijk achter je oren krabben als je dan bij een ander bedrijf de staat van werken ziet en de smoesjes die er rondzweven waarom het niet verbeterd is.
[
Voor 5% gewijzigd door
johnkeates op 20-06-2020 22:23
]