Docker Swarm vs Kubernetes

[Furion2000]

Ik heb in een startup project het dilemma dat er word geopteerd voor docker swarm omdat het voor kleinere project lightweight is en minder hoge leercurve heeft. An sich zijn dit goed argumenten.

Zelf ben ik ervaren met Kubernetes en van wat ik lees over Docker Swarm zijn het ongeveer dezelfde concepten die standaard moeten/kunnen worden ingericht en lijkt het inderdaad meer lightweight.

Ik neig ernaar om dus mee te gaan in het voorstel (je mag pas iets *#$( vinden als je het ervaren hebt ), maar graag zou ik toch wel wat stellingen bevestigd hebben of ontkracht.

- Bij docker swarm gebruik je inherent VPS's en krijg je dus ook het onderhoud van de VPS erbij in tegenstelling tot wanneer je een k8s cluster afneemt van een AWS/Azure, dan wordt er toch wel een hoop voor je gedaan.
- Docker swarm lijkt simpeler (ik ben custom k8s platform gewend dus veel zelf doen), maar ik heb het vermoeden dat met AWS/Azure er tegenwoordig zoveel weg geabstraheerd is, dat ook k8s best simpel te configureren is.
- Docker swarm lijkt toch wel niche te zijn in Nederland
- Kosten van docker swarm set aan VPS's lijken hoger te liggen dan dat van een k8s cluster, puur door het aanbod.

Zijn er nog dingen die ik vergeet in de overweging?

[ Voor 3% gewijzigd door Furion2000 op 27-06-2024 16:41 ]

[Woy]

Sowieso lijkt mij het feit dat k8s zo'n beetje industry standard is, en het dus eenvoudiger is om mensen te vinden die er bekend mee zijn ook wel een belangrijk argument.

[SVMartin]

En je noemt Azure/aws, maar je kunt ook bij Herzberg terecht. Flink goedkoper, kun je later altijd nog naar aws/Azure als het nodig is.

[mmvdp]

Als eenvoud echt een reden is ga je niet voor Docker Swarm of K8s, maar kies iets wat echt eenvoudig is als een AWS ECS. Je geeft een container op en done.

[pennywiser]

mmvdp schreef op vrijdag 28 juni 2024 @ 23:14:
Als eenvoud echt een reden is ga je niet voor Docker Swarm of K8s, maar kies iets wat echt eenvoudig is als een AWS ECS. Je geeft een container op en done.

Ik wou net zeggen, dat is een beetje de cloud versie van Swarm. Zonder dat je moet zeggen dat je het obsolete Swarm gebruikt.

Wil je kunnen groeien op meerdere vlakken zoals niet in de laatste plaats aanwezige kennis - die vervolgens de app kan laten groeien - dan zou ik voor zelf k8s gaan. Swarm is wdb verloren tijd denk ik.

Zo te lezen gaat Mirantis - eigenaar van Docker Enterprise - ook de K8s kant op met Swarm: https://www.mirantis.com/software/swarm/ Moet je überhaupt nog tijd in Swarm investeren denk ik dan.

[ Voor 13% gewijzigd door pennywiser op 28-06-2024 23:23 ]

[Merethil]

Je hebt het ook over kosten en onderhoud. Beetje advocaat van de duivel misschien, maar als je bij AWS een EKS-cluster opspint dan ben je alleen aan de control plane al 70 euro per maand kwijt - naargelang je load en verwachte groei kan je voor die 70 euro ook al aardig wat compute hebben.

Als het niet op dat soort bedragen valt (zeer waarschijnlijk zullen jullie voor een dev-omgeving al meer kwijt zijn per maand als je over k8s denkt) dan heb ik nog wel deze ervaring met onderhoud:

- docker swarm: niemand durfde eraan te komen want het draaide nu dus alle servers liepen jaren achter in patches
- kubernetes: "het kost teveel tijd elke keer, doe het maar eens per zoveel maanden/jaar"
- AWS fargate: "welk onderhoud?" - gechargeerd, maar 't is echt bijzonder hoe weinig onderhoud je hoeft te doen voor een werkend en solide platform

Over het algemeen kijk ik als AWS engineer (vooral met het oog op kosten, gemak en onderhoud) als volgt naar projecten:
1. Past de workload in AWS Lambda?
2. Past de workload beter in AWS Fargate?
3. Past de workload beter in K8s?
4. Al het andere, maar liever niet

Het migratiepad van Fargate naar EKS is naar mijn mening ook erg simpel; er zit aardig wat overlap in features en functies. Expres natuurlijk; AWS heeft goed gekeken naar de slimme dingen die K8s doet en daaruit cherry picked wat ze nuttig vonden voor Fargate.
Zelfde idee bestaat natuurlijk ook bij Azure, maar daar heb ik geen verstand van

[ Voor 13% gewijzigd door Merethil op 29-06-2024 08:27 ]

[Woy]

In Azure heb je inderdaad ook gewoon AKS, die het k8s management voor je overneemt, of container apps als je nog minder zelf wil hoeven regelen. Of als je eenvoudigere workloads hebt gewoon een koude container of een app Service.

Als de voornaamste overweging inderdaad eenvoud is, zou ik zeker niet zelf vps en met orchestration software gaan onderhouden. De containers/apps zelf zullen sowieso niet heel veel verschillen, dus je kunt daar op zich ook eenvoudig later nog switchen. Ik zou vooral voor gemak gaan initieel, als de hosting kosten te hoog worden kun je altijd nog gaan optimaliseren

[Ed Vertijsment]

Ik zou ook inzetten op k8s al zou ik daar niet mee beginnen, welke problemen wil je er mee oplossen? En ben je niet bang dat het duurder en mogelijkerwijs trager wordt dan een “simpele” vps (cluster)?

[MueR]

Docker is leuk voor development en voor kleine projectjes die weinig traffic of resources nodig hebben. K8s is leuk voor grotere of complexe projecten, of wanneer je veel traffic denkt te krijgen. Zodra je meer dan de vingers aan een hand nodig hebt om je benodigde VPSen voor je docker swarm te tellen ben je al 3 VPSen te laat met K8s inzetten.

[Ghehe]

Als een derde optie zou je ook kunnen kijken naar Hashicorp Nomad. Dat zit qua complexiteit en features tussen Docker Swarm en Kubernetes. Het is een single binary om te deployen en daarmee is de kous af (in theorie dan toch), dus vrij gemakkelijk om op VPSen te draaien. Het werkt ook goed samen met andere Hashicorp producten zoals Consul en Vault, als je die al in gebruik hebt.

Ik heb Nomad zelf al gebruikt voor enkele proof en concepts en vooral de web UI out of de box is handig om al je deployments te bekijken (je kan vanuit de UI ook shells spawnen in je containers, je stdout/stderr lezen, je jobspec aanpassen, ...)

[eric.1]

Een startup project kan natuurlijk ook erg snel erg hard groeien. Dan is het wel zo makkelijk om al k8 te gebruiken. Het lijkt me vrij vervelend om na een jaar of twee alles weer te moeten migreren omdat het niet meer houdbaar is.

Denk dus ook een stap verder; hoe ziet de groei verwachting eruit en welke impact gaat dat hebben op de gekozen oplossing inclusief mogelijke migratie.

[Oon]

Je doet wel flink wat aannames, maar om er even op te reageren:

Furion2000 schreef op donderdag 27 juni 2024 @ 16:38:
- Bij docker swarm gebruik je inherent VPS's en krijg je dus ook het onderhoud van de VPS erbij in tegenstelling tot wanneer je een k8s cluster afneemt van een AWS/Azure, dan wordt er toch wel een hoop voor je gedaan.

Dit zit niet anders dan Kubernetes, je kunt Docker ook gewoon als hosted cluster opzetten. Alleen omdat K8s standaard als multi-node cluster draait is dat ook de manier waarop het standaard wordt geadverteerd.

- Docker swarm lijkt simpeler (ik ben custom k8s platform gewend dus veel zelf doen), maar ik heb het vermoeden dat met AWS/Azure er tegenwoordig zoveel weg geabstraheerd is, dat ook k8s best simpel te configureren is.

Dan heb je het over niche/proprietary managementlagen, die zijn weer niet goed voor de portabiliteit van je infrastructuur. Ik weet dat Azure gewoon een standaard Kubernetes dashboard biedt, Docker heeft zoiets niet, tenzij je bijv. Portainer gebruikt

- Docker swarm lijkt toch wel niche te zijn in Nederland

Dat is een ongefundeerde aanname, Docker Swarm wordt gewoon wereldwijd gebruikt. Ik ken zelfs grote internationale cloudhosts die Docker Swarm gebruiken voor hun infrastructuur

- Kosten van docker swarm set aan VPS's lijken hoger te liggen dan dat van een k8s cluster, puur door het aanbod.

Eerder andersom, Docker Swarm draait in de basis overal op; alles dat Docker draait kan een Swarm node worden. Als je het als hosted cluster opzet zijn de kosten vergelijkbaar met Kubernetes, maar Swarm draait ook prima als enkele node en de eisen voor de nodes zijn ook wat lager.
Als ik naar kosten ga kijken dan vind ik Kubernetes in verhouding vaak duur.

Zijn er nog dingen die ik vergeet in de overweging?

De belangrijkste is dat Docker Swarm gewoon al een tijdje in de uitfaseerfase zit; Docker zelf heeft er weinig zin meer in en het wordt ook niet echt actief doorontwikkeld.
Aan de andere kant is dat ook niet nodig, want het kan vrijwel alles dat Kubernetes kan. Je leest wel eens dingen over schaalbaarheid e.d., maar ze werken beiden op exact dezelfde principes en het is echt absoluut niet zo dat je geen grote enterprise infrastructuur op Docker Swarm zou kunnen draaien.
Maar mensen vinden die kennis hebben in Docker Swarm wordt steeds lastiger, en mensen vinden met kennis in Kubernetes steeds makkelijker.

Al met al komt het erop ener dat ze beiden hetzelfde doen, hetzelfde kunnen, hetzelfde kosten, en dat het écht maar een kwestie van voorkeur is.

[Furion2000]

Mede dankzij wat gesprekken in mijn eigen netwerk en jullie input ben ik nog eigenlijk wel tot de conclusie gekomen dat het wensen lijstje niet matched aan docker swarm of kubernetes. @Merethil komt met zijn lijstje eigenlijk wel in de buurt van hoe we het zouden moeten aanvliegen. Althans dat is de mening die ik ga meenemen en verder ga onderzoeken.

@Oon zie overigens weinig flinke aannames, je bevestigd vooral dat er in veel gevallen over dezelfde concepten nagedacht moeten worden met wat nuance verschillen. Maar dat is een goed iets!

Realiseerde mij vooral dat er door meerdere mensen (including myself) vooral vanuit de eigen expertise gedacht werd, maar wat het project nodig heeft is een Fargate achtige oplossing lijkt het en Heroku kwam ook om de hoek kijken. Ik denk dat hier verder onderzoek naar wil gaan doen. Eerste vraag heb ik ook al die @Merethil misschien kan beantwoorden? Zit er bij Fargate eens soort makkelijker migratie traject naar k8s wanneer je onverhoopt ineens heel erg gaat scalen?

[remyz]

Als Fargate en Heroku beter lijken te passen, kijk dan ook eens naar fly.io.

[Merethil]

Furion2000 schreef op zondag 30 juni 2024 @ 20:40:
Mede dankzij wat gesprekken in mijn eigen netwerk en jullie input ben ik nog eigenlijk wel tot de conclusie gekomen dat het wensen lijstje niet matched aan docker swarm of kubernetes. @Merethil komt met zijn lijstje eigenlijk wel in de buurt van hoe we het zouden moeten aanvliegen. Althans dat is de mening die ik ga meenemen en verder ga onderzoeken.

@Oon zie overigens weinig flinke aannames, je bevestigd vooral dat er in veel gevallen over dezelfde concepten nagedacht moeten worden met wat nuance verschillen. Maar dat is een goed iets!

Realiseerde mij vooral dat er door meerdere mensen (including myself) vooral vanuit de eigen expertise gedacht werd, maar wat het project nodig heeft is een Fargate achtige oplossing lijkt het en Heroku kwam ook om de hoek kijken. Ik denk dat hier verder onderzoek naar wil gaan doen. Eerste vraag heb ik ook al die @Merethil misschien kan beantwoorden? Zit er bij Fargate eens soort makkelijker migratie traject naar k8s wanneer je onverhoopt ineens heel erg gaat scalen?

Uiteindelijk is Fargate ook aardig oneindig schaalbaar, maar de hele aanpak van een service, load balancer, service discovery, namespaces etc. zit allemaal op soortgelijke manier in Fargate. Dingen heten iets anders, syntax is iets anders maar naar mijn mening aardig vergelijkbaar. Sowieso denk ik dat je niet snel uit de rek van Fargate loopt, en als dat wel dreigt te gebeuren heb je te laat aan de bel getrokken. Het is mijn insziens een perfecte middenweg tussen bijvoorbeeld Lambda en EKS - de snelheid, schaalbaarheid en betrouwbaarheid liggen op niveau k8s zonder het onderhoud.

Ik heb meermaals bedrijven geholpen bij transities, zowel van Swarm naar Fargate of EKS als van on-prem dockerloze hosting naar Fargate of EKS. Beide trajecten met beide eindstations waren prima, maar met Fargate heb ik de ervaring dat alles sneller was opgezet, de stabiliteit top notch was en de prijs relatief goed gedrukt kon worden voor workloads met weinig variërende pods. Als je alle workloads in je landschap naar één platform wilt brengen zou ik wel altijd EKS/k8s aanraden vanwege de flexibiliteit en omdat je dan vaak de prijs prima kan rechtvaardigen.

[ Voor 14% gewijzigd door Merethil op 30-06-2024 23:51 ]

[Ed Vertijsment]

Toch ben ik even benieuwd waarom je gelijk naar containers wil. Even plat gezegd: waarom is een dikke vette monoliet niet goed (genoeg)?

[Merethil]

Ed Vertijsment schreef op dinsdag 2 juli 2024 @ 21:15:
Toch ben ik even benieuwd waarom je gelijk naar containers wil. Even plat gezegd: waarom is een dikke vette monoliet niet goed (genoeg)?

Naast bijvoorbeeld het gemak met development, snel op- en aftuigen van (test)omgevingen, beveiligingsrisico's indammen en "build once, run anywhere" zegt een container verder weinig over je architectuur; een monoliet kan ook prima in een container draaien.

Dat gezegd hebbende: waarom niet? Vanaf moment 0 beginnen met een architectuur die overal op de wereld gebruikt wordt en waar veel mensen voor te vinden zijn (dus: microservices op een orchestration tool) lijkt me nuttiger dan een monoliet bouwen, niet snel genoeg kunnen schalen en dan gehaast alles herbouwen.

Ik heb het gevoel dat, op basis van je vorige en dit bericht, je weinig met containers danwel microservices werkt. Wat op zich geen probleem is maar misschien niet zoveel toevoegt aan de discussie.

[Marcj]

Ed Vertijsment schreef op dinsdag 2 juli 2024 @ 21:15:
Toch ben ik even benieuwd waarom je gelijk naar containers wil. Even plat gezegd: waarom is een dikke vette monoliet niet goed (genoeg)?

Ik zit nu in een bedrijf dat 9 jaar geleden als start-up is begonnen en enorm is gegroeid. Het probleem van starten met een monoliet is dat je er nooit meer goed vanaf komt zonder erg veel tijd erin te steken. Zelfs na 6 jaar geleden besloten te hebben om naar micro-services om te zetten, is de monoliet nog steeds zeker de helft van het systeem.

Aan de andere kant, een monoliet kun je ook prima in k8s of docker draaien, dus dat is geen probleem. Maar de architectuur wordt een beetje een rommeltje in de tijd dat je in die overgang zit. En die overgang kan makkelijk 10 jaar duren...

Mijn tips zouden zijn:

- Start direct met een micro-service architectuur, dat hoeft echt niet ingewikkeld te zijn.

- API first. Als je een front-end maakt, maak deze zonder dynamische pagina, maar met een framework die API's gebruiken. Er zijn er genoeg: React, Vue, Angular.JS, etc...

- Zorg ervoor dat data ook opgedeeld is per micro-service. Je kunt prima eerst 1 database hebben, maar dat tabellen alleen maar gebruikt worden door 1 micro-service. Het lijkt misschien makkelijk om eenvoudig over systemen heen te querien, maar daar heb je laten spijt van. Als je hard groeit zul je zien dat ineens 1 of 2 van de tabellen een bottleneck vormen voor de schaalbaarheid. Dan is het makkelijker als je maar 1 service hoeft aan te passen als je deze data in een andere tabel gaat plaatsen. Zo kun je starten met een normale SQL database (voor het meeste meer dan voldoende), maar kun je laten voor de high-performance zaken kijken naar andere databases (bijvoorbeeld DynamoDB ofzo).

- Zorg direct voor een goede message bus tussen de systemen. Dat maakt het vaak makkelijker schaalbaar en geeft je ook een middel om asynchroon dingen te doen. Een message bus kan ook helpen om pieken in het systeem makkelijker op te vangen.

- Zorg direct voor goede unit en integratie tests. Dit wordt in een start-up vaak vergeten, maar levert snel weer wat op. Bijvoorbeeld bij het updaten van dependencies (wat je vaak moet doen!) heb je er een stuk meer vertrouwen in dat alles nog werkt als je een goede test suite hebt.

Ik zou willen dat ik hiervan veel meer wist toen wij begonnen Maar goed, al doende leert men

In AWS kun je ook voor Lambda's of Fargate gaan. Het is iets simpeler dan k8s, maar heeft wat mij betreft als grootste nadeel dat je dan wel vast zit in AWS. Kubernetes is een technologie die overal beschikbaar is en er zijn echt goedkopere oplossingen dan AWS. Hetzelfde probleem zie ik met Heroku en vergelijkbare oplossingen, je wordt nogal vastgezet door 1 vendor. Zeker iets om te overwegen.

[ Voor 7% gewijzigd door Marcj op 03-07-2024 08:47 ]

[Furion2000]

Wat @Merethil zegt vooral. Sinds ik bekend ben met containers wil ik eigenlijk niet anders meer. Ik heb bij een bedrijf gezeten waar het nogal eens kapot ging en sinds we containers gingen gebruiken waren we klaar met een groot deel van de problemen. Het is voor mij een no-brainer EN voor de mensen waarmee ik in aanraking kom eigenlijk ook wel. Wel/geen container is eigenlijk geen discussie punt meer merk ik.

Monoliet argument komt dan al snel de Agile/DevOps mindset om de hoek kijken. Snelle value stream kunnen bewerkstelligen kan je alleen door snel kleine aanpassingen te kunnen doen en snelle feedback loops. Ik als ontwikkelaar durf dat zonder blikken of blozen in kleine services met goede interfaces en tests, maar in mijn laatste monoliet hadden we freezes van 1 a 2 maanden en een doorlooptijd met bugs van het dubbele daarvan. Daarnaast zijn kleine services sneller in pipelines waardoor die kleinere feedback loop ook weer sneller is. nano services is de vallkuil, maar ook die zijn simpeler op te lossen dan spaghetti code uit elkaar trekken vind ik.

En ja een goede monoliet kan ook prachtig gescheiden zijn met interfaces, maar het word niet verplicht en dan komen die praktijk voorbeelden om de hoek kijken waarbij een dev onder druk van een manager even een shortcut neemt

Afijn je merkt al dat ik fan ben denk ik

Marcj schreef op woensdag 3 juli 2024 @ 08:44:
[...]

- Zorg direct voor goede unit en integratie tests. Dit wordt in een start-up vaak vergeten, maar levert snel weer wat op. Bijvoorbeeld bij het updaten van dependencies (wat je vaak moet doen!) heb je er een stuk meer vertrouwen in dat alles nog werkt als je een goede test suite hebt.

Ik zou willen dat ik hiervan veel meer wist toen wij begonnen Maar goed, al doende leert men

In AWS kun je ook voor Lambda's of Fargate gaan. Het is iets simpeler dan k8s, maar heeft wat mij betreft als grootste nadeel dat je dan wel vast zit in AWS. Kubernetes is een technologie die overal beschikbaar is en er zijn echt goedkopere oplossingen dan AWS. Hetzelfde probleem zie ik met Heroku en vergelijkbare oplossingen, je wordt nogal vastgezet door 1 vendor. Zeker iets om te overwegen.

Dat laatste is het belangrijkste van tests imo, ontwikkelaars die met (meer) vertrouwen aanpassingen doen en testcases toevoegen voor elke fout die er ontstaat.

Voor vendor locking ben ik in principe minder bang bij low-ops oplossingen, want het is low-ops. Je containers verhuizen zou dan ook geen rocket science moeten zijn lijkt mij.

[ Voor 31% gewijzigd door Furion2000 op 03-07-2024 09:00 ]

[Ed Vertijsment]

Merethil schreef op dinsdag 2 juli 2024 @ 21:59:
[...]


Naast bijvoorbeeld het gemak met development, snel op- en aftuigen van (test)omgevingen, beveiligingsrisico's indammen en "build once, run anywhere" zegt een container verder weinig over je architectuur; een monoliet kan ook prima in een container draaien.

Dit maakt op zich sense, bepaalde klanten van ons gebruiken ook k8s voor standaardisatie van deployment. Overigens is snel en standaard deployen ook mogelijk met traditionele tools (Ansible, Chef, Puppet) etc. maar het is zeker een manier om je deployment geautomatiseerd te hebben.

Merethil schreef op dinsdag 2 juli 2024 @ 21:59:
[...]
Dat gezegd hebbende: waarom niet? Vanaf moment 0 beginnen met een architectuur die overal op de wereld gebruikt wordt en waar veel mensen voor te vinden zijn (dus: microservices op een orchestration tool) lijkt me nuttiger dan een monoliet bouwen, niet snel genoeg kunnen schalen en dan gehaast alles herbouwen.

Deze ga ik even opsplitsen:

en architectuur die overal op de wereld gebruikt wordt

Monolieten worden ook overal op de wereld gebruikt, het zal je verbazen

waar veel mensen voor te vinden

Het is makkelijker om mensen te vinden die een app kunnen bouwen dan mensen die een app kunnen bouwen EN k8s kunnen beheren. Zelfs al zal het makkelijk zijn om hier mensen voor te vinden (momenteel is het een probleem om uberhaubt mensen te vinden) verhoog je de drempel dus.

niet snel genoeg kunnen schalen en dan gehaast alles herbouwen.

Ik kom dit "fabeltje" wel vaker tegen dat monolieten niet kunnen schalen. In veel gevallen zelfs beter dan micrsoservices afhankelijk van de applicatie en het type gebruik. Veel applicaties zijn simpelweg niet Netflix heb hebben ook niet de bijbehorende architectuur nodig, de meeste fatsoenlijke geschreven applicaties kunnen een land bedienen op een enkele (dikke) server, opschalen kan daarna prima door er een tweede bij te zetten, wat qua kosten plaatje in mijn ervaring nog steeds flink goedkoper is dan een dure cloud (ook al is autoscaling goed ingeregeld).

Merethil schreef op dinsdag 2 juli 2024 @ 21:59:
[...]
waarom niet

Bold statement: Omdat microservices in essentie een monoliet zijn met meer netwerk traffic.

Een goed opgezette monoliet die intern "apps/features/module/etc." opsplitst is net zo goed te overzien of aan te werken dan een stel microservices, minus de onderlinge afhankelijkheden op API versies etc. microservices kunnen een strategie zijn om naar toe te migreren op het moment dat later daar behoefte aan is, bijvoorbeeld omdat er een dedicated team ontstaat voor module X. Het goed opsplitsen van modules vanaf de start is de takeaway, of dat gebeurt middels een andere "app/feature/module/etc." of een microservice is een implementation detail.

Verder gaat voor gemiddeld gebruik die monoliet waarschijnlijk beter performen. De workload voor dezelfde app met enkel een andere architectuur is hetzelfde, echter kan de monoliet af met minder I/O en heeft de enkele server(s) waar alles op draait meer headroom (houd er rekening mee dat in veel gevallen containers met restricted specs draaien om meer containers per server te kunnen draaien). De schaalbaarheid van microservices is voor de verreweg de meeste applicaties niet nodig en vanuit performance gezien dus een investering die zichzelf niet terugverdient.

Merethil schreef op dinsdag 2 juli 2024 @ 21:59:
[...]
Ik heb het gevoel dat, op basis van je vorige en dit bericht, je weinig met containers danwel microservices werkt. Wat op zich geen probleem is maar misschien niet zoveel toevoegt aan de discussie.

https://yourlogicalfallacyis.com/no-true-scotsman

Ik werk met zowel microservices als monoliet projecten, allebei hebben ze een time and place. Bepaalde projecten zijn vanaf het begin opgezet als microservices (eigenlijk nooit met een technische reden) en bepaalde projecten worden neergezet als monoliet, al dan niet in een container gezet voor deployment.

Ik heb gewerkt aan het opsplitsen van codebases en het samenvoegen tot een monoliet, in een bepaald geval (applicatie met een naam die de meeste hier wel kennen) ging de architectuur (overgenomen) van.

• Microservices
• Traag
• Veel outages
• Duur

naar

• Monoliet
• Snel
• Betrouwbaar
• Goedkoop

Best een groot en duur project om aan te pakken, scheelt: de besparing was zo groot dat, dat binnen een maand was terug verdient.

Microservices worden te vaak neergezet als oplossing op zoek naar een probleem; het vanaf het begin introduceren van nodeloos veel I/O vertraag applicaties en leid af van je daadwerkelijk wilt doen: het goed indelen van code, wat prima in een monoliet kan.

[Ed Vertijsment]

Marcj schreef op woensdag 3 juli 2024 @ 08:44:
[...]

Ik zit nu in een bedrijf dat 9 jaar geleden als start-up is begonnen en enorm is gegroeid. Het probleem van starten met een monoliet is dat je er nooit meer goed vanaf komt zonder erg veel tijd erin te steken.

Mijn vermoeden is dat, dat meer zegt over architectuur dan over het concept monoliet. als je spul vanaf het begin goed opsplitst is het prima te migreren. Als je vanaf het begin een architectuur niet goed neerzet is het lastig om het achteraf goed te krijgen, het maakt dan niet uit of het een monoliet is of microservices zijn.

Marcj schreef op woensdag 3 juli 2024 @ 08:44:
[...]
Zelfs na 6 jaar geleden besloten te hebben om naar micro-services om te zetten, is de monoliet nog steeds zeker de helft van het systeem.

Is dat erg, de delen die meer te winnen hebben van services zijn kennelijk wel gemigreerd, de rest draait misschien prima?

Marcj schreef op woensdag 3 juli 2024 @ 08:44:
[...]
Aan de andere kant, een monoliet kun je ook prima in k8s of docker draaien, dus dat is geen probleem. Maar de architectuur wordt een beetje een rommeltje in de tijd dat je in die overgang zit. En die overgang kan makkelijk 10 jaar duren...

Elke architectuur kan een rommeltje worden, het goed indelen van code is de uitdaging maar of dat in services of onderdelen van een monoliet gebeurt maak niet heel veel uit.

- Start direct met een micro-service architectuur, dat hoeft echt niet ingewikkeld te zijn.

- API first. Als je een front-end maakt, maak deze zonder dynamische pagina, maar met een framework die API's gebruiken. Er zijn er genoeg: React, Vue, Angular.JS, etc...

- Zorg ervoor dat data ook opgedeeld is per micro-service. Je kunt prima eerst 1 database hebben, maar dat tabellen alleen maar gebruikt worden door 1 micro-service. Het lijkt misschien makkelijk om eenvoudig over systemen heen te querien, maar daar heb je laten spijt van. Als je hard groeit zul je zien dat ineens 1 of 2 van de tabellen een bottleneck vormen voor de schaalbaarheid. Dan is het makkelijker als je maar 1 service hoeft aan te passen als je deze data in een andere tabel gaat plaatsen. Zo kun je starten met een normale SQL database (voor het meeste meer dan voldoende), maar kun je laten voor de high-performance zaken kijken naar andere databases (bijvoorbeeld DynamoDB ofzo).

- Zorg direct voor een goede message bus tussen de systemen. Dat maakt het vaak makkelijker schaalbaar en geeft je ook een middel om asynchroon dingen te doen. Een message bus kan ook helpen om pieken in het systeem makkelijker op te vangen.

- Zorg direct voor goede unit en integratie tests. Dit wordt in een start-up vaak vergeten, maar levert snel weer wat op. Bijvoorbeeld bij het updaten van dependencies (wat je vaak moet doen!) heb je er een stuk meer vertrouwen in dat alles nog werkt als je een goede test suite hebt.

In de basis prima advies, alleen zou ik niet starten met microservices maar wel dingen goed opsplitsen zodat je later makkelijker kan refactoren (mogelijk naar microservices).

[famschopman]

Sluit me aan bij bovenstaande.

Waar men vaak de afslag mist is de drang om alle functionaliteit op te delen naar micro-services; ergens hebben ze gehoord dat een monoliet per definitie niet goed is.

Je moet zelf beoordelen of er tussen functionaliteit bepaalde afhankelijkheden spelen, inwisselbaar zijn voor andere implementaties (en dan moet je je nóg afvragen of de introductie van complexiteit door abstraheren wel opweegt tegen de mogelijke voordelen) en of je specifieke onderdelen sterker wil schalen; in die situaties kan het juist wel interessant zijn.

[Merethil]

Ed Vertijsment schreef op woensdag 3 juli 2024 @ 09:37:

Het is makkelijker om mensen te vinden die een app kunnen bouwen dan mensen die een app kunnen bouwen EN k8s kunnen beheren. Zelfs al zal het makkelijk zijn om hier mensen voor te vinden (momenteel is het een probleem om uberhaubt mensen te vinden) verhoog je de drempel dus.

Ik ben dan ook van mening dat de mensen die de app bouwen niet óók k8s moeten beheren. Het idee is dat je Kubernetes inzet als je deploymentplatform en de developers voorziet van (makkelijke) automatisaties om hun code daar te laten draaien, liefst door een gestandaardiseerde deploymentstructuur op te zetten waar zij alleen een buildspec, hun code en de dependencies oid. hoeven aan te leveren.

Ik kom dit "fabeltje" wel vaker tegen dat monolieten niet kunnen schalen. In veel gevallen zelfs beter dan micrsoservices afhankelijk van de applicatie en het type gebruik. Veel applicaties zijn simpelweg niet Netflix heb hebben ook niet de bijbehorende architectuur nodig, de meeste fatsoenlijke geschreven applicaties kunnen een land bedienen op een enkele (dikke) server, opschalen kan daarna prima door er een tweede bij te zetten, wat qua kosten plaatje in mijn ervaring nog steeds flink goedkoper is dan een dure cloud (ook al is autoscaling goed ingeregeld).

Dat monolieten niet zouden kunnen schalen heb ik niet gezegd, maar de schaalbaarheid van kleine, op zichzelf staande componenten, waar men van tevoren rekening houdt dat deze schaalbaar moeten zijn (en dus communicatie tussen onderdelen, dependencies etc. extern houden, bijvoorbeeld door queues/service discovery etc.) is een stuk beter in te richten en te garanderen, alsook dat dit zeker in een orchestrationplatform als Kubernetes gewoon automatisch voor je gebeurt zonder zelf na te denken over welke servers/services waar komen te draaien.

Bold statement: Omdat microservices in essentie een monoliet zijn met meer netwerk traffic.

Een goed opgezette monoliet die intern "apps/features/module/etc." opsplitst is net zo goed te overzien of aan te werken dan een stel microservices, minus de onderlinge afhankelijkheden op API versies etc. microservices kunnen een strategie zijn om naar toe te migreren op het moment dat later daar behoefte aan is, bijvoorbeeld omdat er een dedicated team ontstaat voor module X. Het goed opsplitsen van modules vanaf de start is de takeaway, of dat gebeurt middels een andere "app/feature/module/etc." of een microservice is een implementation detail.

Verder gaat voor gemiddeld gebruik die monoliet waarschijnlijk beter performen. De workload voor dezelfde app met enkel een andere architectuur is hetzelfde, echter kan de monoliet af met minder I/O en heeft de enkele server(s) waar alles op draait meer headroom (houd er rekening mee dat in veel gevallen containers met restricted specs draaien om meer containers per server te kunnen draaien). De schaalbaarheid van microservices is voor de verreweg de meeste applicaties niet nodig en vanuit performance gezien dus een investering die zichzelf niet terugverdient.

Alhoewel ik het met bovenstaande niet oneens ben, heb ik de ervaring dat veel monolieten totaal niet schalen omdat er bij de opzet niet over nagedacht is. En zelfs als dat zo is, dan is de schaalbaarheid beperkt tot de hoeveelheid servers die je neer kan zetten. Juist een orchestration tool als Kubernetes (of Openshift, of Fargate, of ...) heeft als voordeel dat je services server-onafhankelijk worden, ze los van elkaar kunnen schalen op basis van load (zodat je niet 90% van je codebase meeschaalt zonder dat die er nut van hebben) en dat het platform ook regelt wat er gebeurt met je services als er eens een server down is vanwege issues of maintenance.

De monolieten die ik in de eerste tien jaar van m'n carrière heb mogen onderhouden waren allemaal beperkt schaalbaar, nauwelijks high-available te krijgen en we moesten altijd bepaalde onderhoudswindows afspreken met onze klanten. In bijna alle gevallen duurde 't best lang om een nieuwe server op te tuigen en de monoliet daar aan het werk te krijgen in vergelijking met wat Kubernetes voor ons doet als we eens één server onderuit trekken. Zelfs al hadden we alles gescript; een nieuwe server opstarten, de applicatie uitrollen (of een server starten op basis van een bepaalde AMI waar de applicatie al op stond) was altijd trager dan Kubernetes die m'n workload gewoon verplaatst naar een andere, al draaiende server waar nog genoeg ruimte was.

https://yourlogicalfallacyis.com/no-true-scotsman

Ik werk met zowel microservices als monoliet projecten, allebei hebben ze een time and place. Bepaalde projecten zijn vanaf het begin opgezet als microservices (eigenlijk nooit met een technische reden) en bepaalde projecten worden neergezet als monoliet, al dan niet in een container gezet voor deployment.

Ik heb gewerkt aan het opsplitsen van codebases en het samenvoegen tot een monoliet, in een bepaald geval (applicatie met een naam die de meeste hier wel kennen) ging de architectuur (overgenomen) van.

• Microservices
• Traag
• Veel outages
• Duur

naar

• Monoliet
• Snel
• Betrouwbaar
• Goedkoop

Best een groot en duur project om aan te pakken, scheelt: de besparing was zo groot dat, dat binnen een maand was terug verdient.

Microservices worden te vaak neergezet als oplossing op zoek naar een probleem; het vanaf het begin introduceren van nodeloos veel I/O vertraag applicaties en leid af van je daadwerkelijk wilt doen: het goed indelen van code, wat prima in een monoliet kan.

Ik zie dat wat ik heb geschreven voldoet aan de fallacy, en het was juist niet mijn bedoeling om je af te schrijven als "iemand die niet weet waar hij het over heeft". Excuus hiervoor, in mijn haast was ik erg kortaf in m'n schrijfwijze.

Wat ik bedoelde te zeggen (ook met het oog op het verhaal dat ik hierboven schreef): Alhoewel ik snap dat een monoliet kan voldoen, komt de TS hier met de vraag "welke infra kan ik het best gebruiken voor m'n microservices als ik eis X, Y en Z heb?". Dan is het antwoord "Heb je al eens aan een monoliet gedacht?" zonder verdere onderbouwing (tot vanochtend dus) naar mijn mening niet het meest nuttige antwoord

[Ed Vertijsment]

Merethil schreef op woensdag 3 juli 2024 @ 13:09:
[...]

Ik ben dan ook van mening dat de mensen die de app bouwen niet óók k8s moeten beheren. Het idee is dat je Kubernetes inzet als je deploymentplatform en de developers voorziet van (makkelijke) automatisaties om hun code daar te laten draaien, liefst door een gestandaardiseerde deploymentstructuur op te zetten waar zij alleen een buildspec, hun code en de dependencies oid. hoeven aan te leveren.

En wie gaat die automatisering bouwen en beheren? K8s beheren is een stuk complexer dan eenvoudig Ansible aftrappen op een host, beide doen wat dit betreft hetzelfde: een workload neerzetten op een server. Het punt hier was dat de totale werknemerskosten van K8s hoger liggen door dit soort aanvullende complexiteit.

Merethil schreef op woensdag 3 juli 2024 @ 13:09:
[...]

Dat monolieten niet zouden kunnen schalen heb ik niet gezegd, maar de schaalbaarheid van kleine, op zichzelf staande componenten, waar men van tevoren rekening houdt dat deze schaalbaar moeten zijn (en dus communicatie tussen onderdelen, dependencies etc. extern houden, bijvoorbeeld door queues/service discovery etc.) is een stuk beter in te richten en te garanderen, alsook dat dit zeker in een orchestrationplatform als Kubernetes gewoon automatisch voor je gebeurt zonder zelf na te denken over welke servers/services waar komen te draaien.

queues/service discovery etc.

Complexiteit (over netwerk) wat een monoliet niet nodig heeft.

is een stuk beter in te richten en te garanderen

Hoe dan? Wat is er mis met een simpele load balancer?

Kubernetes gewoon automatisch voor je gebeurt zonder zelf na te denken over welke servers/services waar komen te draaien.

Welk voordeel geeft dit? Niet dat ik nu constant wakker lig over waar "de server" staat, die staat er gewoon, en doet het. Wat is het voordeel van de plaatsing abstraheren? Niet weten is overigens niet een voordeel.

Merethil schreef op woensdag 3 juli 2024 @ 13:09:
[...]

Alhoewel ik het met bovenstaande niet oneens ben, heb ik de ervaring dat veel monolieten totaal niet schalen omdat er bij de opzet niet over nagedacht is. En zelfs als dat zo is, dan is de schaalbaarheid beperkt tot de hoeveelheid servers die je neer kan zetten.

Met microservice is dit net zo, er is geen enkele garantie dat die kleine service prima schaalt, en als dat zo wel kan, kan dat doorgaans ook als de het een module in een groter systeem is, en zoals ik al eerder heb aangeven, vaak makkelijker want minder netwerk (en je hebt niet per se die queues/service discovery etc. nodig).

De factor is vaak code: hoe goed kan die omgaan met meerde instances. Of dat stukje code in een mapje samen met andere code zit of los in zijn eigen mapje in een monorepo of repository is een implementation detail en bepaald niet hoe de code schaalt.

Merethil schreef op woensdag 3 juli 2024 @ 13:09:
[...]
Juist een orchestration tool als Kubernetes (of Openshift, of Fargate, of ...) heeft als voordeel dat je services server-onafhankelijk worden, ze los van elkaar kunnen schalen op basis van load (zodat je niet 90% van je codebase meeschaalt zonder dat die er nut van hebben)

Nu krijg je dus dat je doelgerichter kan schalen, op zich prima, maar welk voordeel wil je hier mee behalen? Minder kosten zul je er doorgaans niet mee krijgen aangezien die "domme" vps/server heel goedkoop is en cloud platforms doorgaans totaal niet (ook al willen ze je dat graag doen geloven). Verder: dat module B profiteert van server upgrade voor module A is niet per se slecht. Als je niet Netflix bent is veel kleine nodes vaak niet sneller dan 1 grote. Die 1 grote is vaak wel goedkoper dan die vele kleine.

Merethil schreef op woensdag 3 juli 2024 @ 13:09:
[...]

en dat het platform ook regelt wat er gebeurt met je services als er eens een server down is vanwege issues of maintenance.

Dit is vaak wel een voordel, health checks worden vaak goed uitgevoerd omdat het platform je dwingt dit correct te doen. Niet dat het met anders niet kan maar mijn ervaring is wel dat het dan snel wordt vergeten.

Merethil schreef op woensdag 3 juli 2024 @ 13:09:
[...]

De monolieten die ik in de eerste tien jaar van m'n carrière heb mogen onderhouden waren allemaal beperkt schaalbaar, nauwelijks high-available te krijgen en we moesten altijd bepaalde onderhoudswindows afspreken met onze klanten. In bijna alle gevallen duurde 't best lang om een nieuwe server op te tuigen en de monoliet daar aan het werk te krijgen in vergelijking met wat Kubernetes voor ons doet als we eens één server onderuit trekken. Zelfs al hadden we alles gescript; een nieuwe server opstarten, de applicatie uitrollen (of een server starten op basis van een bepaalde AMI waar de applicatie al op stond) was altijd trager dan Kubernetes die m'n workload gewoon verplaatst naar een andere, al draaiende server waar nog genoeg ruimte was.

Die doet mij toch vermoeden dat de deployment scripts niet ideaal waren, maar true: eenmaal goed maintained kan je met K8s redelijk makkelijk manoeuvreren. Ik vraag mij wel af of een kleiner maintenance window die moeite/kosten en complexiteit waard is. My 2 cents: nee.

Merethil schreef op woensdag 3 juli 2024 @ 13:09:
[...]

Ik zie dat wat ik heb geschreven voldoet aan de fallacy, en het was juist niet mijn bedoeling om je af te schrijven als "iemand die niet weet waar hij het over heeft". Excuus hiervoor, in mijn haast was ik erg kortaf in m'n schrijfwijze.

No offense taken, ik wou je er wel inbrengen dat het een drogreden was, ook al had ik nooit met services gewerkt dan nog kunnen standpunten bijdragen aan een discussie

Merethil schreef op woensdag 3 juli 2024 @ 13:09:
[...]

Wat ik bedoelde te zeggen (ook met het oog op het verhaal dat ik hierboven schreef): Alhoewel ik snap dat een monoliet kan voldoen, komt de TS hier met de vraag "welke infra kan ik het best gebruiken voor m'n microservices als ik eis X, Y en Z heb?". Dan is het antwoord "Heb je al eens aan een monoliet gedacht?" zonder verdere onderbouwing (tot vanochtend dus) naar mijn mening niet het meest nuttige antwoord

De vraag K8s of docker had ik dan ook beantwoord met (K8s), maar ik was wel benieuwd naar de motivatie om überhaupt daar mee te beginnen, beetje een X/Y probleem.

[edeboeck]

offtopic:
Fijn om nog eens een discussie te lezen die behoorlijk stevig op de bal gaat, maar respectvol voor de spelers is... Kudo's @Merethil en @Ed Vertijsment

[ Voor 3% gewijzigd door edeboeck op 03-07-2024 14:30 ]

[DexterDee]

Very very late to the game in deze discussie, maar als ik een paar dockers zou willen hosten met minimale complexiteit dan zou ik zelf kiezen voor een serverless oplossing.

Pak bijvoorbeeld Cloud Run van Google Cloud. Ze hebben een royale free tier, voor kleine projectjes vaak al (bijna) genoeg om gratis te kunnen hosten. Je pusht je docker in een artifact repository, tagt een versie en deze wordt automatisch gedeployed naar een Cloud Run instantie. Het in de lucht houden, schalen en bereikbaar maken van je docker op een HTTPS endpoint wordt volledig automatisch voor je geregeld. Een beetje slimme developer met docker ervaring heeft letterlijk 0 voorkennis nodig om dit aan de praat te krijgen.

Begrijp me niet verkeerd, ik heb zelf veel expertise in K8S en draai een aantal managed clusters, uitgerold met Terraform, gespecialiseerde nodes, (anti)affinity rules, horizontal pod autoscaling en deployments met Helm en ArgoCD. Prachtig spul, maar heeft wel een redelijke learning-curve en vereist wat DevOps ervaring.

[Furion2000]

@DexterDee denk dat dit dan vergelijkbaar is met Fargate van AWS en Heroku? Zo klinkt het wel, maar ik zet hem op het lijstje. Dankjewel!

Tussentijd ook geen onderzoek meer gedaan verder.

@Ed Vertijsment is het ook niet een beetje Conway's law van wat goed werkt bij projecten? Is je afdeling groot met een dedicated Ops team dan kun je als team je eigen life cylce management doen en de 10x deployments per dag doen op een k8s cluster. Daarnaast is het budget er dan ook vaak om dat goed te doen.

Startup met een klein dedicated full-stack team die vooral functionaliteit eruit moet knallen is misschien meer gebaat bij een simpele opzet en dus misschien wel monoliet. Al vind ik het in deze erg werknemer en bedrijfsvoering afhankelijk of deze monoliet het goed gaat overleven.

Voor mij is het niet zozeer de technische beste oplossing die leidend is, het is vooral de werkbaarheid daarin. Als in een half jaar een prutser zijn gang laten gaan in 1 microservice is minder erg dan diezelfde prutser los laten gaan op een monoliet.

Ik ben overigens wel gevoelig voor je argumenten over kosten/tijdwinst maar ik zit wel gelijk met slimme pipelines en een custom linters in mijn hoofd die pogingen tot shortcuts af zouden vangen.

[Ed Vertijsment]

Furion2000 schreef op woensdag 3 juli 2024 @ 15:36:

@Ed Vertijsment is het ook niet een beetje Conway's law van wat goed werkt bij projecten? Is je afdeling groot met een dedicated Ops team dan kun je als team je eigen life cylce management doen en de 10x deployments per dag doen op een k8s cluster. Daarnaast is het budget er dan ook vaak om dat goed te doen.

Startup met een klein dedicated full-stack team die vooral functionaliteit eruit moet knallen is misschien meer gebaat bij een simpele opzet en dus misschien wel monoliet. Al vind ik het in deze erg werknemer en bedrijfsvoering afhankelijk of deze monoliet het goed gaat overleven.

Ik denk dat dit een veel gezondere afweging is dan een technische afweging, hoe ga je met development teams om, bij verschillende teams die aan verschillende "services" werkt is een microservice een passende oplossing, puur uit organisatorisch standpunt.

Furion2000 schreef op woensdag 3 juli 2024 @ 15:36:

Voor mij is het niet zozeer de technische beste oplossing die leidend is, het is vooral de werkbaarheid daarin. Als in een half jaar een prutser zijn gang laten gaan in 1 microservice is minder erg dan diezelfde prutser los laten gaan op een monoliet.

Zo had ik er nog niet naar gekeken . In essentie heb je daar een punt (al kan je natuurlijk ook iemand laten werken aan 1 "module" binnen een monoliet).

Furion2000 schreef op woensdag 3 juli 2024 @ 15:36:
Ik ben overigens wel gevoelig voor je argumenten over kosten/tijdwinst maar ik zit wel gelijk met slimme pipelines en een custom linters in mijn hoofd die pogingen tot shortcuts af zouden vangen.

Ik weet even niet welke shortcuts je bedoelt

[Merethil]

Ed Vertijsment schreef op woensdag 3 juli 2024 @ 13:44:
[...]


En wie gaat die automatisering bouwen en beheren? K8s beheren is een stuk complexer dan eenvoudig Ansible aftrappen op een host, beide doen wat dit betreft hetzelfde: een workload neerzetten op een server. Het punt hier was dat de totale werknemerskosten van K8s hoger liggen door dit soort aanvullende complexiteit.

Nou ja, de afgelopen vijf jaar heb ik meerdere EKS-clusters beheerd en door de abstractielaag van AWS heb je relatief weinig van doen met de infra, meer met het opzetten en onderhouden van de logica (capacity planning, scaling, networking etc) op het cluster. Dat heb ik voor meerdere (middel)grote bedrijven gedaan waar ik deel uitmaakte van een team van 2, waar we vaker dan niet bezig waren met meehelpen met development omdat je niet 100% van de tijd bezig bent met het cluster en alles eromheen.

Dus uit een klein team 1 a 2 mensen op ops en 1 a 2 op dev werkt al heel goed.

Complexiteit (over netwerk) wat een monoliet niet nodig heeft.

Zeker, maar daar staat tegenover dat je monoliet een stuk minder makkelijk opdelen in daadwerkelijk fysiek gescheiden, herbruikbare publieke, private en geïsoleerde delen is - dat is zeker bij een landschap waar je veel externe en interne gebruikers (en andere applicaties) hebt die willen werken met wat jij aanbiedt, eventueel verdeeld over verschillende landen of zelfs continenten.

Hoe dan? Wat is er mis met een simpele load balancer?

Niets, maar interne communicatie tussen services en eventueel containers tussen services, binnen namespaces en tussen containers in dezelfde pod is out of the box geregeld zonder externe zaken als een load balancer.

Welk voordeel geeft dit? Niet dat ik nu constant wakker lig over waar "de server" staat, die staat er gewoon, en doet het. Wat is het voordeel van de plaatsing abstraheren? Niet weten is overigens niet een voordeel.

De plaatsing is geautomatiseerd, niet geabstraheerd. Je kan prima zien waar je pods staan, je servers staan etc. Maar nu regelt een k8s het voor mij dat er bijvoorbeeld pods in alle availability zones of zelfs verschillende regio's staan zodat hardware outages nooit (veel) impact hebben - k8s regelt dat m'n workload automatisch verplaatst en dat is heel fijn als er 's nachts opeens een network, internet of power outage bij mij provider is.

Met microservice is dit net zo, er is geen enkele garantie dat die kleine service prima schaalt, en als dat zo wel kan, kan dat doorgaans ook als de het een module in een groter systeem is, en zoals ik al eerder heb aangeven, vaak makkelijker want minder netwerk (en je hebt niet per se die queues/service discovery etc. nodig).

De factor is vaak code: hoe goed kan die omgaan met meerde instances. Of dat stukje code in een mapje samen met andere code zit of los in zijn eigen mapje in een monorepo of repository is een implementation detail en bepaald niet hoe de code schaalt.

Eens, behalve dat je bij microservices gedwongen wordt hierover na te denken en het toe te passen omdat andere zaken altijd extern van je eigen microservices zijn. Dus je kan de shortcuts van bijvoorbeeld "even een private method aanroepen" gewoon niet uitvoeren tussen microservices. Je interface wordt een stuk strakker afgedwongen.

Nu krijg je dus dat je doelgerichter kan schalen, op zich prima, maar welk voordeel wil je hier mee behalen? Minder kosten zul je er doorgaans niet mee krijgen aangezien die "domme" vps/server heel goedkoop is en cloud platforms doorgaans totaal niet (ook al willen ze je dat graag doen geloven). Verder: dat module B profiteert van server upgrade voor module A is niet per se slecht. Als je niet Netflix bent is veel kleine nodes vaak niet sneller dan 1 grote. Die 1 grote is vaak wel goedkoper dan die vele kleine.

Gerichter schalen is zeer fijn als één service veel gebruikt wordt en de rest niet. Als iemand jouw login hamert blijft de rest gewoon rustig doorgaan terwijl de loginservice opschaalt. Zelfde voor het verwerken van asynchrone processen; cronjobs draaien volledig separaat en trekken niet zomaar je server omver, processen die op queues luisteren kunnen opschalen zonder dat omliggende code die niets doet ook mee moet schalen etc. Ik zie daar genoeg voordeel in imo.

Die doet mij toch vermoeden dat de deployment scripts niet ideaal waren, maar true: eenmaal goed maintained kan je met K8s redelijk makkelijk manoeuvreren. Ik vraag mij wel af of een kleiner maintenance window die moeite/kosten en complexiteit waard is. My 2 cents: nee.

Zoals genoemd; met 2 mensen konden we prima middelgrote bedrijven bedienen wat betreft k8s en het gros van het onderhoud was gewoon uit handen genomen. Zelf niet een proces hoeven aftrappen om naar een andere regio te gaan als m'n regio even outage heeft, of zelf niet hoeven nadenken over het opzetten van servers voor verschillende instanties van je service vind ik zelf erg fijn en scheelt mij letterlijk dagelijks tijd.

De vraag K8s of docker had ik dan ook beantwoord met (K8s), maar ik was wel benieuwd naar de motivatie om überhaupt daar mee te beginnen, beetje een X/Y probleem.

En ik zeg Fargate ipv k8s want goedkoper, makkelijker en nog minder onderhoud
Ik denk dat het erg in "the eye of the beholder" zit, en dat iedereen door verschillende ervaringen ook zeker verschillende wensen en verwachtingen heeft.

[Ed Vertijsment]

Merethil schreef op woensdag 3 juli 2024 @ 18:05:
[...]

Nou ja, de afgelopen vijf jaar heb ik meerdere EKS-clusters beheerd en door de abstractielaag van AWS heb je relatief weinig van doen met de infra, meer met het opzetten en onderhouden van de logica (capacity planning, scaling, networking etc) op het cluster. Dat heb ik voor meerdere (middel)grote bedrijven gedaan waar ik deel uitmaakte van een team van 2, waar we vaker dan niet bezig waren met meehelpen met development omdat je niet 100% van de tijd bezig bent met het cluster en alles eromheen.

Dus uit een klein team 1 a 2 mensen op ops en 1 a 2 op dev werkt al heel goed.

Nu heb ik geen enkele twijfel over jouw skills om K8s in te richten maar mijn punt was dat je dus wel die extra handjes nodig hebt voor het onderhouden van de logic (capacity planning, scaling, networking etc). Extra kosten en complexiteit dus.

Merethil schreef op woensdag 3 juli 2024 @ 18:05:
[...]


Zeker, maar daar staat tegenover dat je monoliet een stuk minder makkelijk opdelen in daadwerkelijk fysiek gescheiden, herbruikbare publieke, private en geïsoleerde delen is - dat is zeker bij een landschap waar je veel externe en interne gebruikers (en andere applicaties) hebt die willen werken met wat jij aanbiedt, eventueel verdeeld over verschillende landen of zelfs continenten.

Of je dat een moeilijk kan opdelen is nog maar de vraag, dat hangt van de applicatie af. Een punt wat ik eerder maakte is dat het veel handig is om rekening te houden met het kunnen opsplitsen in plaats van het op voorhand alles opsplitsen.

Niet elke app is Netflix (de meeste niet), en het punt dat ik maakte dat het doorgans niet een goed idee is om op voorhand altijd te beginnen met microservices omdat het geld, capaciteit en performance kost voor de meest meeste use cases, Als startup heb je vaak nog niets aan zo veel gedistribueerde logica.

Ik stelde de vraag waarom een monoliet niet volstond (dat kan prima zo zijn) en waarom er microservices gebruikt moesten worden. Je gaf aan "waarom" niet en daarmee impliceer je dat dus geen noemenswaardige nadelen zijn, waar ik niet in mee ga. Hogere kosten, meer complexiteit en een grote vaag naar personeel om het te beheren lijken mij groot genoeg risico's om in ieder geval bij stil te staan. Zonder motivatie waarom microservices een goed idee zijn is het bijna altijd een slecht idee.

Merethil schreef op woensdag 3 juli 2024 @ 18:05:
[...]


Niets, maar interne communicatie tussen services en eventueel containers tussen services, binnen namespaces en tussen containers in dezelfde pod is out of the box geregeld zonder externe zaken als een load balancer.

Klopt, de load balancer doet namelijk niet communicatie tussen services omdat dat niet nodig is met een monoliet, nog minder complexiteit

Merethil schreef op woensdag 3 juli 2024 @ 18:05:

De plaatsing is geautomatiseerd, niet geabstraheerd. Je kan prima zien waar je pods staan, je servers staan etc. Maar nu regelt een k8s het voor mij dat er bijvoorbeeld pods in alle availability zones of zelfs verschillende regio's staan zodat hardware outages nooit (veel) impact hebben - k8s regelt dat m'n workload automatisch verplaatst en dat is heel fijn als er 's nachts opeens een network, internet of power outage bij mij provider is.

Dat is fijn, absoluut. Alleen heb ik in de afgelopen jaren amper hardware failures of storing gezien, als er iets fout ging was het vaak software of configuratie. Het aantal outages zie ik ook hoger bij service based systemen omdat A: er meer kapot kan (onderling netwerk) en B: de complexiteit, dus foutgevoeligheid hoger is.

Merethil schreef op woensdag 3 juli 2024 @ 18:05:

Eens, behalve dat je bij microservices gedwongen wordt hierover na te denken en het toe te passen omdat andere zaken altijd extern van je eigen microservices zijn. Dus je kan de shortcuts van bijvoorbeeld "even een private method aanroepen" gewoon niet uitvoeren tussen microservices. Je interface wordt een stuk strakker afgedwongen.

Aan de ene kant fijn, aan de andere kant vrij traag als je voor alles een netwerk call moet doen. Ook wil je nog wel eens in de problemen komen met bepaalde systemen. Voorbeeld:

• Service A houd een lijst bij
• Service A vraagt gegevens op bij service B
• Service B antwoord met een paginated set aan data
• Service A wil data van service B filteren op basis van de bijgehouden lijst
• Paginated set klopt niet meer (inconsistentie opgetreden)

Zaken die veel simpeler op te lossen zijn in een monoliet omdat we gewoon "iel vies" bij de database query/orm call kunnen en een query kunnen runnen, kun je ook een keer een fatsoenlijke index erop zetten.

Ja, je interface kan soms iets vertroebelen, maar hij zijn prima design patterns voor om dit een nette plek te geven.

Overigens is het voorbeeld hierboven los gebaseerd op een project wat WEL microservices gebruikt (en terecht) maar de zaken die jij mooi neerzet als "strakker" zijn niet per se beter. Of het beter is hangt namelijk de context af.

Merethil schreef op woensdag 3 juli 2024 @ 18:05:

Gerichter schalen is zeer fijn als één service veel gebruikt wordt en de rest niet. Als iemand jouw login hamert blijft de rest gewoon rustig doorgaan terwijl de loginservice opschaalt. Zelfde voor het verwerken van asynchrone processen; cronjobs draaien volledig separaat en trekken niet zomaar je server omver, processen die op queues luisteren kunnen opschalen zonder dat omliggende code die niets doet ook mee moet schalen etc. Ik zie daar genoeg voordeel in imo.

Klinkt in theorie mooi maar als die login service omgaat gaat vervolgens elke andere service om met een gateway timeout omdat de sessie niet opgehaald kan worden. Waar die monoliet op een enkele server misschien wel genoeg headroom heeft om gewoon alle requests te beantwoorden.

Het is nu niet te zeggen of een toekomstige applicatie langer door gaat kunnen in een microservice scenario of op een enkele zware server. Punt blijft wel dat bij rust een enkele request op de zware server waarschijnlijk gewoon sneller geserveerd kan worden. De hele microservice architectuur is dat punt een premature optimization.

Merethil schreef op woensdag 3 juli 2024 @ 18:05:
[...]
Zoals genoemd; met 2 mensen konden we prima middelgrote bedrijven bedienen wat betreft k8s en het gros van het onderhoud was gewoon uit handen genomen. Zelf niet een proces hoeven aftrappen om naar een andere regio te gaan als m'n regio even outage heeft, of zelf niet hoeven nadenken over het opzetten van servers voor verschillende instanties van je service vind ik zelf erg fijn en scheelt mij letterlijk dagelijks tijd.

Eerder noemde je ook dat je, je bezig met houden capacity planning, scaling, networking etc) klinkt als meer (terugkerend werk) dan die ene keer dat je een regio moet switchen. Hebben de meeste web projecten sowieso niet mee te maken. Ik haal hier verder wel uit dat je best dus nog wat tijd aan hele beheer kwijt bent. Nu is dat ook zo als je op een simpele server zet (beetje is nooit weg) maar ik kom zeker niet aan 2 personen.

