Satya Nadella: techindustrie gaat twee moeilijke jaren tegemoet

Microsoft-ceo Satya Nadella heeft tijdens een interview met het Indiase CNBC-TV18 gezegd dat de wereldwijde techindustrie nog twee moeilijke jaren tegemoet zal gaan. Nadien zal er volgens hem opnieuw sprake zijn van betere tijden.

Volgens Nadella zal er enerzijds sprake zijn van een recessie in sommige delen van de wereld. Anderzijds zal de toegenomen vraag naar tech afnemen nadat die is gestegen tijdens de coronapandemie. “We zullen ons moeten aanpassen en onszelf de vraag moeten stellen of we wel efficiënt en competitief genoeg zijn als bedrijf”, klonk het in het interview met CNBC-TV18.

De ceo van Microsoft ziet de toekomst van de techindustrie op lange termijn wel positief in. Steeds meer bedrijven en industrieën zouden volgens de man gebruikmaken van technologie en die hebben op termijn ook technologische infrastructuur nodig.

Nadella haalt ook de recente ontwikkelingen in AI aan. Volgens de ceo zal kunstmatige intelligentie de komende twee à drie jaar voor een 'paradigmawijziging' zorgen. Nadella zegt ook dat knowledge work en softwareontwikkeling "getransformeerd" zullen worden door AI. Hij maakt, wat betreft AI in het algemeen, de vergelijking met cloudcomputing dat volgens hem in 2007 en 2008 ook voor grote omwentelingen in de techindustrie heeft gezorgd.

Reacties (101)

Ik snap onmiddellijk wat er bedoeld wordt met AI en hoe dit paradigmaverschuivend is. Het is nieuwe tech die nieuwe mogelijkheden (en gevaren) met zich mee brengt en de manier waarop er gewerkt wordt fundamenteel kan veranderen.

Maar wat voor 'paradigmaverschuiving' heeft hij het over m.b.t. de cloud? Het is niet alsof je iets nieuws of anders kan met 'de cloud'. Voordat datacenters populair werden had je de servers intern draaien en had je misschien meer mensen nodig om de hardware te onderhouden. Maar het is niet alsof je nu van zoveel mensen afscheid kan nemen; je hebt nog steeds mensen nodig die de servers configureren, up-to-date houden, etc. Maar nu doen ze dat in de cloud. Het is waar; je heb geen kosten meer van zelf hardware draaien, maar je hebt wel de kosten van de servers huren. Dus wat is hier nu 'paradigmaverschuivend' aan?

[Reactie gewijzigd door MaestroMaus op 8 januari 2023 13:39]

Op zich is de transformatie van IT naar de cloud niet alleen een lift-and-shift van servers zoals je stelt in je voorbeeld. Het is echt heel veel meer. De opkomst van cloud ging hand in hand met de opkomst van DevOps. Mbt je voorbeeld van servers configureren in bijv Azure, je kan tegenwoordig met een bicep template die in je source control staat, via een devops pipeline een complete infrastructuur in azure uitrollen. Er zijn al zoveel services beschikbaar binnen Azure en/of AWS dat je vaak niet eens een VM hoeft te hosten om iets voor elkaar te krijgen.

Mbt AI, ik gebruik de laatste weken ChatGPT als een soort pair programmer en het werkt echt vrij goed. Als ik vraag hoe een bicep template er uit moet zien waarbij ik een application gateway wil deployen met twee azure functions in de backend pools, dan krijg ik dat netjes als antwoord. Github CoPilot gebruik ik zelf nog niet in het bedrijfsleven, maar ook daar zie je dat automatische code suggesties echt "next level" zijn. Je moet nog steeds zelf nadenken! Maar er wordt zeker heel veel uit handen genomen als je het goed weet te gebruiken.

Ik krijg altijd een beetje jeuk als mensen DevOps gaan noemen in de zin van technische pipelines. DevOps is een filosofie en manier van werken, wat jij noemt is slechts een tool om het mogelijk te maken.

Het DevOps principe is juist het verbeteren van samenwerking tussen developers en operations. Tools kunnen daar zeker bij helpen maar ik heb al te veel tenten gezien die dergelijke oplossingen maar ertegenaan gooien om een cultuurprobleem op te lossen.

Dat is het mooie van Devop die kan diverse cultuut problemlen ook oplossen weant,

DEV is OPS en OPS is DEV,

Het wordt dus 1 team en niet meer over de schutting gooi mentaliteit want dan komt het toch weer terug bij jouw

In mijn organisatie is DEVOPS wel een beetje problematisch. We ontwikkelen nieuwe applicaties, maar beheren deze ook als ze in gebruik zijn. Dus dat is handig om DEVOPS teams te gebruiken. Maar in de praktijk heeft het DEV gedeelte van het team best wel veel last van het OPS gedeelte. Als in: de ontwikkeling van nieuwe applicaties loopt vertraging op, omdat er telkens productiebevindingen van de oude op het bord terechtkomen en daar vertraging veroorzaken.

Hoe zouden we dit het best kunnen aanpakken? Want op dit moment lijkt het de kant op te gaan van 1 team dat de bugs oppakt en het andere dat de nieuwbouw doet. Maar dat is niet echt DEVOPS...

De oplossing klinkt vrij voor de hand liggend toch?
Laat ontwikkelaars zelf hun bugs oplossen! Ze hebben uiteindelijk zelf de software geschreven en zullen dus het beste weten hoe ze de bugs op moeten lossen? Daarnaast leren ze daardoor om vervolgens betere code te schrijven. Want als je rommel schrijft ben je meer tijd kwijt aan bugs.

Dat is hoe we het doen binnen ons team tenminste. We zijn verantwoordelijk voor alles wat draait binnen een bepaald domein en kennen dat dus ook als de binnenkant van onze broekzak. Wat zowel de onderhoud als ontwikkeling ten goede komt.

Dat klinkt hetzelfde als een ontwikkelaar zelf unit-tests laten schrijven. Dan word er echt alleen getest op de fouten die deze programmeur kan bedenken. Ooit gehoord van tunnel-visie?

Bij het bedrijf waar ik werk is er de regel dat diegene die de software schrijft absoluut niet de beste persoon is om te testen op fouten, dus ook niet de unit tests mag maken. Ja, een 2e persoon dient zich ook in te lezen in de materie/eisen/wensen. De ene schrijft de test, de ander de code. En dat wisselt continu.

Klinkt als een overdreven manier van werken, maar het heeft toch vaak tot inzichten bij de betrokkenen geleid die ze waarschijnlijk zelf nooit hadden hudden krijgen. Of zeker niet zo snel. Natuurlijk, dat is in het begin ook een slomere manier van werken. Maar wanneer iedereen aan dat systeem is gewend, dan scheelt het een boel tijd.

Want tijdens het schrijven/testen van software in de development omgeving zijn fouten of misvattingen veel sneller onderkent dan in de acceptatie-omgeving. Dat is zeker een magintude sneller. En er is ook nog eens een magnitude aan tijdswinst als software faalt in de productie-omgeving. Een uur verkwist in de development-omgeving is 10 uur tijdsverkwisting in acceptatie-omgevingen en 100 uur in productie-omgevingen.

Nu wordt software, welke goed door de unit-tests is gekomen, ook nog eens onderworpen aan automatische regressietests. En dan kom je toch nog wel eens fouten tegen, die unit-tests hebben weten te omzeilen. Doen we ook om er zeker(der) van te zijn dat er geen fouten zijn ingeslopen tijdens het bouwen van de software.

Ja, kost allemaal meer tijd, maar nog altijd veel minder dan brakke software die zich in de acceptatie-omgeving heeft weten te nestelen. Ik hoor velen die het hosanna van unit-tests verkondigen en dat er niets anders nodig is. Unit-tests zijn absoluut nuttig in de test-procedures, maar zijn zeker geen vervanger voor regressietests. Een goede aanvulling? Jazeker!. Maar niet meer dan dat.

