Cloud Republic

Iedereen wil snelheid in Azure. Tot niemand meer precies weet wie wat mag uitrollen, welke resources waarvoor worden gebruikt en waarom de testomgeving ineens draait op een production-grade SKU. Veel Azure-landschappen zijn niet zo ontworpen. Ze zijn zo gegroeid. En juist daar begint de uitdaging voor platformteams: hoe krijg je weer grip op een organisch gegroeide omgeving, zonder ontwikkelteams af te remmen? In ons nieuwste blog laat Martin zien hoe je een brownfield Azure landschap stap voor stap weer beheersbaar maakt. Van het ontvlechten van subscriptions en landing zones tot Infrastructure as Code, Azure Policies en Just-In-Time access met PIM. Lees het blog hier: https://lnkd.in/ev9T_Muu

Wanneer is agnostic design echt de moeite waard? In theorie klinkt het aantrekkelijk: business logic loskoppelen van Spring, JBoss of Quarkus, zodat je later makkelijker kunt wisselen. Leon zag daar in de praktijk jarenlang weinig voordeel in. Tot een migratie van JBoss naar Spring Boot nodig werd door de overstap naar OpenShift. Omdat de code sterk aan JBoss gekoppeld was, raakte de migratie ook de business logic. Ondertussen moesten twee branches naast elkaar blijven draaien. Weet je dat er een migratie aankomt? Scheid dan eerst je business logic van je framework-code. Zo kun je oud en nieuw makkelijker naast elkaar laten bestaan en voorkom je dubbel onderhoud. In zijn blog deelt Leon hoe hij dit heeft aangepakt: https://lnkd.in/eHuNsd_Z

AI gaat development niet vervangen. Het gaat bepalen wat een goede developer is. Tijdens refinements zie je het verschil al. Niet tussen senior en junior. Niet tussen backend en frontend. Maar tussen mensen die oplossingen roepen en mensen die de juiste vragen stellen. “Wat bedoelen we precies met klaar?” “Welke randvoorwaarden gelden hier?” “Voor wie is dit expliciet niet bedoeld?” “Wat gebeurt er als deze aanname niet klopt?” Dat soort vragen voorkomt niet alleen bugs. Ze definiëren het systeem. En precies daar verschuift ons vak. Want in een wereld waarin AI steeds meer code kan genereren, wordt implementatie goedkoper. Specificatie wordt de bottleneck. Een agent kan alleen zo goed bouwen als jij scherp definieert wat belangrijk is. Vage refinement betekent vage software, alleen nu op hogere snelheid. De developer van morgen onderscheidt zich niet door meer code te schrijven. Maar door beter te denken. Door aannames zichtbaar te maken. Door constraints expliciet te formuleren. Door complexiteit te structureren voordat er één regel code ontstaat. Dat is geen soft skill. Dat is architectuur in zijn puurste vorm. In een tijd waarin code een commodity wordt, wordt helder denken strategisch kapitaal. De vraag is niet of AI je werk verandert. De vraag is of jij verandert wat jij onder vakmanschap verstaat.

Hoe vaak kun je nieuwe software uitrollen zonder dat de betrouwbaarheid van je operatie eronder lijdt? Industriële omgevingen worden steeds meer afhankelijk van software, API’s en gekoppelde systemen. Een storing in één onderdeel kan daardoor gevolgen hebben voor een veel groter deel van de keten. Bij AkzoNobel bouwde het MIXIT-team daarom een resilience-architectuur die problemen automatisch opvangt op drie niveaus: lokaal, regionaal en globaal. Valt een service uit of bevat een nieuwe release een fout? Dan kan het platform automatisch ingrijpen, verkeer omleiden naar een gezonde regio en verdere belasting van de falende service voorkomen. Het resultaat: sneller kunnen blijven ontwikkelen en releasen, met minder afhankelijkheid van handmatige interventie wanneer er iets misgaat. In dit blog laat Dennis zien hoe hij dit met zijn team heeft opgebouwd en welke keuzes daarachter zitten: https://lnkd.in/evJVmJkQ

De keuze die binnen event-driven architectuur op Azure nogal wat impact kan hebben: Event Grid, Service Bus of Event Hub? Op het eerste gezicht doen ze iets vergelijkbaars: berichten van A naar B krijgen. Toch verschillen ze flink als het gaat om aflevergarantie, schaalbaarheid en de manier waarop je berichten verwerkt. En een verkeerde keuze kan ervoor zorgen dat berichten simpelweg verdwijnen, je setup onnodig complex wordt of je tegen schaalbaarheidsproblemen aanloopt. Martin legt aan de hand van voorbeelden uit waar de verschillen zitten en wanneer je voor welke dienst kiest. Lees het volledige artikel: https://lnkd.in/e2bS8tsS

Ik spreek regelmatig bedrijven die jaren geleden een solide applicatie-architectuur hebben neergezet: toekomstvast, dachten ze toen. Maar na verloop van tijd wordt doorontwikkeling uitdagender, integraties ingewikkelder en innovatie langzamer. Bij AkzoNobel herkenden we dat. Ons ontwikkelteam stelt zichzelf continu de vraag: kunnen we meer uit de applicatie halen met nieuwe technologie? Kunnen we bijvoorbeeld onze kleurdataservice beschikbaar maken voor andere markten, partners en platformen? Die vraag leidde tot een belangrijke doorontwikkeling van MIXIT Cloud, de kleurmatching-applicatie. We zijn al jaren verantwoordelijk voor de evolutie van deze cloudapplicatie en zorgen er met de nieuwste technologieën voor dat ze wendbaar en toekomstbestendig blijft, zodat AkzoNobel haar voorsprong behoudt. Samen met ons team maakten we de stap van een monolithische naar een modulaire architectuur. Dat gaf ruimte voor snellere releases, soepelere integraties en… de mogelijkheid om nieuwe markten te betreden. Benieuwd hoe we dat aanpakten? Lees hier de hele klantcase: https://lnkd.in/ekTBxuYk