Ik probeer je trouwens niet te overtuigen dat in jouw use case K8s een slechte keuze is (ik ken jouw use case niet en je klinkt wel in een situatie te zitten waarin het wellicht heel nuttig is). Mijn punt is dat het onverstandig is om altijd met microservices te start zonder gemotiveerde reden anders dan "waarom niet" en dat wel degelijk nadelen aan zitten waar wel over moet worden nagedacht.

Kom ik terug op: zonder motivatie waarom microservices een goed idee zijn is het bijna altijd een slecht idee.

[Woy]

Sowieso is het echt niet zo dat microservices makkelijk zijn om goed op te zetten, er komt een hele legio aan andere problemen naar voren. Ik heb ook meermaals micro Services gezien die voor alles en nog wat REST calls gingen maken. Want er wordt gedaan alsof bij micro Services magisch een slimme indeling van domeinen gemaakt wordt. Ik zie vaker dat het meer een doel dan middel is.

Als je al een goed design kunt maken, dan kan je binnen een monoliet ook gewoon een nette structuur aanhouden. En als er een hot Path is waar veel Scaling nodig is, kun je ook een micro service naast de monoliet zetten.

Ik ben het met @Ed Vertijsment eens dat het goed is om de context te bekijken. Maar zowel bij micro Services als bij een monoliet moet je goede mensen hebben die de architectuur en het design goed opzetten en bewaken.