Dan kun je de bugs toch nog wel gewoon terug zetten naar de zelfde dev?

Als je je unit tests pas schrijft nadat je code is opgeleverd zal de kwaliteit niet al te best zijn in veel gevallen (dev is er wel klaar mee, weet al dat het werkt etc). Dan is een goede TDD setup ook een oplossing.
Maar elkaars unit tests schrijven zorgt natuurlijk ook voor een intense kennis deling wat de onderhoudbaardheid fors verbeterd, leuk om de verschillende methoden te zien.

Waar komt deze hele preek over unittests vandaan?
Deze zijn maar een heel klein onderdeel van het gehele ontwikkelprocess mag ik hopen!
Anders is het inderdaad niet zo vreemd dat er brakke software geproduceerd wordt.

Dat klinkt hetzelfde als een ontwikkelaar zelf unit-tests laten schrijven. Dan word er echt alleen getest op de fouten die deze programmeur kan bedenken.

Dat is toch logisch? je test ‘een unit’ … bijvoorbeeld 1 functie en mocked eventueel een interactie. Ondersteund door code coverage test een ontwikkelaar de unit. Op basis van acceptatie criteria van die unit. Algehele overkoepelende functionele tests worden door testers geschreven. Die zullen deels automatisch zijn en vaak ook nog deels handmatig.

Bij het bedrijf waar ik werk is er de regel dat diegene die de software schrijft absoluut niet de beste persoon is om te testen op fouten,

Het gaat om bugs oplossen, niet testen op bugs.

Leer van je fouten, verlaag de Ops druk

Ja, dat is de DEVOPS theorie, maar zo werkt het natuurlijk niet. Veel van die fouten uit productie hadden we nooit vantevoren kunnen voorzien, dus ook niet kunnen voorkomen. Vaak zijn het bevindingen die gewoon 'ontstaan' omdat er bijvoorbeeld iets nieuws wordt gevonden in Fortify of OWASP of ZAP. Soms komen gebruikers ineens met een nieuwe wens of de mededeling dat een bepaalde oplossing (ondanks uitgebreide besprekingen en demo's) toch niet is wat ze nodig hebben... Nou zijn dat niet perse productie"bevindingen", maar het leidt wel tot extra werk wat de planning voor de nieuwe applicaties in de war gooit...

Tja, dat is waarom we al decennia met Agile werken. Als jij nu al een planning hebt gemaakt wat je programmeurs in 2024 doen, dan heb je zinloos veel tijd verspild aan iets wat nog voor de zomervakantie achterhaald is.

Mmm agree to disagree dan. Ja, een fase van nazorg na een release, zeker van complexe apps, is altijd nodig.

Maar alles wat daarna komt qua Ops (incidenten) kan je van leren en in de toekomst voorkomen. Je kan eens wat lezen over reliability engineering (hoe kan iets kapot?) en die werkwijze op je software toepassen.

Grotere changes is Dev werk, en aan de Product Owner (of vergelijkbare rol) om keuzes te maken.

Anyway, jij ervaart het anders, dat kan, zoek iets wat voor jouw team werkt, die zoektocht is vast ook de moeite waard!

De situatie die je schetst is er een waar meer organisaties mee worstelen. Zonder de hele organisatorische context te kennen haal ik een aantal rode vlaggetjes uit je verhaal:

• Veel productiebevindingen, reduceren door te investeren in kwaliteitscontrole voor nieuwe, maar ook oude applicaties.
• DEV ontwikkelt lekker door, OPS gaat aan de slag met bevindingen

Het klinkt alsof jullie organisatie simpelweg ontwikkelaars en beheerders heeft gepakt en deze in één team heeft gestopt in de hoop dat het dan magisch goed zou gaan. De praktijk leert dat dit in veel gevallen helaas niet de resultaten levert die je er van verwacht.

Het klinkt cliché, maar dat maakt het niet minder waar: De organisatie zal zich moeten richten op het verbeteren van de kwaliteit in het voortbrengingsproces zodat de team(s) minder tijd kwijt is aan het oplossen van productiebevindingen. Dit moet écht over de gehele breedte, denk daarbij aan een concrete Definition of Ready/Done voor stories. Kwaliteitsborging onderdeel maken van het gehele ontwikkelprocess, oftewel: unit testen, component testen (API of FE testen waarbij de backend gemocked is), contract testen tussen interfaces en eventueel aanvullen met ketentesten.

Je hebt inzicht (en grip) op de kwaliteit nodig om daadwerkelijk de beoogde snelheid te halen en vast te houden. De benodigde investering die je hiervoor moet doen is in veel gevallen vrij fors, dit is voor veel organisaties een drempel. Imo staat het in schraal contrast met de tijd die we kwijt raken met productiebevindingen en de features (lees: waarde) die je daardoor niet kunt opleveren.

Ik zie het toch anders, juist met behulp van bepaalde tooling kan je een cultuur probleem (over de schutting gooien) aanpakken en oplossen.

Een quote van een boek over devops zegt het eigenlijk al

DevOps is as much about culture as it is about tools.

Edit:autocorrect typo

[Reactie gewijzigd door david-v op 8 januari 2023 19:57]

het kan zeker maar helaas zijn er nog steeds veel (met name langer bestaande bedrijven) waar heel die tools uberhaupt niet aanslaan omdat de developers geen vertrouwen hebben in systeembeheer en de systeembeheerders liefst een hek om hun servers heen zetten. Dan heb je dus een cultuurprobleem en dat is best lastig op te lossen.

Als er geen onderlinge vertrouwen is tussen de mensen in je team (want systeembeheerders zijn onderdeel daarvan) dan heb je als team een probleem, dat klopt. Ik moet wel toegeven dat ik al jaren niet te maken heb met systeem beheer omdat we gebruik maken van services in de cloud.

Als devops team zijn we verantwoordelijk voor het hele stuk, van requirements tot het draaiend houden in productie. Infrastructure as code is een integraal onderdeel binnen ons team waar we een aantal mensen voor hebben die zich daar, naast ontwikkelen, ook mee bezig houden omdat ze daar affiniteit mee hebben. Het netwerkgedeelte om vanuit de cloud naar on premise systemen te gaan is dan bij een andere partij belegd, maar daar hoeft vrijwel nooit iets gedaan te worden, maar ook dat netwerk gedeelte is infrastructure as code. Het maakt het leven voor iedereen een stuk simpeler en je kan razend snel oplossingen uitrollen, dat is in ieder geval mijn ervaring.

Wat mij het meest verbaasd over het gebruik van devops is als organisaties overtuigd zijn dat ze volgens devops werken, maar als ontwikkelaar je helemaal geen (lees)toegang hebt tot productie (en soms zelfs acceptatie). Als ik dan uitleg dat dat juist wel de bedoeling is bij devops dan vallen ze terug op de OTAP silos. Op ontwikkel en test heb je overal toegang en werken ze volgens devops, einde discussie

Daar kan je dan weer tegenin gooien: als je als ontwikkelaar toegang nodig hebt tot de productie omgeving, dan is een duidelijk teken dat je het concept van een acceptatie-omgeving niet hebt begrepen.

Nou weet ik ook wel dat er altijd verschillen kunnen zitten in acceptatie- en productie-omgevingen, en dat er daardoor toch fouten in productie op kunnen treden. Maar toch, als dat met te grote regelmaat gebeurd, dan is het hoog tijd om je acceptatie-omgeving aan te passen.

In een ideale wereld is er geen toegang voor ontwikkelaars/testers nodig in een productie-omgeving. En dat is waar systeembeheer vanuit gaat. Alleen de hoogst noodzakelijke gebruikers hebben toegang nodig op het moment dat dit nodig is, dus niet continu. Zero-trust is een concept waaraan steeds meer getoetst voor ISO-certificeringen. En een heleboel van die certificeringen zijn tegenwoordig een vereiste om nog enigzins zaken te kunnen doen.

Systeembeheer doet wat er nodig is om te voldoen aan die certificeringen. Dat mag dan niet kloppen in jouw idee van hoe een test-, acceptatie- en productie-omgeving is opgezet. Jouw idee betekent echter niet zoveel in hun wereld, daar tellen alleen die ISO-certificeringen. De "speeltuin" voor ontwikkelaars/testers bestaat uit de test- en acceptatie-omgeving en dat zou ruimschoots voldoende moeten zijn. En als dat niet zo is, dan ligt de fout dus eerder aan de acceptatie-omgeving of nog erger, de test-omgeving.

De ideale wereld bestaat niet.in software land

Acceptatie kan nooit hetzelfde zijn als productie. Dat is nooit zo, zelfs niet in de ideale wereld. Maar er zijn genoeg problemen die niks te maken hebben met inrichting maar met volume (aantal calls).

Maar los daarvan, waarom zou een ontwikkelaar geen lees toegang mogen hebben tot de applicatieve logging of de metrieken van productie? toegang tot productie hoeft niet te betekenen dat ze "god" zijn binnen productie. Waarom zou de ontwikkelaar die zelf een CI/CD pipeline in zijn code heeft niet kunnen lezen of dat allemaal wel goed is gegaan in productie door ze lees toegang te geven tot de eigenschappen van de gebruikte sources?

Degene die de applicatie het beste kent is de ontwikkelaar en operationeel beheerder. Waarom zou je dat scheiden door krampachtig de toegang tot gegevens van productie uitsluitend voor systeembeheerders en technisch applicatie beheer mogelijk te maken?

Let wel, wat mij betreft is het werk van systeembeheer heel duidelijk, maar daar past prima bij dat een developer of operationeel beheerder (lees) toegang krijgt tot de logging en metrieken op productie, want daar kan systeembeheer bijzonder weinig mee als ze de applicatie niet door en door kennen.

edit:typo

[Reactie gewijzigd door david-v op 11 januari 2023 17:22]

BaseLine doelt op Azure DevOps. Dat heeft niets te maken met de principes die jij beschrijft. Helaas heeft Microsoft zo'n waardeloze naam gekozen voor deze tool.

Het DevOps principe is juist het verbeteren van samenwerking tussen developers en operations. Tools kunnen daar zeker bij helpen maar ik heb al te veel tenten gezien die dergelijke oplossingen maar ertegenaan gooien om een cultuurprobleem op te lossen.

Precies dat.
Ik word moe van al die verschillende interpretaties van DevOps.
Uiteindelijk moeten je Development teams snel business value kunnen leveren, en moeten ze kunnen innoveren op het tempo dat past bij de organisatie en de business.

Hoe je dat doet? Ja, laat in elk geval Dev en Ops goed samen werken. Dat lijkt me zinnig.
Of je dat doet dmv multi-disciplinaire teams , volledig autonome teams, platform engineering, wel- of geen centraal orgaan: it depends.

Mbt AI, ik gebruik de laatste weken ChatGPT als een soort pair programmer en het werkt echt vrij goed.

Ik denk niet dat dit heel slim is. Ik heb chatGPT een paar eenvoudige zaken laten genereren en het ding is nogal een fantast. Het kan niet rekenen (zegt overigens datie dat prima kan) en als jouw vraag niet rechtstreeks gecovered is door de trainingsdata dan fantaseertie er op los. Het probleem is dat de antwoorden soms met absolute zekerheid worden gesteld en ook redelijk klinken als je het echte antwoord nog niet kent terwijl het gegeven antwoord fout is.

Je moet nog steeds zelf nadenken!

Dan moet je dus iets vragen waar je zelf het antwoord al op weet...

Dan moet je dus iets vragen waar je zelf het antwoord al op weet...

Ja en nee, ChatGPT is geen vragen beantwoorder, het is een creatieve verhaaltjes verteller.

Je kan prima een vraag stellen, maar je moet ook capabel zijn om het antwoord te evalueren op bruikbaarheid. Als je goed kan coden, dan kan je een programmeer vraag beoordelen op code. Het is gevaar is dat je dat niet goed beoordeeld (door lui of laksheid). Maar het voordeel is dat je niet eerst zelf het hoeft te maken, alleen maar te beoordelen.

Ik zie het zo: Vroeger maakte je voor html pagina's met de hand geneste tabellen in notepad, daar zijn we andere zaken voor gaan gebruiken, zoals WYSYWG editors die prima een complex geneste tabel kunnen maken zonder daar een hele tijd mee bezig te zijn, je moest echter wel de html code beoordelen, want soms maakte de editor een regelrechte puinhoop van (MS!)...

Of het verschil tussen zelf een muurtje bouwen of het iemand anders laten doen en dan checken of dat goed is gedaan...

Het verschil tussen een onoverzichtelijke berekening en een onoverzichtelijke geneste tabel, is dat je een foutje in de laatste meteen ziet

Smartass! ;-) Ik bedoel niet dat de tabel niet klopt, ik bedoel de crap die aan de html wordt toegevoegd waardoor de html pagina 3x zo groot is als deze hoort te zijn. Aan de gerenderde html pagina zie je niets mis.

