Zo’n tien jaar geleden werd devops een cultureel fenomeen, waarbij developers en operations-professionals samen werden gebracht om silo’s te doorbreken. Maar hoe bijzonder deze verschuiving binnen de it ook was, devops is op het punt gekomen waarop het bespreken ervan achterhaald lijkt. Toch is de ontwikkeling van het oorspronkelijke concept van devops naar de huidige staat eerder een triomf dan een ondergang. Meer, devops heeft geleid tot de opkomst van de platform-engineer, een nieuwe rol toegesneden op het moderne devops-tijdperk.
Devops opereert tegenwoordig onder de paraplu van platform-engineering met een eigen budget, een team en een reeks self-servicetools waarmee developers hun werk rechtstreeks kunnen beheren.
Het platform-engineeringteam biedt significante voordelen, waardoor developers Kubernetes kunnen benutten als een self-servicetool. Hierdoor kunnen talloze gebruikers efficiënter en sneller ontwikkelen, wat de maturity en toepasbaarheid van Kubernetes onderstreept. Binnen drie jaar zullen volgens Gartner vier op de vijf software-engineeringorganisaties beschikken over platformteams die herbruikbare services en tools bieden voor de implementatie van applicaties.
Nieuwe middleware
Platform-engineering is de nieuwe middleware voor softwareontwikkeling. Naarmate het aantal developers en applicaties blijft stijgen, is het traditionele concept van middleware – een altijd beschikbare app-server – vervangen door een platform-engineering self-servicemodel voor developers.
Deze transitie is belangrijk. In de eerdere fasen van devops werd er namelijk overal met verschillende technologieën geëxperimenteerd, maar deze technologieën waren nog niet geconvergeerd. Tegenwoordig werken applicaties echter probleemloos met containers en storage, waarbij networking en security via Kubernetes op een cloud-native manier worden beheerd.
Elastische infrastructuur
Developers zijn niet langer afhankelijk van ticketingsystemen voor het definiëren, structuren en delen van informatie. In plaats daarvan verwachten ze een elastische infrastructuur die ze kunnen gebruiken en uitrollen via een platform dat wordt onderhouden en beheerd door de platform-engineer. De platform-engineer organiseert dat developers het platform zelfstandig kunnen gebruiken en altijd toegankelijk, elastisch, multi-tenant en toch veilig is. Daarnaast waakt de platform-engineer ervoor dat het platform ‘vangrails’ heeft om overbelasting te voorkomen en tevens gebruiksmonitoring en facturatiemethoden biedt. Platform-engineers bouwen zelf echter geen applicaties en zijn niet verantwoordelijk voor de implementatie van de applicatie. Zij zorgen er daarentegen voor dat developers sneller kunnen innoveren, sneller aanpassingen kunnen doorvoeren en sneller applicaties kunnen uitrollen. Nu developers de touwtjes in handen krijgen, nemen de ontwikkeltijd en de implementatietijd drastisch af.
Een succesvol voorbeeld is T-Mobile, waarbij de applicatie ontwikkeltijd is teruggebracht van zes maanden naar slechts uren dankzij Portworx. Grote bedrijven met duizenden developers hebben self-service of on-demandtoegang tot storage en data services nodig, die platform-engineering teams op de gewenste schaalgrootte moeten leveren.
Platform-engineers gaan een stap verder dan traditionele it en vertrouwen op twee belangrijke technologieën: cloud-native en ai-ready data-services. Denk aan moderne databases en dataservices zoals Postgres, Redis, Cassandra, Kafka en Spark, of de meer recente analytics- en ai-tools zoals Snowflake en ChatGPT. Allemaal services die developers via het platform kunnen gebruiken.
Expertise
Platform-engineers bieden essentiële diensten waardoor developers geen uitgebreide Kubernetes-expertise meer hoeven te hebben. Onder deze diensten valt het beheer van verschillende Kubernetes distributies zoals OpenShift, GKE, EKS of Rancher, maar ook het bieden van securitymaatregelen via platforms als Prisma Cloud of Sysdig. Bovendien beheren platform engineers data op Kubernetes, storage-resources, backup, disasterrecovery, databases en data-services die onder Kubernetes vallen. We zien de efficiencywinst uit de eerste hand: een paar platform-engineers kunnen honderden gebruikers ondersteunen.
Als een technologie overal wordt gebruikt, verdwijnt deze vaak langzaam naar de achtergrond. Neem halfgeleiders. Ze zijn overal en zijn essentieel voor de meest uiteenlopende apparatuur, van afstandsbedieningen tot auto’s. Eindgebruikers staan echter zelden stil bij hun bestaan, ze zijn onzichtbaar geworden. Kubernetes ondergaat een soortgelijke transformatie. Bij grote bedrijven raakt Kubernetes diep verankerd in verschillende systemen. Door het self-servicemodel is Kubernetes voor gebruikers van die systemen nauwelijks meer zichtbaar. Vroeger moest elke developer uitgebreide kennis over Kubernetes hebben, nu hoeven ze er alleen nog maar gebruik van te maken en laten ze de ingewikkelde taken over aan de platform-engineers. Platform-engineering zal Kubernetes uiteindelijk onzichtbaar maken.
In detail
Platform-engineering geeft developers een waardevol geschenk, want zij hoeven Kubernetes niet langer in detail te begrijpen als onderdeel van hun dagelijkse verantwoordelijkheden. Hierdoor verdwijnt een hinderlijke skills gap, terwijl Kubernetes blijft groeien en in gebruik is bij de grootste en succesvolste organisaties ter wereld. Platform-engineers en Kubernetes zijn een ideale combinatie voor innovatie en om de concurrentiepositie te verbeteren.
In devops context is er blijkbaar maar 1 platform en das kubernetes, volgens het artikel dan.
Maar goed er is een platform dus en daarop doen dev/ops-ers dingen.
En het platform team begrijpt hun niet en andersom.
Een platform voor OS of containers. Weinig verschil vanuit het platform, want of je nou een container image opspint of een OS image..
Zo ben je weer terug bij af : sysadmins, ontwikkelaars en operators..
Allemaal IT-ers die elkaar niet begrijpen en de business met de mooie praatjes..