[MarcoC]

Ik zou zelf zo simpel mogelijk beginnen en kiezen voor een VPS met Docker + docker-compose.yml. Onderhoud stelt niet veel voor, al je applicaties en dependencies zitten in containers dus je OS updaten is af en toe apt update && apt upgrade -y en je kan weer verder. Dit werkt simpel, is heel robuust, en kost weinig tijd/onderhoud.

[Merethil]

Ed Vertijsment schreef op woensdag 3 juli 2024 @ 20:36:
[...]


Nu heb ik geen enkele twijfel over jouw skills om K8s in te richten maar mijn punt was dat je dus wel die extra handjes nodig hebt voor het onderhouden van de logic (capacity planning, scaling, networking etc). Extra kosten en complexiteit dus.

Dat is natuurlijk niet allemaal nodig voor één set aan applicaties; zoals ik eerder al had genoemd raad ik bedrijven alleen aan naar k8s te gaan als je al je applicaties erheen brengt. Tot die tijd is het naar mijn mening inderdaad teveel overhead.
In mijn voorbeelden ging het om bedrijven waar ze al hun producten en webservices/sites op k8s draaiden, inclusief zaken als SSO, Kafka, elastic search etc. Dan haal je naar mijn mening ook het meest uit de flexibiliteit van het platform. En dat alles was dus goed te managen met twee Opsers.