Ah, je bedoelt dat er nu zoiets als een div en (betere) css bestaat die hetzelfde / meer kan, met minder moeite / code. Dat was me idd niet helemaal duidelijk. Wysiwyg editors maakten net zo enthousiast geneste tabellen als divs

Vroeger maakte je voor html pagina's met de hand geneste tabellen in notepad, daar zijn we andere zaken voor gaan gebruiken, zoals WYSYWG editors die prima een complex geneste tabel kunnen maken zonder daar een hele tijd mee bezig te zijn, je moest echter wel de html code beoordelen, want soms maakte de editor een regelrechte puinhoop van (MS!)...

Het soort fouten die chatGPT maakt zijn veel subtieler en beoordelen kan echt problematisch zijn, zeker als je niet goed bekend bent met het probleem waar je een oplossing voor vraagt.

Maar het deel van de hele infrastructuur uitrollen via scripting (wat eigenlijk infrastructure as code is) is al veel ouder, hier was men al mee bezig voor het hele 'cloud' gebeuren. Dat zagen we eigenlijk al toen men van dedicated fysieke servers naar VMs ging, zeker bij de enorme bedrijven. Dat we er nu meer van zien in de 'cloud' zou ik het nog steeds niet als deel van de 'cloud' beweging willen benoemen.

Persoonlijk vind ik infrastructure as code heel cool, maar ook heel gevaarlijk. De afstand tussen de 'script beheerders' (zij die al hun systemen beheren dmv. scripts) en de daadwerkelijke servers/software is al groot en wat ik in de praktijk zie is dat die afstand alleen maar groter wordt. Ik zie het risico voor enorme fouten veel groter worden, niet omdat 'infrastructure as code' een slecht idee is, maar omdat je verwacht dat je infrastructure op een bepaalde manier functioneert. Als dat opeens door settings of patches heel anders functioneert en dat je daar niet van op de hoogte bent of niet/slecht is gedocumenteerd dan kan dat heel fout gaan.