Of je dat een moeilijk kan opdelen is nog maar de vraag, dat hangt van de applicatie af. Een punt wat ik eerder maakte is dat het veel handig is om rekening te houden met het kunnen opsplitsen in plaats van het op voorhand alles opsplitsen.

Niet elke app is Netflix (de meeste niet), en het punt dat ik maakte dat het doorgans niet een goed idee is om op voorhand altijd te beginnen met microservices omdat het geld, capaciteit en performance kost voor de meest meeste use cases, Als startup heb je vaak nog niets aan zo veel gedistribueerde logica.

Eens, maar als je al een architectuurplan hebt voor je opzet (zoals de TS) dan denk ik dat op beide manieren je iets goed neer kan zetten met toekomstvisie, en dan zou ik persoonlijk kiezen voor microservices omdat ik merk dat die refactor anders nooit meer plaatsvindt en zaken toch wel eens willen gaan knarsen in schaalbaarheid en onderhoudbaarheid.

Ik stelde de vraag waarom een monoliet niet volstond (dat kan prima zo zijn) en waarom er microservices gebruikt moesten worden. Je gaf aan "waarom" niet en daarmee impliceer je dat dus geen noemenswaardige nadelen zijn, waar ik niet in mee ga. Hogere kosten, meer complexiteit en een grote vaag naar personeel om het te beheren lijken mij groot genoeg risico's om in ieder geval bij stil te staan. Zonder motivatie waarom microservices een goed idee zijn is het bijna altijd een slecht idee.