Het is bv. niet de eerste keer dat ik beheerders heb meegemaakt die nog nooit hebben aangemeld op de servers die ze beheren. Ja, maar we zien 'alles' via scripting en logging! Maar soms zie je dus niet alles omdat je daarvoor (nog) niet script en logt... Laat ik een voorbeeld geven: Gebruikers hebben opeens zware performance problemen op verschillende RDP servers, ik meld aan op die servers en mijn conclusie is vrij vlot dat er inderdaad iets zwaar mis gaat met servers, steeds meer servers. Uiteindelijk blijkt dat een ander onderdeel beheerders doodleuk extra software is gaan deployen (via scripting) naar alle (VM) servers ivm. het tellen van licenties... Geen documentatie, geen interne berichtgeving. Ik heb heel wat moeten uitzoeken en moeten overtuigen voordat de andere partij toegeef dat dit een issue was omdat ZIJ geen performance issues zagen... Nu kan je dat gooien op slechte beheerders (dat waren ze trouwens niet), maar doordat je zo een afstand heb tussen wat je doet en de mensen die er daadwerkelijk mee werken kom je heel snel in een bepaalde mentaliteit terecht, niet iedereen (jij niet natuurlijk! ), maar een hele hoop zeker wel.

De afgelopen ~10 jaar doe ik al aan 'cloud' migraties en doe daar over het algemeen heel weinig met infrastructure as code, vele jaren bij MSPs gezeten voor het MKB, daar zit je zo vaak met heel specifieke implementaties, dat infrastructure as code meer werk opleverde dan dat het bespaarde (en het was in 2013 een heel stuk complexer dan dat het nu is. Maar zelfs tijdens de pandemie zie je bij grotere bedrijven dat men wil beginnen aan infrastructure as code, maar dat niet alle infrastructure daar klaar voor was. Zo heb ik een tijd terug naar de oplossingen van MS zelf gekeken voor O365, ja dat kon wel, lastig, koste veel tijd en was omslachtig, maar het was ook nog eens een keer hardstikke onveilig! Gewoon niet fit for purpose buiten testopstellingen, ondertussen zie ik wel zaken voorbijkomen waaruit het lijkt dat het nu wat veiliger kan, maar ik zie nog steeds 'uitdagingen'... Denk aan Global Administrator accounts welke met username en ww in het script moeten staan...

Deel van die grote 'cloud' verschuiving is niet alleen lift-and-shift (waar ik een gruwelijke hekel aan heb), maar juist ook allerlei diensten die taken integreren die je zelf allemaal lokaal moest hosten/configureren. Denk aan lokale SSO, MFA, etc. oplossingen die nu allemaal geïntegreerd aangeboden (kunnen) worden. Ik zie juist als je een goede 'cloud' migratie uitvoert je met een heleboel minder bewegende onderdelen zit dan als je alles zelf hoste/deployde. En tegen prijzen waar lokale oplossingen niet tegenop kunnen boxen.

Iac moet je de aplicatie ook voor ontwerpen. Je moet niet proberen o. Iets custom in iac te passen.

Bij iac zijn ook altijd zo min mogelijk componenten. En die mini deployments praten met elkaar via api. Dan wordt je iac ineens heel anders dan proberen 30 servers met terminal service in een iac te draaien

Iac is dan ook niet bedoeld voor iaas maar meer voor saas en paas

[Reactie gewijzigd door Scriptkid op 8 januari 2023 23:03]

Precies dit. Ik zie in de comments veel systeem beheer achtige bedenkingen.. dát hele gebied is de paradigm shift (mening).
DevOps of infrastructure as code is goed te maken met AI. Apps draaien op allerlei HW Horizontaal schalend helemaal managed.
Ops zal dus (pun) meer Opsolete worden. Ja dit gaat met verlies van maatwerk, maar veel bedrijven zullen zich realiseren dat ze wel meer kunnen sturen bij cloud based werken. Dit ten opzichte van weinig grip op IT.
Maatwerk kun je nog steeds zelf maken en hosten, in hetzelfde (Kubernetes) cluster. Als bedrijf focus je dan meer op je core business... Wel meer eenheidsworst..

Op dit moment, als developer, wil ik geen I.P. code naar een webservice AI sturen. maar als je een pair programming company-AI-buddy hebt, die allerlei vragen kan beantwoorden, over coding standards of architectuur, of simpelweg 'which code manages endpoint XY?' .. dat wil ik wel! En dat is niet weg lijkt het

[Reactie gewijzigd door sjongenelen op 8 januari 2023 19:12]

ChatGPT is echt een fantastische tool. Prive gebruik ik het ook, voor m'n rpg en programmeerprojectjes.

Professioneel zal ik het echter niet inzetten: mijn opdrachtgevers vinden het niet zo leuk als ik details over waar ik mee bezig ben naar buiten breng. En algemeenheden kan ik ook met stack overflow/google oplossen.

Inderdaad, ChatGPT is echt verrekte goed. Het verbaast me echt hoe goed het is, het kan dingen in 5 seconden uitvogelen waar ik een halve dag nodig heb, en dat is MET mijn complete achtergrond als IT'er, en weken aan training en leren van een specifiek systeem. En nee, de dingen die ik vraag zijn niet 1:1 van google te trekken. Het loopt echt informatie van meerdere bronnen te combineren en dat is echt nieuw.

Wat het nog mist is 1 punt: Het is gebaseerd op een statisch model. Soms komt het met een verkeerd antwoord en dan zeg je dat terug en dan krijg je vaak "Je hebt gelijk, sorry voor het verkeerde antwoord, het juiste is ....". Echter, het kan daar niet van leren dus de volgende die de originele vraag stelt, krijgt weer hetzelfde foute antwoord. Ik denk dat dat de volgende stap in de ontwikkeling gaat zijn, en dat het daarna echt verrekte snel kan gaan omdat er geen limiet meer is hoe snel het kan leren. Er zullen wel wat uitdagingen zijn van gebruikers die de zaak proberen te manipuleren en de foute kant op te sturen. Denk dat dat ook de reden is dat hij nu niet kan leren van interacties.

Maar de potentie is enorm, en ik vind het soms bijna schrikbarend hoe goed het obscure dingen kan combineren tot een werkend geheel dat niet als zodanig eerder bestaat. Dit is echt absoluut geen 'chattende google' zoals een collega met oogkleppen op laatst zei.

Natuurlijk moet je de antwoorden met een korreltje zout nemen. Ik denk dat ze ChatGPT qua bewoording iets te autoritair hebben gemaakt en mensen trappen daar in en denken dat hij echt alles zo goed weet. Ze hadden hem beter kunnen laten zeggen: "Volgens mij is ..." in plaats van "Het is ...". Ik denk dat je dan een stuk minder klachten ziet van mensen die kwaad zijn omdat sommige antwoorden niet kloppen.

[Reactie gewijzigd door GekkePrutser op 8 januari 2023 23:53]

Al die verschillen die je beschrijft zijn paradigmaverschuivend. Je kunt je als organisatie nog meer focussen op je core business. Je hoeft veel minder tijd te besteden aan strategische IT beslissingen omdat je gewoon volgt wat je leverancier biedt. Als ik bij ons op het werk kijk wat "iets simpels" als een Office upgrade vroeger betekende. Dat waren gigantische projecten met flinke operationele impact. Nu gebeurt dat op de achtergrond en niemand merkt er meer iets van.

Al die verschillen die je beschrijft zijn paradigmaverschuivend. Je kunt je als organisatie nog meer focussen op je core business. Je hoeft veel minder tijd te besteden aan strategische IT beslissingen omdat je gewoon volgt wat je leverancier biedt.

Of dat wat er geboden wordt nu aansluit op je business of niet. Je wordt voor bedrijfskritische processen afhankelijk van een 3e partij die je business al dan niet zal willen ondersteunen. Maatwerk zit er in ieder geval niet meer in, een directeur die roept "ik wil dit NU geregeld hebben" heeft ook het nakijken...

Als ik bij ons op het werk kijk wat "iets simpels" als een Office upgrade vroeger betekende. Dat waren gigantische projecten met flinke operationele impact. Nu gebeurt dat op de achtergrond en niemand merkt er meer iets van.

Oh, was dat maar waar. De problemen zijn nog verergerd, omdat dergelijke changes niet langer bij het bedrijf zelf in beheer zijn. Maar de effecten wel, wanneer de eindgebruikers beginnen te piepen over dat het een en ander niet meer werkt - er wordt, omdat de changes niet meer in beheer zijn bij het bedrijf immers ook geen test en acceptatie meer gedaan.

Ik ben geen fan van "de cloud". Het uitbesteden van bedrijfskritische processen betekent dat je het voortbestaan van je bedrijf van een ander afhankelijk maakt. Een ander die jouw als kostenpost heeft.

Dat laatste ben ik het totaal mee oneens.

Je maakt je bedrijf met on-prem oplossingen juist veel afhankelijker van die ene systeembeheerder die een roll-back moet doen op een kritiek moment en je zult net zien dat die beheerder net op Vrijdagmiddag aan de pils zit nadat Rupert de stagiair besloot om Vrijdagmiddag een update te doen. Of wat denk je van HW redundancy?

Lullig als er een on-prem server uitfikt, toevallig stonden de main en backup server naast elkaar, lullig joh, alles kwijt.

Switch dood? Mag er iemand met een vervanger in de auto snel op pad om het te vervangen..

Da’s vrij vervelend als je een online oplossing biedt die letterlijk geld verliest per minuut geen uptime.

Er zijn veel grote bedrijven die immutable infra in de cloud goed toepassen en zich anders dan de capaciteit totaal niet afhankelijk maken van vendor specifieke services.

On-prem heeft zeker zn plek, zeker voor stage en dev en probeersels maar, zeker als je een serieus bedrijf bent, zijn er weinig business cases om production on-prem te doen.

Lijkt mij een prima reden om hybride te werken. Het kán on-prem, maar ook in de cloud. Gaat het mis, dan switch je van omgeving.

Dat lijkt me dan weer een kostbare oplossing.

Overigens zijn er wel bedrijven die een "on-prem cloud" achtige oplossing hebben, vaak grote partijen zoals KPMG en zo verder die bedrijven als HP, IBM etc. heel veel geld betalen om hun eigen "cloud" te bouwen (ze noemen het dan cloud maar in feite is het on-prem of private cloud, al is "de cloud" ook gewoon andermans server maar dan met een bak meer redundancy).

Redenen kunnen zijn, zoals bijvoorbeeld voor een club als KPMG, dat de data die ze opslaan dusdanig gevoelig en beveiligd moet zijn, dat het niet compliant is om het in een public cloud te hosten.

Het is dan een private cloud maar wel een managed private cloud waarbij de vendor ook bepaalde SLA's moet halen.

Zelf een on-prem oplossing hebben kan zelfs voor productie een optie zijn maar er kleven gewoon risico's aan.

soms moet je wel vanwege regelgeving. Patiëntendata mag b.v. alleen op systemen die geaudit zijn, binnen de grenzen van het netwerk. Die data draait dus op de interne cloud. Hetzelfde type data, maar dan b.v. op niet-medische data, schaalt dan lekker op de cloud, zodat het het interne systeem niet belast (alleen het budget, dat dan weer wel helaas)
Als je de processsen dus compatible maakt kun je schalen waar nodig

een directeur die roept "ik wil dit NU geregeld hebben" heeft ook het nakijken...

Als er directeuren zijn die dat willen dan zal de markt daarop inspringen en kun je een service afnemen die 24/7 veranderingen in het systeem gaat ondersteunen. En directeuren roepen dit eigenlijk alleen maar tijdens kantoortijden, dus wordt het nog gemakkelijker om wijzigingen direct door te voeren.

Daarnaast zullen bedrijven die afhankelijk zijn van onmiddellijke wijzigingen daar zelf al op inspelen door een flexibele service af te nemen met zelf personeel al dan niet op afroep die daarmee om kan gaan)

Directeuren die dingen stante pede gefikst willen hebben kunnen dat nog steeds, maar daar hangt dan ook een fiks (en nu wel zichtbaar) prijskaartje aan... en meestal willen ze dan toch wat minder snel
Al dat maatwerk dat ik de afgelopen jaren heb gezien betekende vooral veel broddelwerk, niet-onderhoudbare meuk die met kunst en vliegwerk toch maar in de lucht gehouden werd, want... reasons.

Nu kan dat niet meer, en is de keuze simpel: eenheidsworst of heel veel betalen voor je maatwerk. Dan blijkt dat die eenheidsworst (soms in andere vormen gestompt) ook prima te werken. En zo lang je niks geks vraagt, wordt het best betrouwbaar geleverd. Niet 100%, maar dat was vroegah ook alleen maar als je in-house kennis had. Werd er toen ge-outsourced, dan was je ook afhankelijk van een derde partij, en ook die was niet altijd bereikbaar.

Ik ben een fan van de cloud als alternatief voor outsourcen naar peperdure custom hardware-speeltjes. Ik ben vooral geen fan van outsourcen van je bedrijfskritieke processen, ongeacht of dat de 'cloud' (someone elses computer) of een oude partij is.

Ik ben geen fan van "de cloud". Het uitbesteden van bedrijfskritische processen

Cloud is niet veel anders dan een hoop datacenters bij elkaar met een flinke dosis aan "klik het zelf bij elkaar" en draai het waar je maar wilt.

Er is geen enkele serieuze partij in Nederland die niet voor een deel zijn bedrijfskritische processen bij een derde partij onderbrengt in een datacenter. Natuurlijk heb je nog bedrijven die een plek huren bij een datacenter en alles zelf regelen, maar mijn gevoel zegt dat dat steeds minder wordt. De reden is heel simpel, bedrijven willen zich niet bezig houden met hardware om hun bedrijfsprocessen te draaien. Ze willen een SLA met garanties dat de hardware draait (zoals bij elke willekeurige datacenter) en ze willen zich voornamelijk met functionaliteit bezig houden, dat van hun bedrijfsproces. Mensen in dienst hebben om een router/server/nas te onderhouden is niet hun core business, dus krijg je een verschuiving naar partijen die dat voor je doen, in een eigen datacenter, of bij een cloud aanbieder. Deze laatste hebben het zo goed voor elkaar (certificeringen, wereldwijde dekking, continu innoveren enz) dat veel bedrijven daarvoor kiezen.

Ik ben al ook jaren om, de cloud heeft voor mij werkzaamheden een enorme versnelling teweeg gebracht en de devops gedachte nog dichterbij gebracht.

De definitie van paradigmaverschuivend is niet heel duidelijk.
Tot nu ging ik er altijd vanuit dat het bij het verschuiven van paradigma's ging om maatschappelijke veranderingen die onomkeerbare veranderingen veroorzaken in de sociale structuur van de maatschappij.
Als wij constateren dat het risico van het inzetten van AI op dat vlak ligt, dan kunnen we er als samenleving ook voor kiezen om een stapje terug te doen, al verwacht ik niet dat de meerderheid van de Nederlandse bevolking daar ooit voor zal kiezen...

Kosten zijn toch niet wat een paradigma bepaald?

Ik denk dat hij het heeft over de manier hoe je je producten aanbied en de wensen van de klant.

Kosten zijn voor mij niet wat een paradigma verschuiving bepaald. Als dat is hoe je mijn bericht op vat dan heb ik dat verkeerd geschreven of heb je het verkeerd begrepen.

Een paradigma verschuiving betekent, voor mij dat er fundamentele verandering plaatsvindt in hoe we werken. Een of meerdere situaties op een andere manier aanpakken doordat we nieuwe inzichten of technieken hebben. Je software naar een datacentrum verhuizen voelt voor mij niet als een nieuwe inzicht of techniek. Het is nog steeds dezelfde techniek. Je verhuist de hardware slechts naar een andere locatie waar de hardware gecentraliseerd is.