Mijn "waarom niet" komt dus voor uit een set aan ervaringen waar ik meer voordeel heb gezien in microservices, bij jou is dat blijkbaar andersom. Ik snap jouw gedachtengang ook maar heb het zelf altijd anders ervaren. Kosten zijn zeer goed te reduceren (zeker bij serverless, want dan kan je naar nul toe optimaliseren), complexiteit is af te vangen met platformen als Fargate of managed k8s en het beheer valt in mijn ervaring dus zeer mee.

Dat is fijn, absoluut. Alleen heb ik in de afgelopen jaren amper hardware failures of storing gezien, als er iets fout ging was het vaak software of configuratie. Het aantal outages zie ik ook hoger bij service based systemen omdat A: er meer kapot kan (onderling netwerk) en B: de complexiteit, dus foutgevoeligheid hoger is.

Dit is natuurlijk N=1 (net als mijn ervaringen, natuurlijk) maar ik zie juist bijna wekelijks issues met netwerken, regionale beschikbaarheid en hardware die er soms gewoon mee stopt. Zowel on-prem als in de cloud, alleen wordt het bij die laatste aardig weggemoffeld.

Aan de ene kant fijn, aan de andere kant vrij traag als je voor alles een netwerk call moet doen. Ook wil je nog wel eens in de problemen komen met bepaalde systemen. Voorbeeld:

• Service A houd een lijst bij
• Service A vraagt gegevens op bij service B
• Service B antwoord met een paginated set aan data
• Service A wil data van service B filteren op basis van de bijgehouden lijst
• Paginated set klopt niet meer (inconsistentie opgetreden)

Zaken die veel simpeler op te lossen zijn in een monoliet omdat we gewoon "iel vies" bij de database query/orm call kunnen en een query kunnen runnen, kun je ook een keer een fatsoenlijke index erop zetten.

Die "iel vies" is natuurlijk één van die shortcuts die genoemd werden ik ben altijd wat allergisch voor niet weten welke delen van alle applicaties praten met iets als een DB; je kan maar moeilijk pinpointen waar welke access patterns opeens problemen opleveren. Dit los je niet zomaar op met microservices maar door de scheiding is een stuk beter te reguleren wie wat doet op welk moment omdat alle access patterns door één plek heen gaan.

Ja, je interface kan soms iets vertroebelen, maar hij zijn prima design patterns voor om dit een nette plek te geven.

Overigens is het voorbeeld hierboven los gebaseerd op een project wat WEL microservices gebruikt (en terecht) maar de zaken die jij mooi neerzet als "strakker" zijn niet per se beter. Of het beter is hangt namelijk de context af.

Zeker, en diezelfde soort design patterns heb je ongeacht infrastructurele keuzes nodig dus het één is niet beter dan het ander tot je alle "it depends" hebt doorlopen

Klinkt in theorie mooi maar als die login service omgaat gaat vervolgens elke andere service om met een gateway timeout omdat de sessie niet opgehaald kan worden. Waar die monoliet op een enkele server misschien wel genoeg headroom heeft om gewoon alle requests te beantwoorden.

Het is nu niet te zeggen of een toekomstige applicatie langer door gaat kunnen in een microservice scenario of op een enkele zware server. Punt blijft wel dat bij rust een enkele request op de zware server waarschijnlijk gewoon sneller geserveerd kan worden. De hele microservice architectuur is dat punt een premature optimization.

Niet mee eens. Als je een fatsoenlijke auth-oplossing kiest als OAuth dan kan je tokens uitleveren die niet nog eens naar de loginserver hoeven om gecheckt te worden. Daarnaast kan ik vrij oneindig de loginservice opschalen dus red ik het sowieso wel; een monoliet schaal je niet even snel even veel op tenzij je heel veel heel dure servers wil opspinnen in vergelijking met mijn relatief lichtgewicht pods.

Eerder noemde je ook dat je, je bezig met houden capacity planning, scaling, networking etc) klinkt als meer (terugkerend werk) dan die ene keer dat je een regio moet switchen. Hebben de meeste web projecten sowieso niet mee te maken. Ik haal hier verder wel uit dat je best dus nog wat tijd aan hele beheer kwijt bent. Nu is dat ook zo als je op een simpele server zet (beetje is nooit weg) maar ik kom zeker niet aan 2 personen.

Het is vooral werk dat je éénmaal doet en af en toe op terugkomt als de omgeving verder groeit. Erg weinig continu onderhoud in mijn ervaring.

Ik probeer je trouwens niet te overtuigen dat in jouw use case K8s een slechte keuze is (ik ken jouw use case niet en je klinkt wel in een situatie te zitten waarin het wellicht heel nuttig is). Mijn punt is dat het onverstandig is om altijd met microservices te start zonder gemotiveerde reden anders dan "waarom niet" en dat wel degelijk nadelen aan zitten waar wel over moet worden nagedacht.

Kom ik terug op: zonder motivatie waarom microservices een goed idee zijn is het bijna altijd een slecht idee.

En andersom probeer ik je ook niet te overtuigen van niet voor monolieten gaan, maar ik probeer vooral te laten zien dat beide kanten op voor elk voordeel een nadeel is te verzinnen en vice versa.

Woy schreef op woensdag 3 juli 2024 @ 21:05:
Sowieso is het echt niet zo dat microservices makkelijk zijn om goed op te zetten, er komt een hele legio aan andere problemen naar voren. Ik heb ook meermaals micro Services gezien die voor alles en nog wat REST calls gingen maken. Want er wordt gedaan alsof bij micro Services magisch een slimme indeling van domeinen gemaakt wordt. Ik zie vaker dat het meer een doel dan middel is.

Volgens mij heeft niemand gezegd dat het een silver bullet is, maar het is ook zeker niet moeilijk om het goed op te zetten. Veel mensen zitten echter vast in bepaalde denkwijzen en dan is omschakelen lastig - allebei de kanten op, trouwens (enigszins schuldig hier)

Als je al een goed design kunt maken, dan kan je binnen een monoliet ook gewoon een nette structuur aanhouden. En als er een hot Path is waar veel Scaling nodig is, kun je ook een micro service naast de monoliet zetten.

Eens, die gulden-middenweg heb ik ook ingezet bij klanten. Alle asynchrone processen met queues en cronjobs liepen via Lambda zodat het flink schaalbaar is maar weinig kost (en niets kost zodra er niets te doen is), terwijl de hoofdapplicatie draaide op een set EC2s voor de brute kracht die ze nodig hadden voor hun data analytics.

[Guus...]

Ed Vertijsment schreef op dinsdag 2 juli 2024 @ 21:15:
Toch ben ik even benieuwd waarom je gelijk naar containers wil. Even plat gezegd: waarom is een dikke vette monoliet niet goed (genoeg)?

Ed Vertijsment schreef op woensdag 3 juli 2024 @ 13:44:
De vraag K8s of docker had ik dan ook beantwoord met (K8s), maar ik was wel benieuwd naar de motivatie om überhaupt daar mee te beginnen, beetje een X/Y probleem.

Beide bovenstaande opmerkingen klinken als "ik zou CSS in plaats van SQL gebruiken"

K8s is een orchestration tool voor containers zoals docker. Een monoliet kan in een container.

[Ed Vertijsment]

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

Dat is natuurlijk niet allemaal nodig voor één set aan applicaties; zoals ik eerder al had genoemd raad ik bedrijven alleen aan naar k8s te gaan als je al je applicaties erheen brengt. Tot die tijd is het naar mijn mening inderdaad teveel overhead.
In mijn voorbeelden ging het om bedrijven waar ze al hun producten en webservices/sites op k8s draaiden, inclusief zaken als SSO, Kafka, elastic search etc. Dan haal je naar mijn mening ook het meest uit de flexibiliteit van het platform. En dat alles was dus goed te managen met twee Opsers.

Mijn ervaring qua beheerbaarheid zijn daarin hetzelfde, maar niet elk project van de start begint met al deze toestanden en de meeste zullen het misschien ook wel nooit nodig hebben. Naar mijn mening is het (in brede zin) goed om altijd na te denken over de "wendbaarheid" van je architectuur zonder daar een specifieke implementatie aan vast te te pinnen, dan kun je later altijd nog door bewegen naar het volgende, als je daar goed vanaf het begin over nadenkt hoeft dat echt geen groot probleem te zijn. Dit geld overigens niet alleen voor infra maar in veel meer aspecten van je applicatie. Houd er ook rekening mee dat wat vandaag hip is morgen misschien wel oud. Nu investeren in een oplossing voor over 3 jaar is over 3 jaar misschien wel achter de feiten aanlopen.

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

Eens, maar als je al een architectuurplan hebt voor je opzet (zoals de TS) dan denk ik dat op beide manieren je iets goed neer kan zetten met toekomstvisie, en dan zou ik persoonlijk kiezen voor microservices omdat ik merk dat die refactor anders nooit meer plaatsvindt en zaken toch wel eens willen gaan knarsen in schaalbaarheid en onderhoudbaarheid.

Als het gaat knarsen gaat er vaak genoeg van zelf een refactor plaatsvinden en een van de mogelijke refactors kan zijn een migratie naar een of meerdere microservices. Op dat moment heb je alle informatie die noodzakelijk is om geïnformeerd een keuze te maken, sommige applicaties hebben baat bij een hele andere soort optimalisatie dan de infra omgooien. Zonder het exacte probleem te kennen (wat je in het begin nog niet kent) kun je niet geinfomeerd een oplossing aandragen.

Als het niet gaat knarsen? Dan is er geen actie nodig.

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

Die "iel vies" is natuurlijk één van die shortcuts die genoemd werden ik ben altijd wat allergisch voor niet weten welke delen van alle applicaties praten met iets als een DB; je kan maar moeilijk pinpointen waar welke access patterns opeens problemen opleveren. Dit los je niet zomaar op met microservices maar door de scheiding is een stuk beter te reguleren wie wat doet op welk moment omdat alle access patterns door één plek heen gaan.

Ik deel die allergie en ik zette heel bewust het voorbeeld inclusief "iel vies" neer om aan te geven dat je er soms niet aan ontkomt een trade te doen tussen elegantie en performance, maar die keuze geven microservices je vaak niet. Het is naar mijn menig naïef om te denken dat je nooit tegen dergelijke problemen aanloopt en dus zul je soms creatief moeten zijn.

Het beschreven probleem is veel lastiger op te lossen met microservices dit soort uitdagingen zijn slechts een van de problemen die je tegen gaat komen op het moment dat je microservices introduceert (wat @Woy ook al eerder aangaf). Overigens is het prima de iel vies oplossing zo te implementeren dat het prima duidelijk is wat waar en waarom met de database praat.

Met de database praten is (al dan niet via een service layer/ORM of iets degelijks) is sowieso niet per se slecht. Referential integrity en transacties etc. zijn best fijn om te hebben en die raak je vaak kwijt met microservices (tenzij je weer een berg complexiteit toevoegt met mogelijk meer performance verlies tot gevolg).

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

Zeker, en diezelfde soort design patterns heb je ongeacht infrastructurele keuzes nodig dus het één is niet beter dan het ander tot je alle "it depends" hebt doorlopen

Exact het punt dat ik widle maken , maar "waarom niet" gaat dus niet op .

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

Niet mee eens. Als je een fatsoenlijke auth-oplossing kiest als OAuth dan kan je tokens uitleveren die niet nog eens naar de loginserver hoeven om gecheckt te worden. Daarnaast kan ik vrij oneindig de loginservice opschalen dus red ik het sowieso wel; een monoliet schaal je niet even snel even veel op tenzij je heel veel heel dure servers wil opspinnen in vergelijking met mijn relatief lichtgewicht pods.

Vervang nu je login service voor service X, die in de praktijk voor elke page view benodigd is want service A<->B<->Z<->X. In de praktijk valt gewoon het hele zooitje om als een service er mee ophoud (ook al maken wij onszelf graag wijs dat, dat niet zo is). En waar dat niet zo is, is het ook niet zo dat, dat met een monoliet wel zo zou zijn.

Verder kom je hier terug op het fabeltje dat monolieten niet makkelijk te schalen zouden zijn, load balancer ervoor en klaar. Maar de server waar het hele zooitje op draait (eerder al genoemd "headroom") gaat doorgaans meer klappen op kunnen vangen dan een kleine container, dus waarom zou die schalen?

Overigens ga je minder "zware" servers nodig hebben voor je aantal "lichte" pods dus (doorgaans is 1 zat) dus qua totale kosten ben je vaak veel goedkoper met een niet K8s oplossing.

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

Het is vooral werk dat je éénmaal doet en af en toe op terugkomt als de omgeving verder groeit. Erg weinig continu onderhoud in mijn ervaring.

Dat is ook mijn ervaring, al zie ik wel (iets) meer onderhoud en vooral complexer waardoor je meer expertise (en dus kosten) in huis moet hebben.

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

En andersom probeer ik je ook niet te overtuigen van niet voor monolieten gaan, maar ik probeer vooral te laten zien dat beide kanten op voor elk voordeel een nadeel is te verzinnen en vice versa.

Exact mijn punt: je kunt niet zonder de applicatie/organisatie/context te kennen van te voren zeggen een monoliet of een microservice setup is beter. Maar wat ik wel vaak zie is dat er automatisch gegrepen wordt naar microservices omdat het idee leeft dat, dat beter zou zijn dan een monoliet wat naar mijn mening in veel gevallen gewoon niet zo is.

De gefundeerde motivaties om voor microservices te gaan zijn in mijn ervaring vaker niet technisch van aard, bijvoorbeeld organisatorisch: verschillende afdelingen die los van elkaar willen bouwen.

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

Volgens mij heeft niemand gezegd dat het een silver bullet is, maar het is ook zeker niet moeilijk om het goed op te zetten. Veel mensen zitten echter vast in bepaalde denkwijzen en dan is omschakelen lastig - allebei de kanten op, trouwens (enigszins schuldig hier)

Om het goed op te zetten komen heel veel dingen kijken, of je mist gewoon bepaalde zaken. Ik wil best aannemen dat het voor jouw gesneden koek is maar realiseer je wel learning curve die verschillende keren benoemd wordt daadwerkelijk een ding is, en dat is een ding omdat het een complex plaatje is. En het gaat niet over een tooltje leren, of een tooltje voor het tootlje, of een bestandsformaat voor het tooltje. Maar een hele waslijst aan zaken waar rekening mee moet worden gehouden door een heel development team(s) (en ops team(s)). Alles bovenop bestaande skillsets. Dat is niet simpel. En volgens het "KISS" principe ontwijk je dit als het niet nodig is.

Dus altijd eerst per case bekijken wat de waarde is, en ik zou daar voor de simpelste geschikte benadering gaan. Voor de meeste projecten kun je dan prima af met een monoliet. Wil je 'em in een container? Prima, maar ik zou al die services nog even laten voor wat het is.


Ik zal overigens ook vast enigszins ergens vastzitten in bepaald gedachtegoed, volgens mij is dat menselijk.

Merethil schreef op woensdag 3 juli 2024 @ 22:07:
[...]

Eens, die gulden-middenweg heb ik ook ingezet bij klanten. Alle asynchrone processen met queues en cronjobs liepen via Lambda zodat het flink schaalbaar is maar weinig kost (en niets kost zodra er niets te doen is), terwijl de hoofdapplicatie draaide op een set EC2s voor de brute kracht die ze nodig hadden voor hun data analytics.

Klinkt als een prima setup.

[Ed Vertijsment]

Guus... schreef op donderdag 4 juli 2024 @ 00:18:
[...]


[...]


Beide bovenstaande opmerkingen klinken als "ik zou CSS in plaats van SQL gebruiken"

K8s is een orchestration tool voor containers zoals docker. Een monoliet kan in een container.

Hoewel ik just for fun wel benieuwd ben in hoeverre je CSS selectors als query taal zou kunnen gebruiken denk ik dat ik K8s/microservices een beetje door elkaar heb gebruikt. Ja, je kan prima een monoliet in een container mikken. Maar voor 1 container K8s optuigen is een beetje overkill als je het mij vraagt.

[Marcj]

Ed Vertijsment schreef op woensdag 3 juli 2024 @ 09:55:
[...]
In de basis prima advies, alleen zou ik niet starten met microservices maar wel dingen goed opsplitsen zodat je later makkelijker kan refactoren (mogelijk naar microservices).

In de hele micro-service vs monoliet discussie was ik misschien wat extreem, maar ik zou echt willen dat we eerder bedacht hebben dat je domeinen wilt scheiden als je groter wordt. En daar zit de crux denk ik ook. Zolang je met 1 of 2 ontwikkelteams (zeg tot 10 ontwikkelaars) bezig bent dan is een monoliet makkelijker en sneller te ontwikkelen. Als het de architectuur goed hebt is het ook prima te runnen. Maar als je dan nog groter wordt, dan krijg je echt problemen en werkt een micro-service architectuur echt beter.

Daarbij wil ik wel opmerken dat "micro" ook een hele discussie oplevert. Ik heb ook projecten gezien waar je het echt te klein opknipt, waardoor je echt heel veel onnodige overhead krijgt. Dus opsplitsen in logische domeinen werkt wel goed. Maar maak het ook zeker niet te klein, dan krijg je inderdaad wel problemen.

En je kunt ook prima met een monoliet beginnen, waar je de zaken wel goed opsplitst zodat je laten wel delen eenvoudig eruit kunt halen. Maar uit mijn ervaring gaat dat niet helemaal werken zonder dat expliciet te maken. Het is te makkelijk voor een ontwikkelaar om data uit een ander deel er direct bij te betrekken, dus gaat het gebeuren.

Waar wij nu tegenaan lopen is dat in de monoliet we queries op de database doen over domeinen heen. Dat is lekker efficient voor bepaalde pagina's, maar maakt het erg ingewikkeld om te refactoren. Helemaal nu we een deel ui de main database willen halen en naar een andere schaalbare database willen krijgen.

Mijn mening: micro-services zijn erg handig als je echt wil opschalen naar iets groots. Als je verwacht dat het nooit zo groot wordt, is een monoliet ook prima. Maar denk dan wel goed na over jouw architectuur.

Edit:

Er nog eens over nadenkend is een combinatie van een monoliet met wat kleine services er omheen wel redelijk ideaal. Het grootste nadeel van het hebben van vele componenten is dat elk ook hun eigen CI/CD pipeline onze moeten hebben. En ze moeten allemaal geupdate worden enzo. Dan zou ik kijken welke delen schaalbaarder moeten zijn en die apart houden. En zorg in de monoliet wel voor een nette architectuur, anders wordt het refactoren en opslitsen later echt een ramp.

[ Voor 10% gewijzigd door Marcj op 04-07-2024 12:30 ]

[Woy]

Marcj schreef op donderdag 4 juli 2024 @ 12:20:
[...]

In de hele micro-service vs monoliet discussie was ik misschien wat extreem, maar ik zou echt willen dat we eerder bedacht hebben dat je domeinen wilt scheiden als je groter wordt. En daar zit de crux denk ik ook. Zolang je met 1 of 2 ontwikkelteams (zeg tot 10 ontwikkelaars) bezig bent dan is een monoliet makkelijker en sneller te ontwikkelen.

Maar dat is denk het hele punt, het opsplitsen van je Domain wil je ook binnen een monoliet al wel doen. Het feit dat het binnen een enkel process draait wil niet zeggen dat alles maar als spaghetti aan elkaar moet zitten. Ook daar kun je overigens met iets simpels als architectuur testen dat redelijk afdwingen.

Ik zie echt in sommige scenario's wel meerwaarde van micro-services, maar veel van de voordelen kun je ook gewoon in-process voor elkaar krijgen.

[SiErRa]

Marcj schreef op donderdag 4 juli 2024 @ 12:20:
[...]
En je kunt ook prima met een monoliet beginnen, waar je de zaken wel goed opsplitst zodat je laten wel delen eenvoudig eruit kunt halen. Maar uit mijn ervaring gaat dat niet helemaal werken zonder dat expliciet te maken. Het is te makkelijk voor een ontwikkelaar om data uit een ander deel er direct bij te betrekken, dus gaat het gebeuren.