Maar ik denk dat ik het ondertussen weet; de man bedoelt natuurlijk activiteiten zoals Microsoft 365 en het aanbieden van andere software as a service. Dat hoeft niet persé vanuit een datacentrum te gebeuren, maar dat is meestal wel de beste plaats ervoor. Dat was in het verleden alleen weggelegd voor de grote jongens en in dat opzicht is het paradigma verschuivend voor veel bedrijven.

[Reactie gewijzigd door MaestroMaus op 8 januari 2023 14:23]

Ik zou zeggen een paradigma verschuiving is wanneer een uitbreiding of verfijning van de oude situatie zo belangrijk blijkt dat vrijwel alles er door wordt overgenomen. (Newton -> Einstein).
En saas inderdaad ook.

https://www.betekenis-definitie.nl/Paradigma
My 2cts

Waar een bedrijf eerder bijvoorbeeld 1000 mensen op een groot duur kantoorpand had en een eigen serverpark, zou men straks een paar kleine goedkope locaties kunnen hebben voor team-meetings en klantencontact (hoewel je net zo goed een rijdende balie kunt maken die een regio bedient) en het team gaat maar naar een restaurant of bij elkaar thuis als ze willen) het meeste werk gebeurt thuis. Kunnen ze ook gelijk de facilitaire diensten deels inkrimpen en deels opdoeken. Verandering van het aanbod van banen, verandering van hoe we werken en verandering van waar we werken. Dat kun je toch wel een fundamentele verandering noemen?

je hebt nog steeds mensen nodig die de servers configureren, up-to-date houden, etc. Maar nu doen ze dat in de cloud

En dit gaat dus allemaal vol automatisch. Ik gebruik best wel wat cloud services, maar servers, IAAS? Nee, dat doe ik allang niet meer. De machines waarop mijn services draaien worden automatisch gepatched. In sommige gevallen (bijvoorbeeld databases) kan je ook kiezen wanneer dat onderhoud moet plaatsvinden.

Je ziet wel steeds meer AI in de cloud. Bijvoorbeeld als er iets in je omgeving anders is dan normaal (extreem veel traffic, ineens hoge cpu/memory gebruik). De AI bepaald dan of dat een "normale" situatie is voor jouw diensten en zal daar dan op reageren, bijvoorbeeld door bij/af te schalen of de alarmbellen laten rinkelen.

Ik denk dat het AI stuk in de cloud alleen maar meer en meer gaat worden. Misschien is dat wat hiermee bedoeld wordt. Ik ben heel benieuwd naar de ontwikkelingen.

Ik had ooit een artikel gelezen waarin volgens wetenschappers in 2050 AI het menselijk brein zou benaderen of zelfs voorbij gaan. Volgens dat zelfde artikel was het van levensbelang om in de komende decennia heel goed vast te leggen wat wel en niet verantwoord met AI, en binnen welke kaders dat moet plaatsvinden. Allemaal heel interessant, maar tot nu toe was/is AI nog niet zo verdiend in onze maatschappij dat we daar iets van vinden. Het meest in het oog springend zijn deepfakes. Dat gaat de komende decennia alleen maar meer en meer verstorend zijn voor de maatschappij. Of dat goed is of niet .... Dat is de vraag die we ons moeten stellen.

Edit:typos

[Reactie gewijzigd door david-v op 8 januari 2023 19:20]

Maar wat voor 'paradigmaverschuiving' heeft hij het over m.b.t. de cloud? Het is niet alsof je iets nieuws of anders kan met 'de cloud'.

Ik denk dat je het nogal onderschat. Een goed voorbeeld is remote werken. Er zijn nu complete bedrijven zoals bijvoorbeeld Spotify die remote werken. Dat was zonder de cloud onmogelijk.

Er zijn heel veel modellen in de cloud waar je minder tot geen servers hoeft te beheren. Denk aan serverless of Paas diensten.

Verder heeft de cloud een versnelling gegeven aan de DevOps beweging waarbij teams meer zelfstandigheid hebben ipv alles via centrale it organisaties moeten regelen.

Is er dan geen beheer meer nodig? Tuurlijk wel maar wel wat minder of in andere vormen

Ik heb niet inhoudelijk gelezen wat Nadella daar precies over zei, maar paradigmaverschuivend in hun omzet ja.

Het grappige is dat jij het verhaal vanuit jouw optiek bekijkt en Nadella vanuit die van Microsoft. Voor jou is de plek waar data staat verplaatst. Voor Microsoft is er een enorm verdienmodel werkelijkheid geworden. Voorheen konden ze serversoftware leveren en misschien nog wat support. Nu kunnen ze mensen en bedrijven sturen naar hun cloud. Ze kunnen de prijzen ophogen wanneer ze willen omdat er geen weg terug meer is. Ze beschikken over enorme hoeveelheden data die geanalyseerd worden en die analysedata kan weer verkocht worden zodat er extra aan wordt verdiend. Met andere woorden het is Microsoft gelukt om ons in hun netten te vangen.
Nadella ziet dat dat binnenkort nog een keer kan met AI en dat Microsoft dan nog meer aan de gebruikers gaat verdienen. Hij denk alleen dat hij nog even geduld moet hebben omdat we even geen nieuwe uitgaven doen omdat we dat enerzijds net hebben gedaan en anderzijds in een recessie zitten.

M.a.w. het kabbelt gewoonlijk door zoals het altijd gedaan heeft. Een paar vette jaren, een paar magere jaren en ondertussen wordt de mensheid nog afhankelijker van automatisering en electronica. Met een beetje mazzel hebben we ondertussen een paradigma verschuiving of een grote ontwikkeling op electronisch vlak waardoor de zaken weer iets eerder in beweging komen.

Die afhankelijkheid van automatisering en AI gaan we heel hard nodig hebben. Onze huidige maatschappij is niet houdbaar met de hele babyboom-generatie die al met pensioen aan het gaan is. Over 20 jaar verwachten ze dat 25% van de bevolking gepensioneerd is, dat betekent dat er op basis van de huidige maatschappij een hoop openstaande vacatures zullen zijn die opgevuld moeten worden. Als we minimaal in stand willen houden wat wij nu hebben.

Problematische is wel dat grootste deel van die openstaande vacatures ´hands-on´ vacatures zijn. Ik zie het werk van een zorgkundige niet snel ingevuld worden door ai.

Tenzij robots plots een gigantische sprong voorwaarts maken

Aan de ene kant vervang je personeel door automatisering, aan de andere kant kunnen die vrijgekomen mensen elders ingezet worden. En dat is niet een proces van een paar jaren, maar meer naar de komende decennia. Dat gaat langzaam een andere richting op groeien, het punt is dat we geen andere keuze hebben.

Die mensen kunnen niet per definitie elders ingezet worden. Een IT'er maakt nog geen goede verpleegkundige. Mensen glijden hierdoor alleen maar af naar mindere banen of bijstand. Slechts een enkeling is flexibel genoeg om in een andere branch succesvol te worden.

Binnen een individuele loopbaan of leven heb je natuurlijk gelijk, radicale omschakelingen zijn maar weinigen gegeven. Maatschappelijk gezien over decennia is het anders, dan gaat het meer om andere scholing e.d.

Heb je daar substantieel bewijs voor? Ik ben echt niet het meest flexibele persoon, maar heb oa als design engineer, install engineer, lean agent, computerverkoper, postbode, vakkenvuller, assistent kok en (laagdrempelig) netwerkbeheerder gewerkt.

Ik denk als er iets is dat mensen goed in zijn, is het aan aanpassen. Het enige waar het nu wat mij betreft misgaat is dat onze huidige markt specialisme onevenredig waardeert. Dus als je zoals ik 5 jaar lang postbode bent geweest zal je echt aan de bak moeten om competitief te blijven met een ontwerper die al 10 jaar er zit.