Dat kan je eigenlijk alleen met code-reviews voorkomen, wat nog wel een handig hulpmiddel is, zijn unittests frameworks waarmee je je architectuur controleert, zoals deze voor .Net en deze voor Java.

Waar wij nu tegenaan lopen is dat in de monoliet we queries op de database doen over domeinen heen. Dat is lekker efficient voor bepaalde pagina's, maar maakt het erg ingewikkeld om te refactoren. Helemaal nu we een deel ui de main database willen halen en naar een andere schaalbare database willen krijgen.

Ja, dat is eigenlijk ook zo'n shortcut. Daarom zou je je domeinen misschien vanaf dag 1 wel in losse databases neer willen zitten. Maar wederom ook met code-reviews wel te voorkomen.

[Marcj]

Woy schreef op donderdag 4 juli 2024 @ 13:11:
[...]

Maar dat is denk het hele punt, het opsplitsen van je Domain wil je ook binnen een monoliet al wel doen. Het feit dat het binnen een enkel process draait wil niet zeggen dat alles maar als spaghetti aan elkaar moet zitten. Ook daar kun je overigens met iets simpels als architectuur testen dat redelijk afdwingen.

Ik zie echt in sommige scenario's wel meerwaarde van micro-services, maar veel van de voordelen kun je ook gewoon in-process voor elkaar krijgen.

Dat ben ik ook met jou eens, dat is eigenlijk wat ik in mijn update ook zei. Ik zie het helaas wel vaak mis gaan wanneer je groeit met meer en meer ontwikkelaars. Niet iedereen ziet deze problemen meteen en dus schiet het er wel eens bij in.

SiErRa schreef op donderdag 4 juli 2024 @ 13:29:
[...]
Dat kan je eigenlijk alleen met code-reviews voorkomen, wat nog wel een handig hulpmiddel is, zijn unittests frameworks waarmee je je architectuur controleert, zoals deze voor .Net en deze voor Java.
[...]

Die ArchUnit tests kende ik nog niet, maar kan wel interessant zijn. Alleen jammer dat de voorbeeld gelijk zijn zoals ik het liever niet zie, maar dat is persoonlijk

Het voornaamste probleem dat ik nogal in de een start-up omgeving zie is dat de push voor nieuwe functionaliteit heel erg groot is. Vaak zo erg dat er short-cuts genomen worden waar je later heel veel spijt van hebt. En in die fase ben ik nu aan het werk als architect samen met ~10 engineering teams. Er zijn veel keuzes gemaakt in het verleden die nu heel veel werk kosten om te fixen.

[Ed Vertijsment]

Marcj schreef op donderdag 4 juli 2024 @ 12:20:
[...]

En je kunt ook prima met een monoliet beginnen, waar je de zaken wel goed opsplitst zodat je laten wel delen eenvoudig eruit kunt halen. Maar uit mijn ervaring gaat dat niet helemaal werken zonder dat expliciet te maken. Het is te makkelijk voor een ontwikkelaar om data uit een ander deel er direct bij te betrekken, dus gaat het gebeuren.

Is dat erg? Als er een noodzaak is om informatie uit meerdere bronnen te hebben dan is dat toch gewoon nodig? Of je dan een database query moet doen of een REST call maakt toch niet veel verschil? Behalve dat je met de laatste niet zomaar referential integrity of transacties hebt.

Volgens mij doen we net alsof we met microservices geen andere domeinen meer nodig hebben, die hebben we nog steeds nodig maar de IO is moeilijker en trager. Volgens mij is het gewoon zaak om hier goed mee om te gaan en dit netjes in te delen. Microservices gaan daar niet zomaar verandering in brengen.

Marcj schreef op donderdag 4 juli 2024 @ 12:20:
[...]
Waar wij nu tegenaan lopen is dat in de monoliet we queries op de database doen over domeinen heen. Dat is lekker efficient voor bepaalde pagina's, maar maakt het erg ingewikkeld om te refactoren. Helemaal nu we een deel ui de main database willen halen en naar een andere schaalbare database willen krijgen.

Misschien mis ik kennis van waar hier om gaat maar een van de eerste eerste dingen die ik mij afvraag is waarom die database niet zou schalen. Sure als je sqlite gebruikt misschien maar kun je dat dan niet eerst migreren voordat je database uit elkaar wilt trekken. En als er wel gewoon een MySQL/PostgreSQL/<database of choice> staat. Waarom schaalt ie niet? En is dat je niet je echte probleem?

Op je refactor vraagstuk: ja dat kan best complex zijn, maar zou dat niet net zo complex zijn als het meerdere REST calls waren over verschillende domeinen, en zeg eens eerlijk, gaat dan ook zo efficient?

Marcj schreef op donderdag 4 juli 2024 @ 12:20:
[...]

Mijn mening: micro-services zijn erg handig als je echt wil opschalen naar iets groots. Als je verwacht dat het nooit zo groot wordt, is een monoliet ook prima. Maar denk dan wel goed na over jouw architectuur.

De meeste projecten halen nooit het formaat dat microservices op technische afwegingen interssant worden, en mocht je dan toch zo groot worden als Netflix ga je echt wel aan de middelen kunnen komen om die refactors te doen.

De organisatorische afweging die je benoemde (hoeveel teams/developers) lijkt mij veel verstandiger om te maken als je gaat kiezen voor een opzet.

Marcj schreef op donderdag 4 juli 2024 @ 12:20:
[...]
Edit:

Er nog eens over nadenkend is een combinatie van een monoliet met wat kleine services er omheen wel redelijk ideaal. Het grootste nadeel van het hebben van vele componenten is dat elk ook hun eigen CI/CD pipeline onze moeten hebben. En ze moeten allemaal geupdate worden enzo. Dan zou ik kijken welke delen schaalbaarder moeten zijn en die apart houden. En zorg in de monoliet wel voor een nette architectuur, anders wordt het refactoren en opslitsen later echt een ramp.

Klinkt prima, services waar nodig, simpelheid waar mogelijk.

[Marcj]

Ed Vertijsment schreef op donderdag 4 juli 2024 @ 14:37:
[...]

Is dat erg? Als er een noodzaak is om informatie uit meerdere bronnen te hebben dan is dat toch gewoon nodig? Of je dan een database query moet doen of een REST call maakt toch niet veel verschil? Behalve dat je met de laatste niet zomaar referential integrity of transacties hebt.

Volgens mij doen we net alsof we met microservices geen andere domeinen meer nodig hebben, die hebben we nog steeds nodig maar de IO is moeilijker en trager. Volgens mij is het gewoon zaak om hier goed mee om te gaan en dit netjes in te delen. Microservices gaan daar niet zomaar verandering in brengen.

Het maakt het later opschalen door uit elkaar trekken van systemen echt moeilijker. Door het opsplitsen in domeinen kun je ook veel beter nadenken als je elkaars data nodig hebt op welke manier je dit wilt doen.

Voor de duidelijkheid: dit wordt pas relevant als je echt gaat opschalen.

[...]

Misschien mis ik kennis van waar hier om gaat maar een van de eerste eerste dingen die ik mij afvraag is waarom die database niet zou schalen. Sure als je sqlite gebruikt misschien maar kun je dat dan niet eerst migreren voordat je database uit elkaar wilt trekken. En als er wel gewoon een MySQL/PostgreSQL/<database of choice> staat. Waarom schaalt ie niet? En is dat je niet je echte probleem?

Misschien zit ook veel te veel vanuit mijn eigen werk te denken, waar we op behoorlijk grote schaal zitten te werken (denk miljoenen apparaten die communiceren voor 10-duizenden verschillende klanten). Dan bereik je wel limieten van een SQL voor een paar specifieke delen. En die wil je kunnen overzetten naar een beter schaalbare oplossing.

Op je refactor vraagstuk: ja dat kan best complex zijn, maar zou dat niet net zo complex zijn als het meerdere REST calls waren over verschillende domeinen, en zeg eens eerlijk, gaat dan ook zo efficient?

Micro-services hoeven niet alleen met REST calls met elkaar te praten. Er zijn nog veel meer manieren om dit efficient te doen. Denk ook aan data-duplicatie door event-sourcing bijvoorbeeld. Dan kun je in het ingress-proces ook de data masseren zodat het in een vorm is die die service nodig heeft.

Weer voor de duidelijkheid: alleen relevant als je naar echt grote schaal gaat. Dit zou ik niet bij een kleine start-up meteen doen.

[...]

De meeste projecten halen nooit het formaat dat microservices op technische afwegingen interssant worden, en mocht je dan toch zo groot worden als Netflix ga je echt wel aan de middelen kunnen komen om die refactors te doen.

De organisatorische afweging die je benoemde (hoeveel teams/developers) lijkt mij veel verstandiger om te maken als je gaat kiezen voor een opzet.

[...]

Klinkt prima, services waar nodig, simpelheid waar mogelijk.

Volgens mij zijn we het eigenlijk wel met elkaar eens. Zorg er vooral voor dat je niet een spaghetti aan code aan het maken bent die ook nog eens compleet geen test coverage heeft. Want dan heb je later heel veel spijt

[Ed Vertijsment]

Marcj schreef op donderdag 4 juli 2024 @ 16:24:
[...]


Het maakt het later opschalen door uit elkaar trekken van systemen echt moeilijker. Door het opsplitsen in domeinen kun je ook veel beter nadenken als je elkaars data nodig hebt op welke manier je dit wilt doen.

Voor de duidelijkheid: dit wordt pas relevant als je echt gaat opschalen.

Tuurlijk, maar nogmaals, als de requirement er is dan moet het. Kun je kiezen tussen een rest call of een query maar je zult de data moeten ophalen. Opsplitsen in domeinen kan ook in een monoliet. Later verder opsplitsen is dan prima mogelijk.

Marcj schreef op donderdag 4 juli 2024 @ 16:24:
[...]

Misschien zit ook veel te veel vanuit mijn eigen werk te denken, waar we op behoorlijk grote schaal zitten te werken (denk miljoenen apparaten die communiceren voor 10-duizenden verschillende klanten). Dan bereik je wel limieten van een SQL voor een paar specifieke delen. En die wil je kunnen overzetten naar een beter schaalbare oplossing.

Dat is zeker verkeer, volgens mij moet dit nog steeds prima te doen zijn met maar ik snap hier de wens.

Marcj schreef op donderdag 4 juli 2024 @ 16:24:
[...]

Micro-services hoeven niet alleen met REST calls met elkaar te praten. Er zijn nog veel meer manieren om dit efficient te doen. Denk ook aan data-duplicatie door event-sourcing bijvoorbeeld. Dan kun je in het ingress-proces ook de data masseren zodat het in een vorm is die die service nodig heeft.

True, en hoewel dit allemaal klinkt allemaal (is het ook) maar geen van deze aanpak verdient de voorkeur voor simpelere (de meeste) projecten.

Marcj schreef op donderdag 4 juli 2024 @ 16:24:
[...]

Weer voor de duidelijkheid: alleen relevant als je naar echt grote schaal gaat. Dit zou ik niet bij een kleine start-up meteen doen.


[...]


Volgens mij zijn we het eigenlijk wel met elkaar eens. Zorg er vooral voor dat je niet een spaghetti aan code aan het maken bent die ook nog eens compleet geen test coverage heeft. Want dan heb je later heel veel spijt

Dit dus

[NotAFarmer]

Graag wil ik, hoewel ik wat laat in het gesprek aansluit, toch nog enkele suggesties doen.

Kijk eens naar Jelastic. Wij maken hier naar volle tevredenheid gebruik van; het stelt ons in staat om Docker-images eenvoudig en schaalbaar te hosten. Wij nemen deze service af bij Previder. De leercurve van dit systeem is letterlijk nul.

Daarnaast zou je qua ontwikkeling altijd kunnen overwegen om een modulaire monoliet te gebruiken. Bij een goed ontwerp en uitvoering is het niet heel complex of tijdrovend om later de verschillende modules als microservices te implementeren.