Ik heb het ook niet over vandaag of morgen maar over de komende decennia, automatisering gaat ook niet in een dag. Genoeg tijd om aan te sturen op andere scholing.

En dat is niet een proces van een paar jaren, maar meer naar de komende decennia. Dat gaat langzaam een andere richting op groeien, het punt is dat we geen andere keuze hebben.

Als het een proces van decennia is, dan schiet je het doel voorbij.
De huidige influx in de vergrijzing komt door de baby-boom generaties net na de oorlog. Zodra die hun laatste levensjaren gesleten hebben, kom je weer terug op een meer normaal ratio van werkenden tov gepensioneerden.
Wat we vooral niet moeteb doen is overhaast alles om gaan gooien zonder met die terugloop rekening te houden, want anders zijn we op een later tijdstip nog veel verder van huis.

Problematische is wel dat grootste deel van die openstaande vacatures ´hands-on´ vacatures zijn. Ik zie het werk van een zorgkundige niet snel ingevuld worden door ai.

Dan nog kun je wel automatiseren zodat er minder onnodige handelingen gedaan hoeven te worden. Zo zijn er sensor-systemen in de zorg waarmee kan worden gedetecteerd dat iemand uit bed valt of rond gaat dwalen. Daardoor hoeft de verpleger geen nachtelijke rondes te maken, wat grotendeels verspilde tijd is, maar juist ook voor onrust zorgt bij slapende bewoners waardoor die sneller uit bed vallen en gaan ronddwalen.

Zo wordt de zorg beter en hebben de verplegers meer tijd voor andere dingen.

Precies. Een ander goed voorbeeld vind ik dit product van Philips: https://www.philips.nl/he...lthdot-wearable-biosensor

Patiënten kunnen zo thuis gemonitord worden via LoRa na een operatie, in plaats van in het ziekenhuis te blijven. Zo'n sensor kost geld natuurlijk maar de besparing voor het ziekenhuis is enorm.

In de zorg kan echt nog heel veel geautomatiseerd worden om zo capaciteit vrij te maken voor werk dat niet kan worden geautomatiseerd.

En die stroomversnelling komt vanzelf als blijkt dat er wel geld is maar geen mensen om het werk te doen. En er zijn ook al een hoop quick wins die de zorg kunnen ontlasten. Zet bijvoorbeeld overal waar de thuiszorg ook voor schoonmaak zorgt een stofzuigrobot neer en je hebt voor weinig geld veel effect.

En DAT is dus wel zo, de komende 10 jaar gaat de ontwikkeling van robots gigantische zijn, AI en motoriek neemt nu al behoorlijke stappen, en juist op plekken als zorg zijn ze hard nodig, de mensen die nu op de werkvloer werken kunnen het eigenlijk gewoon al niet meer aan, deels door regelgeving en deels door tekort aan personeel.

In mijn directe omgeving zie ik anders veel toekomstige zorgmedewerkers afhaken om : salaris—> kan ik nog wel een huisje betalen, werkdruk —> veel weekend en nachtwerk dat niet gewaardeerd wordt, slechte opleidingen

Het is een drama in zorgland …

Ik geloof er niks van. Er wordt veel onzinnige effort gestoken in automatisering en Al van problemen die er niet echt zijn, en zeker niet de grootste problemen die we nu hebben en "later" gaan krijgen i.v.m. de "25%" gepensioneerde bevolking. Er staan heeft veel vacatures open die eigenlijk voor bullshit banen zijn.
Het automatiseren van werk is voor een heel groot heel al een opgelost probleem, maar toch blijven we veel tijd en moeite steken in iets te automatiseren. Deze laatste stukjes automatiseren is veel lastiger om uit te voeren. Je ziet dit vaak terug doordat men naar het magische "Al" gaat grijpen. Wat we moeten doen is het overgebleven werk makkelijker maken, niet automatiseren. We moeten onnodig werk elimineren, niet automatiseren. Neem bijvoorbeeld de zorg, daar is te veel werk te weinig mensen, toch? Een groot deel van dit werk gaat zitten in onnodige administratief werk. Dit werk moet je verminderen, en vereenvoudigen. Men is niet de zorg in gegaan om administratie te doen, dit werk doet afbreuk aan het werkplezier, en zorgt daardoor voor een hogere werkdruk. Je kan het automatiseren, maar dan ben je onnodig werk "automatisch" aan het maken, werk dat vervolgens weer door het personeel gecontroleerd moet worden. Om werk te automatiseren heb je mensen met domein kennis nodig, en programmeurs. Om onnodig werk te elimineren, met je alleen mensen met domein kennis nodig.

Ik nodig je uit om je eens in te gaan lezen in 'het magische AI', want ja het begint nu op een niveau te komen waar op het echt interessant wordt. Dan moet je in acht nemen welk niveau dat bereikt heeft over tien tot twintig jaar, en ook waar dit allemaal toegepast gaat worden. Daarnaast kan automatisering en AI ook een hoop taken overnemen van de problemen die je net aanstipt.

Buiten valt er nog enorm veel te automatiseren, maar dan er wel ruimer gedacht worden. Je hebt het over programmeurs, dat is nog wel één van de simpelere dingen om te vervangen. Neem eens een kijkje bij ChatGPT en verbaas jezelf op wat voor niveau AI tegenwoordig dergelijke taken kan uitvoeren, en daarbij bedenken hoe dat er in de toekomst uit gaat zien. Op een gegeven moment kom je op een punt waar AI zijn eigen algorithmes kan verbeteren.

Er zijn nog genoeg banen die vervangen kunnen worden, de overheid kan aansturen op andere zaken qua scholing. Beroepen die minder makkelijk te vervangen zijn. Daar moet je nu al over nadenken, want die 25% over 20 jaar is geen grap. Na 1970 zie je dat het aantal geboortes inzakt, het einde van de babyboom. Die hele groep gaat de komende 20 jaar met pensioen. Er zijn simpelweg niet genoeg mensen om al die banen die nu over de gehele linie vrij komen op te vullen. En ja daar moet je nu al over nadenken, anders loop je staks heel hard achter de feiten aan.

AI als oplossing naar voren schuiven is bullshit. Het werk versimpelen levert veel meer veel sneller op.

Ik nodig je uit om je eens in te gaan lezen in 'het magische AI', want ja het begint nu op een niveau te komen waar op het echt interessant wordt.

Dat neemt het zeer sterke punt van @elmuerte niet weg. Eerst onzinnige dingen strippen. Dat kan nu al gebeuren. Op AI wachten is dus niet nodig.

[Reactie gewijzigd door LurkZ op 9 januari 2023 08:13]

Afhankelijkheid van IT is een mentale keuze.
Het is mogelijk om - tot een bepaald niveau - hierin onafhankelijk te zijn en toch voluit te participeren in de samenleving.
Als we vooruit kijken naar 'over 20 jaar', dan kunnen we er ook voor kiezen om het welvaartsniveau te verlagen.
Of de meerderheid van 'de huidige samenleving' dat wil, is een andere vraag...

Heel veel(merendeel?) van die openstaande vacatures zijn niet met automatisering en AI op te lossen.

Denk b.v. aan de personeelstekorten in de zorg of de vraag naar technische mensen in vrijwel elke sector.

Ik zie nog niet zo snel AI als verpleegster in een ziekenhuis of als vakman om zonnepanelen op je dak te leggen.

Vergeet niet dat veel millennials jeuk krijgen als ze iets met hun handen moeten doen.

Niks anders dan de normale gang van de Varkenscyclus, waar de piek door corona iets is uitvergroot en het dal ietsje dieper is door de oorlog en hier en daar lichte recessie.

En die Varkenscyclus bij sommige sectoren heel goed zichtbaar, met name bij relatief generieke producten met voldoende concurrentie. Geheugen is daar een goed voorbeeld van, het is gestandaardiseerd en voor de meeste producten maakt het niet uit of je Samsung, Micron of SK Hynix geheugen hebt.

Geheugen is daar een goed voorbeeld van, het is gestandaardiseerd en voor de meeste producten maakt het niet uit of je Samsung, Micron of SK Hynix geheugen hebt.

De industrie verhult juist ook welke chip op welke geheugenmodules zit, wat het voordeel heeft dat assembleerders als Corsair en G.Skill de chipproducenten tegen elkaar uit kunnen spelen. Er is zeker wel een groep consumenten die het best overklokbare geheugen willen hebben en die zelf lijsten bijhouden van welke chips in welke geheugenmodules worden gebruikt. In elke generatie heb je een chip die het veel beter doet (Samsung B-Die bij DDR4 en vooralsnog Hynix A-Die bij DDR5).

Mocht het stroomnet onbetrouwbaar worden, komt er weer een kentering.

Ja en nee. Ja, het volgt de normale economische cyclus van groei en krimp en nee, ai is de volgende disrupter met onbekende gevolgen voor de tech-industrie en de samenleving als geheel. Al denk ik dat twee jaar als horizon daarvoor veel te kort is.

Wellicht voor de consumenten wat betere jaren (kwa prijzen) gezien de vraag daalt.

Voor consumenten die veel hardware hebben en willen upgraden zullen dit geen goede tijden worden.

Vraag daalt maar aandeelhouders willen wel meer dus prijzen omhoog om de lage verkoopaantallen te compenseren

Anderzijds zal de toegenomen vraag naar tech afnemen nadat die is gestegen tijdens de coronapandemie.

Ergens vind ik vreemd dat dit als argument gebruikt word dat het de komende 2 jaar minder zal gaan met de tech industrie. Die vele tech aankopen tijdens de pandemie was alleen maar extra voor de tech industrie en ze in die tijd goede winsten hebben kunnen maken. Dan is het ergens een non-argument dat de winsten daarna teruglopen doordat er minder gekocht word.

Dat inflatie invloed heeft vind ik weer iets anders en wel een logisch gevolg is dat mensen minder tech kopen. Maar ook dan denk ik weer van waarop je verliezen baseert, baseer je dit op minder winst maken of op echt verlies maken. Zelf ben ik van mening dat als een bedrijf evenzogoed nog winst maakt dat er dan geen sprake is dat het minder gaat.

Ken je rupsje nooit genoeg ? Dat een bedrijf "dipt" is slecht nieuws voor aandeelhouders. Dus dan waarschuw je als bedrijf zijnde maar beter alvast dat er minder vette tijden aankomen want de aandeelhouders zijn al gewend aan het resultaat.

Ik weet wel hoe het commercieel gezien in elkaar steekt maar dat wil voor mij nog niet zeggen dat ik het er ook mee eens ben. Dat is dus meer wat ik ermee zeggen wil.

Nee, ik vind het ook van de pot gerukt. Mijn begrip voor commercie en hoe ik er persoonlijk in sta ligt ook mijlenver uit elkaar en toch begrijp ik ook dat de commercie in zijn beste vorm er voor zorgt dat wij het hier zo goed hebben. (Tezamen met een gezond politiek klimaat, uiteraard is dat ook weer afhankelijk van aan wie je het vraagt) Hoe dan ook, wij zijn het met elkaar eens haha.

CNBC-TV18 valt onder CNBC (en TV18), maar het is wel gewoon een los medium uit India dat hun eigen content maakt. Het klopt dus niet dat dit een CNBC-interview is, aangezien je dan de Amerikaanse sectie zou verwachten.

Inderdaad, aangepast. Bedankt voor de opmerking!

Wat opmerkelijk is, is dat de techindustrie vooral reageert op aandeel koersen en inflatiecijfers en hier handig gebruik van maakt. In 2022 werden de meeste cloud licenties voor gebruikers tussen de 10 en 20% duurder en hebben ze net aangekondigd in maart de prijzen met 11-20% te verhogen om valuta verschillen en 'prijsharmonisatie' te doen. Dat is dan afhankelijk van de producten en diensten die je afneemt een prijsstijging van 20-40% in 1 jaar tijd.

Omdat je alles tegenwoordig per gebruiker afrekent is er geen enkel schaalvoordeel meer te behalen in het gebruik van Microsoft producten en is de marge ook beperkt - maar als je de absolute en relatieve winstcijfers erbij pakt dan ziet dat er niet zo negatief uit als Nadella doet voorkomen.

Een ander element is dat ze structureel onprem oplossingen (die nog wel beperkte schaalvoordelen kunnen bieden) relatief veel duurder hebben willen maken. Daar is de Europese commissie enigszins voor gaan liggen en doet daar verder onderzoek naar.

Ik begin mezelf toch af te vragen of we er zo goed aan hebben gedaan om massaal in de pay per month per user systematiek te trappen zonder te bedenken of er op de lange termijn nog wel een weg uit is. Microsoft licenties beginnen voor veel bedrijven de grootste kostenpost voor IT te worden en met prijsstijgingen en licentieveranderingen als afgelopen jaar werken we straks allemaal voor Microsoft.

Iemand die de goocheltruc doorheeft.

Nee, wat is de truc ?

Waar heb je gezien dat ze in maart weer gaan verhogen?

Inmiddels gevonden https://news.microsoft.co...-for-the-microsoft-cloud/

[Reactie gewijzigd door zx9r_mario op 8 januari 2023 21:32]

Ik vind paradigmaverschuivend nogal een zware term, zeker voor iets wat nog moet gebeuren. Doet me een beetje denken aan de hoe ons rond het populair worden van internet steeds werd beloofd hoe het internet ons leven zou veranderen, met haar ongekende mogelijkheden.

‘Interactief’ was toen het toverwoord. Ja, internet stelt ons in staat om bijvoorbeeld thuis te werken en dat is verdomd handig, maar geen paradigmaverschuiving. We doen nog steeds hetzelfde werk. Ik koop nog steeds dezelfde spullen. Ik lees nog steeds dezelfde krant. Via internet in plaats van op papier, maar de basis is hetzelfde. Zelfs het ‘interactieve’ is nogal teleurstellend. Een videootje hier en daar, maar dat is het dan wel. Na het lezen van een artikel over huizen, krijg je nog een paar artikelen over huizen te zien, maar daar houdt het dan wel mee op. Ook als je nooit interesse toont in bekende Nederlanders, krijg je toch weer elke dag de roddelrubriek te zien.

Er is heel veel lucht in geblazen met corona en lage rente. Het is heel goed dat die er nu weer (vooral bij de crypto's) uitloopt. Technologie zal blijven en steeds belangrijker worden.
Wel zie je door de geopolitiek dat fysiek toegang en aanwezigheid weer belangrijker is geworden. China wordt afgesloten van highend halfgeleider technologie en kennis, en andere delen moeten vechten voor de zeldzame metalen.
Het is dus niet genoeg om de beste producten en de slimste oplossingen te hebben, je zal of heel slimme moeten kunnen onderhandelen of gewoon dom geluk moeten hebben in het juiste continent te zitten.
Waarschijnlijk zullen de smokkelaars gouden tijden hebben (al sinds Oekraine eigenlijk).

ben benieuwd dan ja de komende jaren

Aandeelhouders gaan niet over de ontslagen. Dat er mensen uit gaan is gewoon logisch. Jij zal waarschijnlijk wachten totdat er flink verlies is en dan hopen dat je de boel kunt redden. Maar als je tijdig reorganiseerd kan je dat voor zijn. Het is gewoon fatsoenlijke bedrijfsvoering.

Als jij de buurman om de zoveel tijd 100,- geeft om het gras te maaien geef jij de buurman dan ook 100,- als het winter is en er niet gemaaid hoeft te worden?