Monolith vs Microservices eenvoudig weergeven*

[dakathefox]

Mijn vraag

Binnenkort moet ik een presentatie geven waarin ik het verschil tussen de huidige monolith omgeving vs. een microservices omgeving moet gaan uitleggen.

Aan een 80+ jarige...

In dit geval gaat het om een investeerder die al jaren aan boord is. Zeker geen domme man, maar wel iemand met weinig verstand van IT.

Ik ben op zoek naar relevant beeldmateriaal dat ik in de presentatie zou kunnen gebruiken. Maar wat ik zie zijn plaatjes met UI, Data Layers, DB's en ik ben bang dat hij dan al afhaakt. En dat terwijl zijn betrokkenheid wel van belang is.

Hebben jullie suggesties wat ik zou kunnen gebruiken?

[KoningsGap]

Weinig verstand van IT --> Zeker niet de diepte ingaan. Voordelen benoemen (snellere deployments, sneller inhaken op veranderende wensen van stakeholders enz.).

Het is een investeerder, geen IT manager, dus hou het oppervlakkig, zakelijk en laat hem zien wat het voor hém oplevert.

[dakathefox]

KoningsGap schreef op woensdag 28 oktober 2020 @ 10:52:
Weinig verstand van IT --> Zeker niet de diepte ingaan. Voordelen benoemen (snellere deployments, sneller inhaken op veranderende wensen van stakeholders enz.).

Het is een investeerder, geen IT manager, dus hou het oppervlakkig, zakelijk en laat hem zien wat het voor hém oplevert.

Bedankt, maar dit stukje lukt allemaal wel. Ik moet alleen wel de huidige monolith inzichtelijk maken. Het moet tastbaar zijn, anders gaat hij niet inzien waarom de oplossing waar ze nu aan werken eigenlijk een bodemloze put is.

[ydderf]

Laatst ben ik zoiets wel tegengekomen in een youtube filmpje m.b.t. de basic uitleg van Docker. Ik kan hem alleen zo ff niet terug vinden, maar ik bedoel zoiets (op 2:12 min) . Verderop in het filmpje zitten ook nog wel wat plaatjes.
Misschien dat je met de zoekterm "Docker microservice" nog iets verder komt?

[ Voor 12% gewijzigd door ydderf op 28-10-2020 11:01 ]

[farlane]

dakathefox schreef op woensdag 28 oktober 2020 @ 10:53:
Bedankt, maar dit stukje lukt allemaal wel. Ik moet alleen wel de huidige monolith inzichtelijk maken. Het moet tastbaar zijn, anders gaat hij niet inzien waarom de oplossing waar ze nu aan werken eigenlijk een bodemloze put is.

En het feit dat het een monoliet is is daar de oorzaak van? Wat voor een applicatie is het?

[Hydra]

dakathefox schreef op woensdag 28 oktober 2020 @ 10:53:
Bedankt, maar dit stukje lukt allemaal wel. Ik moet alleen wel de huidige monolith inzichtelijk maken. Het moet tastbaar zijn, anders gaat hij niet inzien waarom de oplossing waar ze nu aan werken eigenlijk een bodemloze put is.

Met hoeveel man werk je aan het systeem? Wat zijn de problemen en waarom zou volgens jou 'microservices' hier de oplossing zijn? Want dat is, en dit komt van iemand die al ruim 7 jaar werkt met microservices in verschillende omgevingen, alles behalve een gegeven.

Welke extra complexiteit komt er bij microservices kijken t.o.v. een monoliet?

[ Voor 28% gewijzigd door Hydra op 28-10-2020 16:35 ]

[Hydra]

ydderf schreef op woensdag 28 oktober 2020 @ 11:00:
Laatst ben ik zoiets wel tegengekomen in een youtube filmpje m.b.t. de basic uitleg van Docker.

Microservices hebben net zoveel met docker te maken als het ontwerpen van een huis met bakstenen. Daar heeft hij dus niks aan.

[Hydra]

dakathefox schreef op woensdag 28 oktober 2020 @ 10:51:
Binnenkort moet ik een presentatie geven waarin ik het verschil tussen de huidige monolith omgeving vs. een microservices omgeving moet gaan uitleggen.

Volgens mij wil je dat helemaal niet. Je focust je op het verkeerde. De vraag is; hoe overtuig je de persoon die betaalt dat er een grote refactoring gedaan moet worden. Dus wat is er tot nu toe verkeerd gegaan, hoe ga je dat oplossen, welke waarde levert dat op lange termijn op en hoeverhoudt zich dat tot de korte termijn kosten verhoudt. En vooral; hoe ga je garanderen dat de termijn correct ingeschat wordt, en niet weer dezelfde fouten gemaakt worden.

Dat je naar microservices wil, is voor die persoon helemaal niet relevant. Hij wil antwoord op bovenstaande vragen.

[Dricus]

En ook belangrijk: Een goed onderhoudbare monoliet maken is moeilijk. Een goed onderhoudbare microservices architectuur neerzetten is nog moeilijker. Dit weet diegene aan wie je die uitleg moet geven waarschijnlijk alleen niet.

Als dezelfde mensen die de problematische monoliet gemaakt hebben nu ook de microservices architectuur gaan maken, dan kun je kritische vragen verwachten. De boodschap zal als je niet uitkijkt al snel geïnterpreteerd worden als (gechargeerd) "wij hebben er een zooitje van gemaakt, maar met microservices gaat het allemaal goedkomen." Hoe gaan jullie ervoor zorgen dat het niet weer net zo'n zooitje wordt als dat het nu is?

Ik weet niet of dit in jouw situatie ook speelt, maar ik heb al heel vaak meegemaakt dat er (vaak terecht) een groot wantrouwen is jegens developers. Dat wantrouwen wegnemen is erg lastig bij dit soort voorstellen voor grote refactorings.

[Voutloos]

Wat Hydra zegt.

Zoals je het nu brengt heb je een oplossing op zoek naar een probleem.

[ydderf]

Hydra schreef op woensdag 28 oktober 2020 @ 16:37:
[...]

Microservices hebben net zoveel met docker te maken als het ontwerpen van een huis met bakstenen. Daar heeft hij dus niks aan.

Wat ik bedoelde, is dat er bij de basic uitleg van docker, vaak het verschil tussen de Monolith en Microservices uitgelegd wordt. Mogelijk kan TS daar wat relevante info vandaan halen. Tenmiste voor mij als leek is na mijn zoektocht "wat is docker" ook de termen "Monolith" en "Microservices" duidelijk geworden. Bijvoorbeeld het onderstaande plaatje heeft volgens mij een redelijk laag instapniveau, wat goed als basis voor een praatplaatje gebruikt kan worden om uit te leggen wat de verschillen zijn qua opzet.


Dus ik heb hiermee geprobeerd om de primaire vraag "Hoe vind ik beeldmateriaal om een leek het verschil tussen de Monolith en Microservices uit te leggen" te beantwoorden.
Dat er daarnaast nog andere dingen mee spelen, dat is zeker waar. Dus de aanvulling en opmerkingen van jou en andere kunnen zeker waardevol zijn voor TS.

[Hydra]

ydderf schreef op woensdag 28 oktober 2020 @ 17:21:
Wat ik bedoelde, is dat er bij de basic uitleg van docker, vaak het verschil tussen de Monolith en Microservices uitgelegd wordt. Mogelijk kan TS daar wat relevante info vandaan halen.

Het is voor de vraag van die investeerder helemaal niet relevant.

Tenmiste voor mij als leek

Niet om 't een of andere, maar waarom geef je hier als leek eigenlijk antwoorden op?

[Tsurany]

Jenga is wel een mooi voorbeeld. Je begint met een stabiele toren maar naar mate je blokken verwijderd en ergens anders terug legt wordt de toren steeds instabieler en is de kans op omvallen groter. Maak je echter vier kleine torens dan is vervangen van blokken makkelijker en kan je zelfs hele torens laten omvallen en vervangen zonder dat de rest geraakt wordt.
Tis een hele simplistische uitleg maar wel iets wat heel tastbaar is.


Aan de andere kant, het feit dat je het verschil aan een investeerder moet uitleggen is misschien wel omdat je niet fatsoenlijk kan onderbouwen en kwantificeren wat de voordelen van micro services boven een monolitische applicatie zijn in jullie specifieke situatie.

[Dricus]

Tsurany schreef op woensdag 28 oktober 2020 @ 17:47:
Jenga is wel een mooi voorbeeld. Je begint met een stabiele toren maar naar mate je blokken verwijderd en ergens anders terug legt wordt de toren steeds instabieler en is de kans op omvallen groter. Maak je echter vier kleine torens dan is vervangen van blokken makkelijker en kan je zelfs hele torens laten omvallen en vervangen zonder dat de rest geraakt wordt.
Tis een hele simplistische uitleg maar wel iets wat heel tastbaar is.

Maar de vergelijking gaat mank, want microservices staan (bijna) nooit op zichzelf, maar hebben onderlinge afhankelijkheden, bijvoorbeeld doordat ze elkaars REST API gebruiken, of omdat er messaging tussen services plaatsvindt via queues. Microservices zo opzetten dat je ze echt onafhankelijk van elkaar kunt deployen is niet triviaal.

[Tsurany]

Dricus schreef op woensdag 28 oktober 2020 @ 17:54:
[...]

Maar de vergelijking gaat mank, want microservices staan (bijna) nooit op zichzelf, maar hebben onderlinge afhankelijkheden, bijvoorbeeld doordat ze elkaars REST API gebruiken, of omdat er messaging tussen services plaatsvindt via queues. Microservices zo opzetten dat je ze echt onafhankelijk van elkaar kunt deployen is niet triviaal.

Het is inderdaad heel simplistisch. Maar het is dan ook geen onderwerp dat je even uit kan leggen aan iemand zonder IT ervaring.

Je moet of een echt duidelijke uitleg neer zetten of een analogie zoeken doe simpel genoeg is maar toch een indruk geeft van het verschil.

Daarnaast heb je nog allerlei manieren om microservices te integreren zoals service orchestration via een gateway of een event driven architectuur met een event bus in het midden. Dat leg je ook niet even zo uit vrees ik.

Wellicht gewoon weg blijven van de uitleg en een costs vs benefits vergelijking te maken.

[Dricus]

Tsurany schreef op woensdag 28 oktober 2020 @ 17:59:
[...]

Daarnaast heb je nog allerlei manieren om microservices te integreren zoals service orchestration via een gateway of een event driven architectuur met een event bus in het midden. Dat leg je ook niet even zo uit vrees ik.

Wellicht gewoon weg blijven van de uitleg en een costs vs benefits vergelijking te maken.

Ja, mee eens. Het is alleen best heel moeilijk om die vergelijking goed te maken. Het break even point tussen monoliet en microservices (als dat al bestaat) is niet makkelijk te bepalen.

Ik zou veel liever zien dat de keuze voor microservices gemaakt wordt vanuit een kwalitatief goed opgezette monoliet die daardoor gemakkelijk op te splitsen is. Je kunt dan veel beter een afweging tussen de monoliet versus microservices maken. Een goed opgezette microservices architectuur *zou* onderhoudbaarder *kunnen* zijn dan een slecht opgezette monoliet. Een goed opgezette monoliet is 100% zeker onderhoudbaarder dan een slecht opgezette monoliet.

[Hydra]

Dricus schreef op woensdag 28 oktober 2020 @ 18:18:
Ja, mee eens. Het is alleen best heel moeilijk om die vergelijking goed te maken. Het break even point tussen monoliet en microservices (als dat al bestaat) is niet makkelijk te bepalen.

Microservices is een organisatiestructuur, geen architectuur.

[Dricus]

Hydra schreef op woensdag 28 oktober 2020 @ 18:40:
[...]
Microservices is een organisatiestructuur, geen architectuur.

Hoe bedoel je dat precies?

[Gomez12]

ydderf schreef op woensdag 28 oktober 2020 @ 17:21:
[...]
Tenmiste voor mij als leek is na mijn zoektocht "wat is docker" ook de termen "Monolith" en "Microservices" duidelijk geworden. Bijvoorbeeld het onderstaande plaatje heeft volgens mij een redelijk laag instapniveau, wat goed als basis voor een praatplaatje gebruikt kan worden om uit te leggen wat de verschillen zijn qua opzet.

Alleen dat plaatje zegt mij niets over microservices.
Als ik dat plaatje zie denk ik eerder aan je gaat naar multi-server ipv echt 100% monolithic.

Maar het zegt mij niets over het micro gedeelte wat juist het onderscheidende is van micro services vs gewoon een aantal losse services op 1 of meerdere servers.

Dit zijn afaik redelijke standaard plaatjes voor microservices :

Krijg je die 2 plaatjes niet uitgelegd, dan zou ik zeggen schrap het hele plan maar en ga van monolith eerst maar eens naar meerdere services.

Want die plaatjes geven goed aan wat het micro in microservices is en waarom het microservices heten.

Wil je enkel financial services dubbel uitvoeren en loshalen van je monolith dan praat je over gewoon meerdere services / servers, niet over microservices.

Microservices is gewoon echt een specialistische tak van sport waar het totaal anders werkt als in een monolith.

Sowieso heb ik nog bijna nergens de behoefte gezien om van monolith -> microservices te gaan, zo goed als altijd zit er eerst een stap tussen : monolith -> services.
En over een paar jaar kan je dan gaan kijken of je enkele services om moet gaan zetten naar microservices.

Tsurany schreef op woensdag 28 oktober 2020 @ 17:59:
[...]
Het is inderdaad heel simplistisch. Maar het is dan ook geen onderwerp dat je even uit kan leggen aan iemand zonder IT ervaring.

Als de nood hoog genoeg is, dan is alles uit te leggen. Als je het niet aan een leek kan uitleggen dan is wmb over het algemeen de noodzaak er niet. (En je Jenga voorbeeld is wederom services en geen micro-services)

Wellicht gewoon weg blijven van de uitleg en een costs vs benefits vergelijking te maken.

Op microservices ga je die zwaar verliezen dat kan ik je nu al voorspellen. Microservices zijn inherent duur en traag, maar kunnen dat compenseren op andere vlakken als je op die andere vlakken echt problemen hebt.
En als je op die andere vlakken dus die problemen hebt, dan is de investeerder daarvan op de hoogte (en volstaat een korte globale omschrijving van die problematiek) en kan je hem ook uitleggen waarom microservices daarvoor de oplossing zouden zijn.

Dricus schreef op woensdag 28 oktober 2020 @ 18:18:
[...]
Ja, mee eens. Het is alleen best heel moeilijk om die vergelijking goed te maken. Het break even point tussen monoliet en microservices (als dat al bestaat) is niet makkelijk te bepalen.

Het is er simpelweg niet, omdat de verschillen te groot zijn. Ga gewoon eerst naar meerdere services en laat het hele micro-gedeelte achterwege daar heb je niets aan als je van een monoliet afkomt.

Een goed opgezette microservices architectuur *zou* onderhoudbaarder *kunnen* zijn dan een slecht opgezette monoliet.

Ehm, nee... Zelfs een slecht opgezette monoliet is nog beter onderhoudbaar dan de beste microservices omgeving. Omdat microservices simpelweg veel meer onderhoud en beheer vragen waar je nu nog geen kennis van hebt en wat je op de harde manier gaat leren.

[Dricus]

Gomez12 schreef op woensdag 28 oktober 2020 @ 18:56:
[...]
Ehm, nee... Zelfs een slecht opgezette monoliet is nog beter onderhoudbaar dan de beste microservices omgeving.

Als ik iets geleerd heb in al die jaren in de software development, dan is het wel dat dit soort absolute waarheden niet bestaan.

De plaatjes die je post zijn niet de enige verschijningsvorm van microservices die je in het wild tegenkomt.

[Hydra]

Dricus schreef op woensdag 28 oktober 2020 @ 18:44:
Hoe bedoel je dat precies?

Het is een oplossing voor "hoe laten we X developers werken aan 1 groot systeem", niet meer dan dat.

[Hydra]

Gomez12 schreef op woensdag 28 oktober 2020 @ 18:56:
Ehm, nee... Zelfs een slecht opgezette monoliet is nog beter onderhoudbaar dan de beste microservices omgeving. Omdat microservices simpelweg veel meer onderhoud en beheer vragen waar je nu nog geen kennis van hebt en wat je op de harde manier gaat leren.

Dit is iets kort door de bocht. Het is onmogelijk om meer dan een bepaald aantal mensen aan 'hetzelfde ding' te laten werken. Maar wat 'hetzelfde ding' precies is, en hoe goed mensen in staat zijn samen te werken, is van heel veel factoren afhankelijk. Er is wel een reden dat microservices populair zijn. Maar waar de individuele services simpeler zijn, is de totale samenhang dat alles behalve.

[johnkeates]

Als iemand (oud) niet in de IT zit leg ik het als volgt uit:

Stel dat je dingen van A naar B wil verplaatsen per schip, hoe meer je wil verplaatsen, hoe groter het laadruim moet zijn. Dat is die monoliet: een gigantisch schip, met 1 groot laadruim. Soms kunnen dingen niet bij elkaar in het ruim, bijvoorbeeld olie en zand. Dan moet je twee van die schepen hebben. Het kan ook zijn dat je net een beetje te veel moet meenemen, dat past dan niet op 1 schip, en dan moet je er ook weer een bij halen. Maar dan zou je als je slechts 10% meer wil al wel 100% meer schip hebben. Soms gaat een schip kapot, en dan staat alles stil, net als met periodiek onderhoud. Je kan dan een extra schip nemen, maar dan moet je dus twee van die grote schepen hebben, en dat is niet handig als je die niet altijd nodig hebt. Maar als je ze wel altijd nodig hebt zit je weer met hetzelfde probleem; je kan dan weer bij een enkele uitval een complete vracht niet vervoeren.

Dat kan handiger; je kan bijvoorbeeld dingen in kratten stoppen, of in drums, of in zeecontainers. Opeens kan je dan verschillende dingen tegelijk vervoeren, en dan niet alleen op dat ene schip, maar om dat het minder uit maakt hoe groot het schip is kan je bijvoorbeeld ook als je net wat meer ruimte nodig hebt een kleiner schip er bij halen. Natuurlijk is er een efficiency verschil, en is het niet altijd even handig om allemaal verschillende schepen te hebben; gelukkig kan je ook een schip delen. Dan zet je je container met daarin je kratten op een gemeenschappelijk ship en betaal je alleen voor die ene container met die kratjes. En daar houdt het niet op. Om dat je nu in kleine stukjes meer of minder kan doen naar smaak hoef je niet meer slechts 1 ding tegelijk te doen, kan je wisselen, opschalen en afschalen zonder dat alles tegelijk stil moet liggen, en kan je ook andere modaliteiten gebruiken, zoals een trein met containers. Of een vrachtwagen of een vliegtuig. In plaats van dat je dat ene grote schip van overslaghaven naar overslaghaven laat vragen om overal waar je moet zijn terecht te komen kan je gebruik maken van die gedeelde schepen, of treinen of vliegtuigen. Je kan dan altijd de beste route kiezen, en de beste methode, en als een methode of route wegvalt om wat voor reden dan ook, dan zet je je kratjes en je containers ergens anders neer. Zo kan je bijv. schade aan het spoor hebben waar door een trein niet kan rijden, dus dan zet je je container op een vrachtwagen. Dat kan wat duurder zijn, zo'n individueel vervoer, maar als je dat een paar keer moet doen tot dat de rails gerepareerd zijn is dat beter dan helemaal stilliggen. Je kan daar door ook per vervoer uitrekenen wat het kost, en aan de hand van je marge en andere feiten in het bedrijf dan kiezen om een container die minder geld oplevert dan maar even te laten wachten, terwijl een container die veel meer oplevert (geld, klantervaring, aanzien, wettelijke eisen) dan door een helikopter op te laten halen. Kost veel meer, maar dat helpt je wel even uit de brand. Dat gaat met een compleet schip niet lukken.

Dit omvat:
- meshing en deels service discovery
- multi-tenant hosting maar ook multi-tenant gebruik
- single-responsibility
- verkleinen van de blast radius als er wat mis gaat
- meer autonomie per onderdeel
- minder bijwerkingen bij geplande veranderingen

Maar ook: er is net als bij grote units of work een efficiency trade-off: van elke function call een service maken schiet niet op, net als dat je voor elke korrel rijst geen los schip in zet; wat werkt ligt in het midden en hangt vooral van separation of concerns, schaal en kennis van de ontwikkelaars, en de technologie af.

Voor de meeste C-level en hoger zijn er maar drie dingen van belang in het verhaal:
- minder risico
- meer autonomie
- efficiency

[ Voor 13% gewijzigd door johnkeates op 28-10-2020 19:47 ]

[Dricus]

Hydra schreef op woensdag 28 oktober 2020 @ 19:22:
[...]


Het is een oplossing voor "hoe laten we X developers werken aan 1 groot systeem", niet meer dan dat.

Dat is erg reductionistisch, en tegelijk raak je daarme denk ik wel de essentie van waar het om draait bij het ontwerpen van software: Je probeert software zo te structureren dat X developers daar voor lange tijd effectief aan kunnen ontwikkelen. En doorgaans is dat een continue proces, niet iets wat je 1 keer doet.

Maargoed, microservices wordt doorgaans wel gepresenteerd als een architectuur(stijl), en het is wat mij betreft niet het één óf het ander. Ik zou persoonlijk de definitie die je hier geeft prima kunnen gebruiken om uit te leggen wat we bedoelen met de term "architectuur" binnen de context van software development.

[Kalentum]

Monolith is V&D: alles onder 1 dak. Maar ging failliet. Omdat ze nergens goed in waren. En als je 1 afdeling verbouwt, dan had de rest er last van. Of als het dak lekt, heeft elke afdeling daar last van
Microservices zijn pandjes in een winkelcentrum. Ze werken samen maar kunnen zelf de meest efficiente bedrijfsvoering bepalen.

Dus plaatje laten zien van V&D logo en dat het ten onder gaat. En dan een succesvol winkelcentrum (bv de outlet in Roermond ofzo). Kleiner, flexibeler.

Monolith: dak lekt, kan bv een performance probleem in een backoffice pagina waardoor het aanmaken van een account soms moeizaam gaat.

Microservice: dat performance probleem is geïsoleerd De backoffice kan last hebben maar het winkeltje 'user registration' heeft nergens last van.

[dakathefox]

@johnkeates Volgens mij heb je een voorbeeld waar ik wel wat mee kan. Ik probeer zelf altijd de link te leggen met 'offline' of 'analoge' voorbeelden en dit is er eentje die wel past in het verhaal.

Voor de rest... Bedankt voor jullie input! Mijn insteek is in ieder geval om vanuit de problematiek de presentatie in te vliegen. De oplossing zit 'm zeker niet in de huidige monolitische omgeving, want daar worden honderden uren per maand op verbrand zonder enige zichtbare vooruitgang. En zelfs na livegang zouden we opnieuw dezelfde exercitie moeten doen, dus dan gaan we nog een keer honderden uren verbranden.

Fingers crossed.

[dakathefox]

farlane schreef op woensdag 28 oktober 2020 @ 16:22:
[...]

En het feit dat het een monoliet is is daar de oorzaak van? Wat voor een applicatie is het?

Het is een applicatie waar uiteindelijk honderden mensen tegelijkertijd in moeten gaan werken. Hij moet daarom schaalbaar zijn bijvoorbeeld. Verder zie je dat er door de jaren heen diverse partijen aan gewerkt hebben, zonder dat er enige helderheid is over wie nou uiteindelijk welke code heeft geschreven. Er is geen duidelijke structuur qua ontwikkeling, een OTAP omgeving is ook niet aanwezig en code staat over al en nergens - zelfs niet in Github.

Dus het is gewoon prutswerk.

[Dricus]

dakathefox schreef op woensdag 28 oktober 2020 @ 20:21:
[...]


Het is een applicatie waar uiteindelijk honderden mensen tegelijkertijd in moeten gaan werken. Hij moet daarom schaalbaar zijn bijvoorbeeld. Verder zie je dat er door de jaren heen diverse partijen aan gewerkt hebben, zonder dat er enige helderheid is over wie nou uiteindelijk welke code heeft geschreven. Er is geen duidelijke structuur qua ontwikkeling, een OTAP omgeving is ook niet aanwezig en code staat over al en nergens - zelfs niet in Github.

Dus het is gewoon prutswerk.

Ga je een complete herbouw voorstellen?

[Hydra]

dakathefox schreef op woensdag 28 oktober 2020 @ 20:19:
Voor de rest... Bedankt voor jullie input!

Beetje jammer dat je niet ingaat op de vragen die ik je stel. Dat verhaal wat je daar als 'antwoord' aangemerkt hebt, gaat hij nooit accepteren.

[ Voor 15% gewijzigd door Hydra op 28-10-2020 20:56 ]

[dakathefox]

Hydra schreef op woensdag 28 oktober 2020 @ 20:54:
[...]


Beetje jammer dat je niet ingaat op de vragen die ik je stel.

Ik heb je vragen wel gezien, maar omdat ze niet relevant waren aan mijn vraag heb ik ze in eerste instantie overgeslagen. Mijn vraag ging namelijk over hoe ik het beste een 80-jarige het verschil kon uitleggen. Niet of de keuze voor microservices de heilige graal is. Dat is 'ie niet altijd, maar in dit geval wel.

Met hoeveel man werk je aan het systeem?
Momenteel wordt er met twee man aan het systeem gewerkt. Eén van de developers werkt part-time, alhoewel het meer ad-hoc lijkt te zijn.

Wat zijn de problemen en waarom zou volgens jou 'microservices' hier de oplossing zijn?
Het werk wordt niet gestructureerd gedaan, er is ook eigenlijk geen plan van aanpak. Voor mijn gevoel is het gewoon alsof ze de opdracht hebben gekregen 'bouw systeem A maar opnieuw na' en dat hebben ze letterlijk gedaan.

De software is momenteel verre van af. Er zal nog een Rest API van scratch ontwikkeld moeten worden en daar gaat ook weer een vracht tijd in zitten. Men heeft verder niet nagedacht over de verdere toekomst van het platform, dus op termijn zal er weer een hele hoop ontwikkeling aan zitten te komen. En dat in een platform waar eigenlijk dus niet over nagedacht is.

Ik heb een semi kant-en-klare oplossing liggen, waarmee ik direct alle zaken rondom security, API's, frontend, backend, services geregeld heb. Dat is minder werk dan de bestaande applicatie nu alsnog geschikt maken.

[dakathefox]

Dricus schreef op woensdag 28 oktober 2020 @ 20:28:
[...]

Ga je een complete herbouw voorstellen?

Yep.

[Gomez12]

dakathefox schreef op woensdag 28 oktober 2020 @ 21:00:
[...]
Niet of de keuze voor microservices de heilige graal is. Dat is 'ie niet altijd, maar in dit geval wel.

Weet je wel wat microservices zijn?
Daar bouw je niet met 2 man aan.

Wat zijn de problemen en waarom zou volgens jou 'microservices' hier de oplossing zijn?
Het werk wordt niet gestructureerd gedaan, er is ook eigenlijk geen plan van aanpak.

Microservices zijn idd de oplossing als er niet gestructureerd gewerkt wordt en er geen plan van aanpak is.
Dan bouw je de ene microservice in nodejs, de volgende in VBA en nr 3 maar weer eens in python, nr 4 doen we maar in php, nr 5 vond ik nog een stukje autoit voor op github wat gewoon werkte na copy-paste, nr 6 doen we maar in java want daar heb ik deze week zin in om te leren.
Dat is echt de perfecte omgeving voor microservices, alleen heb je wel een paar 100 man nodig om alle omgevingen bij te houden en de verantwoordelijkheid over de microservices inzichtelijk te maken.
En je had er toch maar 2, dat gaat ietwat schuren...

Ik heb een semi kant-en-klare oplossing liggen, waarmee ik direct alle zaken rondom security, API's, frontend, backend, services geregeld heb. Dat is minder werk dan de bestaande applicatie nu alsnog geschikt maken.

Grappenmaker, ik kan zo 1000 telnrs vinden van verkopers die een betere semi kant-en-klare oplossing hebben liggen...

Serieus, begin hier niet aan, of je verwart een service-model met microservices of het gaat gewoon compleet voor geen ene meter werken met microservices.

[johnkeates]

Gomez12 schreef op woensdag 28 oktober 2020 @ 21:55:
[...]
[...]
[...]
Serieus, begin hier niet aan, of je verwart een service-model met microservices of het gaat gewoon compleet voor geen ene meter werken met microservices.

Of hij wel of niet microservices moet maken was de case hier niet lijkt me. Het gaat er om dat het uit te leggen is aan een investeerder.

Of je het moet doen is een heel ander verhaal, en dat gaat dan eerder over middelen, requirements en ervaring. Daar kan je dan het beste gewoon een nieuw topic over starten in plaats van scope creep introduceren.

Overigens ben ik het wel (deels) met jou en @Hydra eens hoor, maar ik denk zeker niet dat dit de plek is voor die discussie, vooral om dat dit topic goed als referentie (en als zoekresultaat) kan dienen. Dan is het niet handig als de inhoud de vraag (en het antwoord) niet meer reflecteert.

Stel dat men denkt dat het toch goed is om een flink stuk te praten over wat je in technische termen nodig hebt, wat het biedt, en of je het moet doen, dan zou ik eerder vragen aan dakathefox om daar een topic voor te openen met zijn stelling; en stel dat je (of we) het algemeen willen houden, dan maken we er een zelfstandig discussietopic van en linken we het desnoods hier.

[ Voor 34% gewijzigd door johnkeates op 28-10-2020 22:11 ]

[Gomez12]

johnkeates schreef op woensdag 28 oktober 2020 @ 22:09:
[...]
Of hij wel of niet microservices moet maken was de case hier niet lijkt me. Het gaat er om dat het uit te leggen is aan een investeerder.

Eerlijk gezegd komt het bij mij meer over als een slechte verkoper die een product heeft wat verkocht moet worden, maar die problemen heeft met het verkopen van dat product...

En in dat geval is een discussie over de levensvatbaarheid van een specifieke oplossing zinloos, dat is namelijk de enige oplossing die dakathefox te koop heeft, dus die moet er wel ingeschoven worden. Ongeacht hoe rond het gat ook is terwijl het pakket vierkant is.

Sorry hoor maar verkopers die een complete herbouw op basis van hun systeem een goed advies vinden zijn er echt 1000 in een dozijn. En altijd hebben ze een "semi-kant-en-klare-oplossing" liggen waar alleen de lokale personen maar een beetje in hoeven te tweaken maar als ze goed zijn is dat totaal geen werk hoor.

In het verleden heb ik wel eens bij dat soort verkopers voorgesteld : Ok, beetje tweaken dus... Jij als producteigenaar kan dat sneller als wij, oftewel als jij binnen 1000 factureerbare uren of exact over 1 jaar een oplossing kan bieden die voor onze organisatie echt voelt als een handschoen zonder problemen. Als jij dat aandurft dan stap ik nu naar de directeur die het zo zwart-op-wit zet qua 1000 factureerbare uren + afname van jouw pakket bij naar ons inzicht goede oplevering over 1 jaar.
Maar niemand die het aandurft hoor. Altijd is dan toch iets meer tweaken en kan er opeens niet meer gegarandeerd worden dat het kant en klaar opgeleverd kan worden etc. etc. etc.

Wmb gaat dit soort praktijken meer richting oplichting en dat vind ik wel vermeldenswaardig binnen het topic zelf.
Dit is wmb niet meer onschuldig slecht advies geven.

Er zijn 2 mogelijkheden wmb.
- Of hij begrijpt niet wat hij verkoopt en haalt service-structuur door de war met microservices
- Of hij gaat echt met vol verstand ervoor om gewoon een niet-passend product bij een bedrijf erin te praten.

[farlane]

Hydra schreef op woensdag 28 oktober 2020 @ 19:22:
[...]
Het is een oplossing voor "hoe laten we X developers werken aan 1 groot systeem", niet meer dan dat.

Uit nieuwsgierigheid : Waarom zou dat niet kunnen in een monoliet (met goed gedefinieerde APIs tussen componenten)?

Ik werk niet met microservices

Eerlijk gezegd komt het bij mij meer over als een slechte verkoper die een product heeft wat verkocht moet worden, maar die problemen heeft met het verkopen van dat product...

Hier sluit ik me bij aan. Ik wens de klant in kwestie veel wijsheid...

[ Voor 25% gewijzigd door farlane op 28-10-2020 22:55 ]

[Gomez12]

farlane schreef op woensdag 28 oktober 2020 @ 22:54:
[...]

Uit nieuwsgierigheid : Waarom zou dat niet kunnen in een monoliet (met goed gedefinieerde APIs tussen componenten)?

Ik werk niet met microservices

Omdat je per component toch nog steeds maar praktisch zoveel man eigenaar ervan kan laten zijn.

Oftewel als je 1 login-component hebt kan je niet snel iets in de lucht gooien dat voor china bijv het inloggen ook via wechat kan laten verlopen. Je hele applicatie verwacht dat het via die ene login-component verloopt.

Met microservices zou je gewoon een 2e login microservice de lucht in kunnen gooien (gemaakt door een los team in china die de microservice gewoon in een totaal andere taal kan maken) die je alleen gebruikt voor ip's afkomstig uit china.

Met microservices kan je echt elke onderlinge koppeling weghalen en ze puur laten werken op hoe je het verkeer laat routeren binnen je microservices mesh.
En hoe je het verkeer dan routeert hoef je nergens echt vast te leggen, dat kan je gewoon door hardwarematige load-balancers etc doen die weer totaal geen kennis hebben van jouw microservices maar wel verkeer routeren als een malle (inclusief failover en redundancy etc waardoor je je infrastructuur ook gelijk failover en redundant maakt)

Dat is tegelijk het mooie en het gevaar van microservices, in principe kan je gewoon login v2 lanceren die iets andere parameters pakt waarbij je login v1 micro-services dus een error 500 teruggeven bijv zodat je loadbalancers vanzelf login v1 micro-services uit gaan faseren en daar hoef je in principe niets voor te doen, het gaat "automatisch". En mocht het toch fout zijn in die login v2 dan geef je gewoon de oude parameters weer terug en je login v2 gaat nu error 500 produceren (want foutieve parameters) en gaat vanzelf uitgefaseerd worden terwijl login v1 vanzelf weer terug komt (want die gaat weer code 200 teruggeven)

Want je moet het organisatorisch wel redelijk strak hebben geregeld om te weten welke login services er allemaal draaien als micro-services en wie er waarvoor verantwoordelijk is en wie je moet hebben bij een upgrade etc.

Want het is een reeel risico dat iemand een verkeerde microservice lanceert en dat die dan alles omver trekt.

Plus dat je een uitgebreid monitoringssysteem moet hebben om exact te weten wat er nu allemaal draait binnen je micro-services mesh. Want in theorie kan iedereen een microservice lanceren en daarmee de jouwe overbodig maken. Of jij kan iemand anders zijn aanpassing overrulen.

Het voordeel is wel weer dat als alles platgetrokken wordt, dat je niet zoals bij componenten moet gaan debuggen en de code bekijken etc, nee je trekt gewoon de laatste update terug van die microservice en kijkt of dat het oplost, zoja dan is het binnen seconden / minuten gefixed tegenover uren in een klassiek componenten systeem.

Of laat ik het eens anders proberen te beschrijven, in een monoliet heb je allerlei functies die met code aan elkaar verbonden worden. In microservices heb je grofweg diezelfde functies alleen heten ze nu microservices en zijn ze niet meer via code aan elkaar verbonden, maar via het netwerk.
Alleen waar iedereen in code zou zeggen : Je moet geen hele lijsten switch/case/if-else statements aan gaan maken op ip-adres etc. want dat valt niet te onderhouden en je hebt geen overzicht.
Is dat in netwerkland zo ongeveer de norm, alleen zijn die lijsten dan nog eens veelal dynamisch via BGP en afhankelijk van de load etc en kunnen daarnaast de berichten weer via message-queues lopen die weer andere configs kunnen hebben etc. etc.

Kijk op netwerk-gebied zijn ze veel verder qua optimale routing etc dan iemand in code kan beschrijven, alleen waar een monoliet altijd zo goed als 0 latency heeft, daar kan het netwerk wel eens besluiten dat de amerikanen op de chinese micro-services moeten aanloggen en dan praat je rustig over 10 of 20 ms latency.
Met microservices kunnen berichten ook out-of-order binnenkomen en daar heb je maar mee te dealen (als je al het complete bericht krijgt en het niet verdeeld wordt over 2 micro-services die elk een half bericht krijgen)

[Hydra]

farlane schreef op woensdag 28 oktober 2020 @ 22:54:
Uit nieuwsgierigheid : Waarom zou dat niet kunnen in een monoliet (met goed gedefinieerde APIs tussen componenten)?

Dat vraag ik me ook af In theorie zou het moeten kunnen: netjes je monoliet in modules opdelen zoals je microservices opdeelt. Bijvoorbeeld door aparte libraries per module tet maken. Maar in de praktijk lukt dit dus gewoon nooit. Ik heb in al die jaren nog nooit gezien (selection bias natuurlijk) dat dit wel lukte. Ik denk dat dit vooral te maken heeft met dat softtware gebouwd wordt door mensen en mensen gemiddeld genomen lui en incompetent zijn Dat brengt je dus naar het voornaamste voordeel van microservices; een relatiief klein stuk software waar alleen een kleine groep mensen voor verantwoordelijk is.

[Hydra]

dakathefox schreef op woensdag 28 oktober 2020 @ 21:00:
Ik heb je vragen wel gezien, maar omdat ze niet relevant waren aan mijn vraag heb ik ze in eerste instantie overgeslagen. Mijn vraag ging namelijk over hoe ik het beste een 80-jarige het verschil kon uitleggen. Niet of de keuze voor microservices de heilige graal is. Dat is 'ie niet altijd, maar in dit geval wel.

Je bent nogal overtuigd van jezelf. Ik heb je al uitgelegd wat de vraag achter de vraag van die investeerder is.

Met hoeveel man werk je aan het systeem?
Momenteel wordt er met twee man aan het systeem gewerkt. Eén van de developers werkt part-time, alhoewel het meer ad-hoc lijkt te zijn.

Met maar 2 man die aan een systeem werken is er geen enkele reden om voor een microservice architectuur te gaan. Er is geen hard omslagpunt te geven, maar sowieso kun je met 2 man prima samen in een monoliet werken.

Wat zijn de problemen en waarom zou volgens jou 'microservices' hier de oplossing zijn?
Het werk wordt niet gestructureerd gedaan, er is ook eigenlijk geen plan van aanpak. Voor mijn gevoel is het gewoon alsof ze de opdracht hebben gekregen 'bouw systeem A maar opnieuw na' en dat hebben ze letterlijk gedaan.

De software is momenteel verre van af. Er zal nog een Rest API van scratch ontwikkeld moeten worden en daar gaat ook weer een vracht tijd in zitten. Men heeft verder niet nagedacht over de verdere toekomst van het platform, dus op termijn zal er weer een hele hoop ontwikkeling aan zitten te komen. En dat in een platform waar eigenlijk dus niet over nagedacht is.

Ik heb een semi kant-en-klare oplossing liggen, waarmee ik direct alle zaken rondom security, API's, frontend, backend, services geregeld heb. Dat is minder werk dan de bestaande applicatie nu alsnog geschikt maken.

En je geeft wederom echt nul redenen waarom hiervoor microservices nodig zijn.

Sterker nog; je geeft een hele goede reden waarom je beter geen microservices kunt gebruiken: een flink gebrek aan skills bij je collega's. Met zo'n grote groep relatief onervaren mensen, wordt het gegarandeerd een ramp.

[ Voor 5% gewijzigd door Hydra op 29-10-2020 08:08 ]

[Hydra]

dakathefox schreef op woensdag 28 oktober 2020 @ 21:00:
Yep.

https://www.joelonsoftwar...u-should-never-do-part-i/

[Hydra]

johnkeates schreef op woensdag 28 oktober 2020 @ 22:09:
Of hij wel of niet microservices moet maken was de case hier niet lijkt me. Het gaat er om dat het uit te leggen is aan een investeerder.

De TS ja, maar die investeerder heeft helemaal niet de behoefte om te weten wat microservices zijn. De TS probeert simpelweg een investeerder ervan te overtuigen waarom een complete rewrite nodig is. Ten eerste geldt dit natuurlijk, ten tweede betekent dat zelfs als een totale rewrite nodig is (wat bijna nooit het geval is), dit niet betekent dat microservices de oplossing zijn.

Overigens ben ik het wel (deels) met jou en @Hydra eens hoor, maar ik denk zeker niet dat dit de plek is voor die discussie, vooral om dat dit topic goed als referentie (en als zoekresultaat) kan dienen.

Ai. Ik vind dat je daar nogal wat zegt. Dus ik moet, met bijna 20 jaar ervaring als software engineer waarvan zo'n 7 jaar met microservice architecturen, dus maar gewoon dom antwoord geven op iemand als ik zie dat er nogal een grote kans is dat hij dezelfde fout maakt die ik bij zoveel andere bedrijven gezien heb?

Ik denk namelijk dat het voor mensen die op microservices zoeken het veel nuttiger is dat ze een realistisch beeld krijgen van de voors en tegens. Voor een simpel uitleg van microservices kun je ook op Wikipedia terecht.

Bottomline is de keuze voor microservices vooral een organisatorische. Dat een dergelijk besluit kennelijk op het niveau van een enkele developer genomen wordt, voorspeld niet veel goeds.

[technorabilia]

Hydra schreef op donderdag 29 oktober 2020 @ 08:07:
[...]


https://www.joelonsoftwar...u-should-never-do-part-i/

Met 25 jaar software development ervaring kan ik zeggen dat dit artikel nog steeds actueel is en voorlopig nog wel zal blijven. Refactor en re-architecture waar nodig. Maar start from scratch van relevante business applicaties heb ik hele slechte ervaringen mee.

[farlane]

Gomez12 schreef op donderdag 29 oktober 2020 @ 00:08:
[...]
..Heel verhaal...

Dank je voor je betoog. Wat ik er uit haal (correct me if i'm wrong) is dat een microservice een software component is met een public API die, tov een in-process component, verschrikkelijk duur is om aan te roepen.

Vanuit technisch oogpunt zijn er andere mogelijkheden (in-process componenten, out of process componenten met een meer native interface) voor deze de-coupling die *veel* efficienter zijn.

De keuze voor een micro service aanpak moet dus welhaast niet (veel) met techniek te maken hebben, maar meer wat @Hydra aangeeft organisatorische oorzaken hebben. Developers (myself included) zijn gewoon te eigenwijs

Hydra schreef op donderdag 29 oktober 2020 @ 08:00:
[...]
Dat vraag ik me ook af In theorie zou het moeten kunnen: netjes je monoliet in modules opdelen zoals je microservices opdeelt. Bijvoorbeeld door aparte libraries per module tet maken. Maar in de praktijk lukt dit dus gewoon nooit. Ik heb in al die jaren nog nooit gezien (selection bias natuurlijk) dat dit wel lukte. Ik denk dat dit vooral te maken heeft met dat softtware gebouwd wordt door mensen en mensen gemiddeld genomen lui en incompetent zijn Dat brengt je dus naar het voornaamste voordeel van microservices; een relatiief klein stuk software waar alleen een kleine groep mensen voor verantwoordelijk is.

Dan heb ik het goed begrepen

[Voutloos]

Hydra schreef op donderdag 29 oktober 2020 @ 08:06:

Met maar 2 man die aan een systeem werken is er geen enkele reden om voor een microservice architectuur te gaan. Er is geen hard omslagpunt te geven, maar sowieso kun je met 2 man prima samen in een monoliet werken.

Of even los van monoliet vs microservice: Er is niet eens 2 FTE en die beperkte resource zou dan opeens voor een significant deel naar een nieuwe infrastructuur uitdaging moeten gaan?

Even 10 seconde pauze, zodat ik genuanceerd breng...
F*ck dat, zonder onderbouwing waarom t moet is dit gewoon trollen. Ik zou me zelfs zorgen maken als het gesprek met de investeerder überhaupt op gang kwam.

(En serieus: Dit soort reality checks zijn voor topicstarter wat mij betreft de waardevolle reacties. Iedereen kan wel 10 schermen vol schrijven over microservices ofzo, maar een dergelijke keuze leeft niet in een vacuum he.)

[ Voor 13% gewijzigd door Voutloos op 29-10-2020 09:53 ]

[technorabilia]

Over de "dure" aanroep.Ik denk dat je bij applicaties waar een microservices architectuur op zijn plaats is de extra latency geen punt is. Daar profiteer je meer van structuur, schaalbaarheid etc.

En dat de ook wat minder ontwikkelde developer in een microservices architectuur beter binnen de lijntjes blijft dan bij een monoliet. Domweg omdat men technisch wordt gedwongen om binnen de lijntjes te blijven.

Dat gezegd hebbende. Wees terughoudend. Veel applicaties kunnen prima zonder microservices worden gebouwd en zijn dat uiteindelijk beter mee af. Qua applicatie en mensen.

[Yucon]

Kalentum schreef op woensdag 28 oktober 2020 @ 20:08:
Monolith is V&D: alles onder 1 dak. Maar ging failliet. Omdat ze nergens goed in waren. En als je 1 afdeling verbouwt, dan had de rest er last van. Of als het dak lekt, heeft elke afdeling daar last van
Microservices zijn pandjes in een winkelcentrum. Ze werken samen maar kunnen zelf de meest efficiente bedrijfsvoering bepalen.

Dus plaatje laten zien van V&D logo en dat het ten onder gaat. En dan een succesvol winkelcentrum (bv de outlet in Roermond ofzo). Kleiner, flexibeler.

Monolith: dak lekt, kan bv een performance probleem in een backoffice pagina waardoor het aanmaken van een account soms moeizaam gaat.

Microservice: dat performance probleem is geïsoleerd De backoffice kan last hebben maar het winkeltje 'user registration' heeft nergens last van.

V&D heeft jarenlang uitstekend gelopen. Juist omdat dat in de omgeving waar men inzat gewoon wel de juiste oplossing was. Of op z'n minst een die goed genoeg was.

[Hydra]

farlane schreef op donderdag 29 oktober 2020 @ 09:24:
Dank je voor je betoog. Wat ik er uit haal (correct me if i'm wrong) is dat een microservice een software component is met een public API die, tov een in-process component, verschrikkelijk duur is om aan te roepen.

Er zitten nog veel meer aspecten aan die microservices veel lastiger maken.

Je hebt geen transacties meer en dus geen garanties van consistency. Wat je binnen een database met een transactie heel makkelijk kan regelen, is simpelweg onmogelijk met microservices. En meerdere services die een database schema delen, is ook weer een no-go.

Microservices onderling hebben vaak dependencies. En dat kunnen hele ketens zijn. Versioneren van hun publieke API's is enorm belangrijk, maar ook erg lastig. Daar moet je ten eerste bewuste keuzes op maken, maar het is ook nog eens een extra maintenance burden: onze API's moeten we 6 maanden ondersteunen bijvoorbeeld. Doe je dit allemaal niet, dan ga je krijgen dat microservices tegelijkertijd gedeployed moeten worden. En dan heb je geen microservices maar een gedistribueerde monoliet.

Verschillende teams hebben vaak verschillende opvattingen kwa tooling en talen. Het is leuk dat je in princiepe verschillende componenten in verschillende talen kunt schrijven, maar in de praktijk is dat, aangezien je niet Google bent, gewoon een risico. Leuk dat Pietje die service in JavaScript gedaan heeft, maar nu hebben we een of ander belangrijk component dat verder niemand wil onderhouden. Wat? Geen tests? Quell surprise.

Debuggen van microservices is veel lastiger. Je kunt aan een draaiende monoliet een debugger atttachen. Je kunt geen debugger hangen aan 20 microservices. Inzicht krijgen in wat er gebeurt en welke problemen er zijn, betekent dat je drie belangrijke dingen in moet richten: logging, monitoring en metrics. Veel bedrijven doen niet meer dan alleen logging, en komen er dan achter dat ze geen flauw idee hebben waar het probleem zit, als er een probleem optreedt. En dit terwijl het zelfs met alle drie gewoon lastig is. Is je performance ruk vanwege een netwerk issue? Tja.

De meeste mensen komen niet verder dan dat een microservice gewoon via REST een andere microservice aanroept. En die roept weer een ander aan. En weer een ander. Allemaal met blocking connections. Je hebt zo een keten van 5 services die elkaar allemala aanroepen via HTTP. Even buiten reactive programming (wat zelf weer een wespennest is) blokkeer je dus in 5 services 1 worker thread. Helemaal leuk is het als je een circulaire dependency hebt, A calls B, B calls C, C calls A. Je kunt hiermee je eigen workerthreads blokkeren.

En dat is als het goed gaat. Wat als er iets misgaat? De laatste service geeft een exception. Oops. Nou, dan doen we wat de gemiddelde developer doet als je vraagt em dit betrouwbaarder te maken: we doen gewoon retries. Service A retried 3 keer, B ook, C en D ook. Alleen maar omdat bij E de database performance issues heeft. Zien we waar dit heengaat? 3*3*3*3 = 81 tries voor een enkele call.

Ik kan zo nog wel ff doorgaan

Punt is; ik ben an sich een voorstander van microservices in de organisaties waar ik werk, simpelweg omdat er geen andere optie is. Niet omdat het simpeler is. Verre van; Microservices zijn altijd complexer dan een Monoliet. En als je developers hebt die van een Monoliet een puinhoop maken, gaat het met microservices nog heel veel erger worden.

[CodeCaster]

dakathefox schreef op woensdag 28 oktober 2020 @ 21:00:
Het werk wordt niet gestructureerd gedaan, er is ook eigenlijk geen plan van aanpak. Voor mijn gevoel is het gewoon alsof ze de opdracht hebben gekregen 'bouw systeem A maar opnieuw na' en dat hebben ze letterlijk gedaan.

Dat gaan microservices dus ook niet oplossen. Jij lijkt met dit topic aan te komen met "ik heb een oplossing voor een probleem, vertel me hoe ik deze oplossing verkoop", zonder dat je zelf eigenlijk kunt aangeven waarom die oplossing het gegeven probleem oplost.

Al die vergelijkingen met vrachtschepen en "layers" raken, om toch maar in de maritieme terminologie te blijven, kant noch wal. Met microservices komen er een hoop definities bij kijken: welke berichten gaan de services versturen en ontvangen, wie houdt welke staat bij, wie controleert de staat van de services zelf, wat zijn de afhankelijkheden tussen de services, enzovoorts.

Hiermee ga je van communicatie tussen componenten die je compiler tenminste nog kan controleren en afdwingen (de monoliet) naar communicatie tussen losstaande applicaties die, zonder de nodige gedefinieerde kaders, een groot risico loopt te verworden tot een ongeleid projectiel, met het nodige "waarom werkt dit nu weer niet"-puzzelwerk tot gevolg. Heb je een berichtenboek, een ontwerp van welke events welke gevolgen moeten hebben en welke services daarop moeten acteren? En waarom kun je dat ontwerp niet toepassen op één monolithische service?

Waarom denk je, getuige de momenteel aanwezige incompetentie waardoor het je team al niet lukt om een monoliet gestructureerd op te zetten, dat je dat communicatieprobleem tussen je teamleden gaat oplossen met een compleet andere softwarearchitectuur?

De software is momenteel verre van af. Er zal nog een Rest API van scratch ontwikkeld moeten worden en daar gaat ook weer een vracht tijd in zitten. Men heeft verder niet nagedacht over de verdere toekomst van het platform, dus op termijn zal er weer een hele hoop ontwikkeling aan zitten te komen. En dat in een platform waar eigenlijk dus niet over nagedacht is.

Ik heb een semi kant-en-klare oplossing liggen, waarmee ik direct alle zaken rondom security, API's, frontend, backend, services geregeld heb. Dat is minder werk dan de bestaande applicatie nu alsnog geschikt maken.

Dat heb ik met dotnet new webapi ook, maar dan moet je nog "even" de hele business- en datalaag overnemen, en tien tegen één dat die ongeschikt is om via HTTP-calls bestuurd te worden. Een REST-API is niet iets wat je achteraf tegen een systeem aan kwakt, de overige lagen moeten ook op die statelessness voorbereid zijn.

[Hydra]

kraades schreef op donderdag 29 oktober 2020 @ 09:50:
En dat de ook wat minder ontwikkelde developer in een microservices architectuur beter binnen de lijntjes blijft dan bij een monoliet. Domweg omdat men technisch wordt gedwongen om binnen de lijntjes te blijven.

Dat is dus een probleem. Je hebt voor microservices veel betere lead devs / architecten nodig dan voor een monoliet. Als je die eerder ook niet had, lossen microservices niks op.

Met een team dat een monoliet niet voor elkaar krijgt alles herschrijven naar microservices is een slecht idee. Alsin; bedrijf falliet slecht.

[Hydra]

kraades schreef op donderdag 29 oktober 2020 @ 09:18:
Met 25 jaar software development ervaring kan ik zeggen dat dit artikel nog steeds actueel is en voorlopig nog wel zal blijven. Refactor en re-architecture waar nodig. Maar start from scratch van relevante business applicaties heb ik hele slechte ervaringen mee.

Uberhaupt een big-bang rewrite voorstellen is gewoon een sterk staaltje Dunnig-Kruger. Dat artikel gaat volgens mij nooit niet-actueel zijn. Onze industrie beweegt zich in cirkels.

[technorabilia]

@Hydra
Helemaal mee eens. Dat is inderdaad een harde voorwaarde. De gevolgen kunnen anders desastreus zijn.

[Haan]

Ik zal ook even mijn eigen ervaring delen: ik ben de laatste drie jaar bezig geweest met het ombouwen van meerdere monoliet applicaties naar een service-based architectuur. In het begin hadden we het ook over microservices, maar dat is het bij ons niet en dat is ook een fout die volgens mij vaak gemaakt wordt. Je kan wel een monoliet opknippen in losse componenten, maar dat maakt het niet meteen een microservice architectuur. Bij ons hangt er bijvoorbeeld een database onder waar de meeste services van afhankelijk zijn, dus je krijgt nooit services die helemaal onafhankelijk kunnen zijn.

Anyway, dit koste een team van 6 man (dev+test) ongeveer 9 maanden, ongeveer het dubbele van wat we hadden ingeschat. Daarna zijn we nog twee jaar bezig geweest met het fine-tunen van de services en het ooverzetten van minder gebruikte features die niet direct nodig waren. Inderdaad hadden we ook problemen met bijvoorbeeld retries, zoals @Hydra al benoemde, ontbrak het aan circuit breaker logica, waardoor op een gegeven moment een van de services onderuit gehaald werd doordat meerdere andere services teveel retries deden, dat soort dingen.

Om even aan te geven hoeveel werk het kan zijn dus. Het was bij ons qua architectuur dan wel een volledige rewrite, maar de business logica zelf konden we hergebruiken. Uiteindelijk draait de boel nu naar tevredenheid, maar het heeft wel een hoop gekost. We merken nu wel dat de nieuwe architectuur heel veel voordelen heeft op het gebied van onderhoudbaarheid en ontwikkelen van nieuwe features (de monolieten draaien ook nog steeds, dus we kunnen goed vergelijken)

[dakathefox]

Gomez12 schreef op woensdag 28 oktober 2020 @ 21:55:
Weet je wel wat microservices zijn?
Daar bouw je niet met 2 man aan.

Je hoeft mij niet te vertellen wat microservices zijn. Ik werk al een jaar of 7-8 met deze materie en heb meer dan eens grote bedrijven geadviseerd en grote projecten gedaan.

De 2 devs die ik nu heb gaan er zonder meer uit.

[Gomez12]

dakathefox schreef op donderdag 29 oktober 2020 @ 12:59:
[...]
Je hoeft mij niet te vertellen wat microservices zijn. Ik werk al een jaar of 7-8 met deze materie en heb meer dan eens grote bedrijven geadviseerd en grote projecten gedaan.

En in al die jaren heb je het nooit uit hoeven leggen aan een leek, apart...

De 2 devs die ik nu heb gaan er zonder meer uit.

That's the way to do it, nieuwe software, nieuwe mensen, nieuw bedrijf (want het huidige is failliet)

[technorabilia]

Ik ben wel benieuwd naar het type applicatie en de grootte ervan.

Soms verkijk ik mij er wel eens op hoeveel de referentiekaders van elkaar verschillen. Sommigen redeneren vanuit een business applicatie zoals een ERP met duizenden functiepunten en anderen hebben het over een app van een paar honderd regels.

Wat hierboven wordt geschreven blijft natuurlijk gelden maar de applicatie speelt ook een rol. Ik heb hierboven niets over gelezen.

[Gomez12]

kraades schreef op donderdag 29 oktober 2020 @ 14:18:
Ik ben wel benieuwd naar het type applicatie en de grootte ervan.

Soms verkijk ik mij er wel eens op hoeveel de referentiekaders van elkaar verschillen. Sommigen redeneren vanuit een business applicatie zoals een ERP met duizenden functiepunten en anderen hebben het over een app van een paar honderd regels.

Tja, hoe kleiner de app, hoe minder voordelen je gaat hebben van microservices, terwijl je wel alle nadelen ervan blijft behouden (nou ok, stiekem zijn de nadelen zelfs nog iets groter omdat je vanwege allerlei redenen je heel erg veel last last hebt van one in a million bugs met microservices, dan is het wel zo handig als die bug elke minuut optreed omdat je een miljoen acties per minuut verwerkt ipv dat het 1x per 3 maanden is)

[technorabilia]

True, maar een webapp met wat queues en worker roles ziet men ook al snel als een microservices architectuur. Ook een kwestie van referentiekader.

[Kalentum]

Met twee developers valt de infrastructuur die je nodig hebt voor een microservice architectuur al nauwelijks te managen dus ik verwacht geen enorm project

[dakathefox]

Gomez12 schreef op donderdag 29 oktober 2020 @ 13:04:
En in al die jaren heb je het nooit uit hoeven leggen aan een leek, apart...

Vaak genoeg zelfs. Maar dit keer moet ik het aan iemand uitleggen die 80+ is en geen e-mailadres heeft. Dat is echt even andere koek.

[alwinuzz]

dakathefox schreef op woensdag 28 oktober 2020 @ 20:21:
[...]


Het is een applicatie waar uiteindelijk honderden mensen tegelijkertijd in moeten gaan werken. Hij moet daarom schaalbaar zijn bijvoorbeeld. Verder zie je dat er door de jaren heen diverse partijen aan gewerkt hebben, zonder dat er enige helderheid is over wie nou uiteindelijk welke code heeft geschreven. Er is geen duidelijke structuur qua ontwikkeling, een OTAP omgeving is ook niet aanwezig en code staat over al en nergens - zelfs niet in Github.

Dus het is gewoon prutswerk.

dakathefox schreef op woensdag 28 oktober 2020 @ 21:00:
[...]


Ik heb je vragen wel gezien, maar omdat ze niet relevant waren aan mijn vraag heb ik ze in eerste instantie overgeslagen. Mijn vraag ging namelijk over hoe ik het beste een 80-jarige het verschil kon uitleggen. Niet of de keuze voor microservices de heilige graal is. Dat is 'ie niet altijd, maar in dit geval wel.

Met hoeveel man werk je aan het systeem?
Momenteel wordt er met twee man aan het systeem gewerkt. Eén van de developers werkt part-time, alhoewel het meer ad-hoc lijkt te zijn.

Wat zijn de problemen en waarom zou volgens jou 'microservices' hier de oplossing zijn?
Het werk wordt niet gestructureerd gedaan, er is ook eigenlijk geen plan van aanpak. Voor mijn gevoel is het gewoon alsof ze de opdracht hebben gekregen 'bouw systeem A maar opnieuw na' en dat hebben ze letterlijk gedaan.

De software is momenteel verre van af. Er zal nog een Rest API van scratch ontwikkeld moeten worden en daar gaat ook weer een vracht tijd in zitten. Men heeft verder niet nagedacht over de verdere toekomst van het platform, dus op termijn zal er weer een hele hoop ontwikkeling aan zitten te komen. En dat in een platform waar eigenlijk dus niet over nagedacht is.

Ik heb een semi kant-en-klare oplossing liggen, waarmee ik direct alle zaken rondom security, API's, frontend, backend, services geregeld heb. Dat is minder werk dan de bestaande applicatie nu alsnog geschikt maken.

Ik denk dat je meer winst kan halen in een beter proces en infrastructuur, dan in een rewrite met nieuwe architectuur.

Om er nog maar een classic Joel post bij te halen: https://www.joelonsoftwar...-12-steps-to-better-code/
Uit jouw verhaal op te maken, is aan de bovenste 6 vragen volgens mij onvoldoende voldaan.

Ik snap dat gefrustreerd bent over de huidige berg troep. Ik snap niet hoe opsplitsen in specifiek microservices de huidige troep gaat verbeteren. Behalve dan een complete rewrite forceren, wat een enorm risico is. Of je bedoelt iets anders met microservices dan we denken.

De requirements die ik uit bovenstaande info kan halen, zijn allemaal prima haalbaar in bijv. één Asp.net MVC project.

[P_de_B]

Dit artikel is wel mooi: https://m.signalvnoise.com/the-majestic-monolith/


en het doet me ook aan die beroemde quote denken: "if you can't explain it simply you don't understand it well enough"

[ Voor 45% gewijzigd door P_de_B op 29-10-2020 21:15 ]

[gekkie]

dakathefox schreef op donderdag 29 oktober 2020 @ 16:28:
[...]
Vaak genoeg zelfs. Maar dit keer moet ik het aan iemand uitleggen die 80+ is en geen e-mailadres heeft. Dat is echt even andere koek.

Maar in je OP zei je ook dat hij afhaakt als je het complex maakt.
Microservices maken het systeem zelden minder complex, waarom zou hij als investeerder niet afhaken bij jouw voorstel om het om te gaan gooien naar microservices ?

Je leek ook te stellen dat alle afbeeldingen te complex zijn en je iets simpels zoekt.
Ga je deze investeerder dan wellicht niet vals voorlichting aangaande wat microservices zijn en de kosten zowel tijdens implementatie en productie, zolang hij de put maar lekker blijft financieren ?

Mijn gevoel daar in wordt nog wat verstrekt door je sollicitatie topic waarin je ervaring niet op het programmeer vlak lijkt te liggen en je je ook afficieert als "sales-consultant" die zelf "1 miljoen heeft binnengeharkt".

[ Voor 12% gewijzigd door gekkie op 29-10-2020 21:45 ]

[GrooV]

Een volledige rewrite en een nieuw team neer zetten is niet vaak het beste advies in een bestaande situatie. Helemaal met kant en klare producten kom je vaak snel van een koude kermis thuis.

Ik kan niet naar de code kijken maar een hoop is natuurlijk redelijk snel op te lossen. Honderden concurrent gebruikers is natuurlijk helemaal niets. OTAP omgevingen zijn ook zo opgezet (die moet je ook opzetten in veelvoud voor microservices) net zoals code in een git repo incl CI zetten. Dan ga je daarna grof refactoren of delen herbouwen in (micro)services

Als jij een 80+ jarige wil overtuigen zal je moeten kunnen aantonen dat je daadwerkelijk waarde aan het proces gaat toevoegen. Wat gaat dit hem opleveren nadat hij een bak met geld heeft uitgegeven? Technisch/inhoudelijk zal het hem een worst wezen. Hoe ga je afscheid nemen van de huidige teamleden? Werken die er al lang of zijn ze extern?

[Hydra]

gekkie schreef op donderdag 29 oktober 2020 @ 21:33:
Mijn gevoel daar in wordt nog wat verstrekt door je sollicitatie topic waarin je ervaring niet op het programmeer vlak lijkt te liggen en je je ook afficieert als "sales-consultant" die zelf "1 miljoen heeft binnengeharkt".

For fucks sake... Echt? Tja. Dit is ook een manier om "ervaring met microservices" op je CV te krijgen.

[ Voor 9% gewijzigd door Hydra op 30-10-2020 11:16 ]

[Gomez12]

Hydra schreef op vrijdag 30 oktober 2020 @ 11:14:
[...]


For fucks sake... Echt? Tja. Dit is ook een manier om "ervaring met microservices" op je CV te krijgen.

Ik zat meer te denken dat 2 man eruit gewoon voor het bedrijf al snel 2 ton personeelskosten scheelt, geen extra fouten die ze kunnen maken scheelt over het hele bedrijf ook al snel x ton productiviteits verlies.

Oftewel zolang hij volgend jaar niet te veel uitgeeft en je geen waarde hangt aan de wel positieve dingen die de programmeurs opleverden dan ben is hij al hard op weg naar een half miljoen bespaard bij dit bedrijf.

Maar @dakathefox begrijp ik het goed uit je sollicitatie topic dat je nog niet eens 2 maanden bij dit bedrijf werkt?

[gekkie]

Hydra schreef op vrijdag 30 oktober 2020 @ 11:14:
[...]
For fucks sake... Echt? Tja. Dit is ook een manier om "ervaring met microservices" op je CV te krijgen.

Ik vond de wijze van argumenteren der mate afwijkend dat ik het niet kon laten toch even de posthistorie er op na te slaan en toen kwam ik al gauw: dakathefox in "Solliciteren moet je leren" tegen. Het verhaal al daar komt niet op mij over als een "bescheiden architect met appreciatie voor de haken en ogen die aan elke techniek en keuze daarvan kleven" zullen we maar zeggen.

[Ed Vertijsment]

Ten eerste, dit topic gaat een beetje van hoe verkoop ik een microservice architectuur naar de voor- en nadelen van microservices. Eerst het eerste:

Het is al eerder aangegeven maar een microservice architectuur hoef je mijn inziens niet te verkopen. Wat je wilt verkopen is arbeidstijd (uren) voor een grondige refactorslag. Waarom zou de aandeelhouder dat willen kopen, Wat levert het hem op? Het antwoord is denk ik stabiliteit en zekerheid en efficiëntie. Ik zou het dus proberen te verkopen als groot onderhoud aan de fundering van een gebouw of iets dergelijks.

Dat gezegd hebbende heb ook ik mijn twijfels aan de noodzaak en meerwaarde van een microservice architectuur, ik vermoed dat je product duurder en langzamer gaat werken. De refactor zal wel het project werkbaarder maken maar dat gaat ook gebeuren met een monolitische architectuur, simpel weg omdat je het opnieuw aanvliegt met vernieuwde inzichten.

Uit het topic haal ik het volgende:

Middelgrote applicatie

quote: https://gathering.tweaker...message/64413720#64413720

Het is een applicatie waar uiteindelijk honderden mensen tegelijkertijd in moeten gaan werken

Klein team

quote: https://gathering.tweaker...message/64414304#64414304

Momenteel wordt er met twee man aan het systeem gewerkt

"Honderden mense tegelijkertijd" is een beetje abstract, maar laten we voor het gemak 999 simultane gebruikers nemen. Een beetje server doet 300 gebruikers tegelijkertijd, hebt dus dan 3 servers nodig, een load balancer en een database server.

Je zou dit dus uit kunnen leggen als een microservice architectuur met de volgende services:

• Load balancer
• Applicatie
• Database

Je zou het ook uit kunnen leggen als een server cluster maar goed. Houd er nu rekening mee dat je dus daarmee in plaats van 1, 3 projecten moet onderhouden + de infrastructuur ertussen. Maar gegeven wat ik van het project denk te weten verwacht ik dat dit een redelijke setup is. Maar dit zijn geen microservices.

Als je dit verder gaat opsplitsen ga je lichtere individuele nodes krijgen die allemaal op elkaar gaan zitten wachten en minder capaciteit hebben op pieken op te vangen. Je applicatie wordt dus trager en complexer. Zonder overduidelijk voordeel.

Microservices zijn een goed migratiedoel als je specifieke dingen dynamisch wilt kunnen schalen voor specifieke piekmomenten maar het is IMO geen goed idee om er vanaf de start mee te beginnen. ook niet als refactor. Daarnasst mis je de noodzaak en de mankracht in mijn ogen.

[dakathefox]

gekkie schreef op donderdag 29 oktober 2020 @ 21:33:
Maar in je OP zei je ook dat hij afhaakt als je het complex maakt.
Microservices maken het systeem zelden minder complex, waarom zou hij als investeerder niet afhaken bij jouw voorstel om het om te gaan gooien naar microservices ?

Vraag is niet relevant in deze.

gekkie schreef op donderdag 29 oktober 2020 @ 21:33:
Ga je deze investeerder dan wellicht niet vals voorlichting aangaande wat microservices zijn en de kosten zowel tijdens implementatie en productie, zolang hij de put maar lekker blijft financieren ?

Nee, zeker niet. Deze investeerder wil ik er juist uit hebben. Hij is de materie niet machtig en dat is precies de reden waarom de organisatie nu zit waar ze zitten. En dat is gewoon een applicatie uit het jaar kruik, geschreven door een stel loodgieters en na al die tonnen nog steeds niet klaar. Ik stel een frisse start voor, een andere aanpak en met een investeerder die de techniek zal gaan leveren.

Mijn gevoel daar in wordt nog wat verstrekt door je sollicitatie topic waarin je ervaring niet op het programmeer vlak lijkt te liggen en je je ook afficieert als "sales-consultant" die zelf "1 miljoen heeft binnengeharkt".

Je gevoel is kapot in deze.

[dakathefox]

Bedankt voor alle feedback. Het is me gelukt om de terminologie 'microservices' op een eenvoudige manier weer te geven en wel dusdanig dat iedereen aan tafel het zou moeten snappen.

Alle andere feedback over het nut van microservices, hoeveel ton je kunt besparen door 2 FTE eruit te gooien, etc, etc... Bedankt, maar dat was niet waar ik naar op zoek was.

[gekkie]

dakathefox schreef op vrijdag 30 oktober 2020 @ 19:40:
Bedankt voor alle feedback. Het is me gelukt om de terminologie 'microservices' op een eenvoudige manier weer te geven en wel dusdanig dat iedereen aan tafel het zou moeten snappen.

Dan neem ik aan dat je dan als feedback ook iets terug kunt geven. En dus weer kunt geven hoe je dat gedaan hebt ter leering ende vermaeck voor iedereen die heeft bijgedragen mochten zijn in de toekomst met een soortgelijk bijltje moeten hakken ?

[Flapmo]

In Solliciteren moet je leren geef je aan dat je project manager en sales manager/consultant bent. Zou je deze keus niet overlaten aan een geschikter persoon?

Kan informatie uit andere topic niet helemaal rijmen met jouw houding hier. Maar ach, ziet er uit dat je geholpen bent dus succes!

FWIW @johnkeates leuk verhaal. Nog niet eerder gezien.

[ Voor 17% gewijzigd door Flapmo op 30-10-2020 20:20 ]

[sig69]

Ed Vertijsment schreef op vrijdag 30 oktober 2020 @ 19:27:
Een beetje server doet 300 gebruikers tegelijkertijd,

Dat slaat echt helemaal nergens op. Je weet helemaal niets van de software of hardware. Of heb ik een memo gemist dat 300 de max is?

[Ed Vertijsment]

sig69 schreef op vrijdag 30 oktober 2020 @ 20:17:
[...]

Dat slaat echt helemaal nergens op. Je weet helemaal niets van de software of hardware. Of heb ik een memo gemist dat 300 de max is?

Dat is over het algemeen iets wat als haalbaar kan worden beschouwd voor de meeste software, sure bepaalde loads doen 200, andere 400. Andere nog meer.

Punt is dat je met een paar servers af kan.

[ Voor 7% gewijzigd door Ed Vertijsment op 30-10-2020 20:37 ]

[sig69]

Ed Vertijsment schreef op vrijdag 30 oktober 2020 @ 20:36:
[...]


Dat is over het algemeen iets wat als haalbaar kan worden beschouwd voor de meeste software

Wie zegt dat? Is dat gemeten door iemand? Als je zo'n uitspraak doet zou ik graag onderbouwing zien.

[Tsurany]

Ed Vertijsment schreef op vrijdag 30 oktober 2020 @ 20:36:
[...]


Dat is over het algemeen iets wat als haalbaar kan worden beschouwd voor de meeste software, sure bepaalde loads doen 200, andere 400. Andere nog meer.

Punt is dat je met een paar servers af kan.

Daar is gewoon niks zinnigs over te zeggen zonder meer details. Met een moderne front-end en lichtgewicht API's kan dat zomaar een heel stuk meer worden. Met enorm veel server side berekeningen en data manipulaties kan dat een heel stuk minder worden.

Zulke uitspraken slaan gewoon nergens op.

[Voutloos]

Performance maakt ook niet uit, de code wordt vervangen, de developers moeten weg, de investeerder moet inmiddels ook vervangen..
Dan is hardware vervangen misschien nog wel de eenvoudigste stap...

(Maar dat soort getallen gaan nergens over inderdaad. Bij ons zijn er componenten met enkele (!) gebruikers per server, maar ook componenten met duizenden per server. Meerdere ordes grootte van verschil dus. Schatten zonder context gaat hem niet worden)

[ Voor 39% gewijzigd door Voutloos op 31-10-2020 08:49 ]

[Jrz]

dakathefox schreef op woensdag 28 oktober 2020 @ 21:00:
[...]

Met hoeveel man werk je aan het systeem?
Momenteel wordt er met twee man aan het systeem gewerkt. Eén van de developers werkt part-time, alhoewel het meer ad-hoc lijkt te zijn.

Wat zijn de problemen en waarom zou volgens jou 'microservices' hier de oplossing zijn?
Het werk wordt niet gestructureerd gedaan, er is ook eigenlijk geen plan van aanpak. Voor mijn gevoel is het gewoon alsof ze de opdracht hebben gekregen 'bouw systeem A maar opnieuw na' en dat hebben ze letterlijk gedaan.

Klinkt als gedoemd te falen. Microservices is handig wanneer een onderdeel of service bij een compleet onafhankelijk team ligt. Dat is bij jou niet zo.

Als uitleg: zie onze applicatie als een bedrijf met meerdere takken. In de loop der tijd is ons bedrijf zo hard gegroeid, en is elke tak eigenlijk een volwaardig bedrijf.
Hierdoor is het niet goed te overzien, en zijn de grenzen van elk bedrijf niet duidelijk meer. We willen de bedrijven gaan afsplitsen. Het voordeel hiervan is dat de verantwoordelijkheden van deze bedrijven duidelijker is, en dat de directeuren bepalen wat voor producten en dientsten worden gemaakt. Zij zijn expert op hun gebied, en eventueel zouden externe bedrijven ook klant kunnen worden.
Maar dit is ook het nadeel: elk bedrijfje heeft zijn eigen structuur. Eigen management, ontwikkelaars etc. Dat kost dus meer resources. En doordat de lijntjes niet meer zo kort zijn (het zijn losse bedrijven) kunnen veranderingen niet snel worden doorgevoerd.

Dus: vind u ook dat we zo hard zijn gegroeid, en dat het verstandig is deze, deze en deze afdelingen op te splitsen en daar in te investeren?

[Hydra]

Ed Vertijsment schreef op vrijdag 30 oktober 2020 @ 20:36:
Dat is over het algemeen iets wat als haalbaar kan worden beschouwd voor de meeste software, sure bepaalde loads doen 200, andere 400. Andere nog meer.

Het is in deze context echt gewoon complete larie. Sowieso in microservice architecturen reken je sowieso niet met "aantallen gebruikers". Je hebt te maken met een gemiddeld en piek aantal transacties per seconde. En daar moet je dus rekening mee houden bij het ontwikkelen van zowel de individuele services als de architectuur in z'n geheel.

Daar is het dus vooral de kunst bottlenecks te identificeren. Een van onze services bijvoorbeeld werkt volledig stateless en vanuit het geheugen omdat het processen met een piek van rond de 2000 transacties per seconde moet ondersteunen. En dat komt van 1 'gebruiker'; een andere service.

Er zijn monolitische applicaties die echt wel heel veel meer dan 300 simultane gebruikers serveren. Heck; ik heb echt heel lang geleden voor D-Reizen werk gedaan en daar werd in de piek alles gedaan door 3 application servers waarbij het zo opgezet was dat 2 van de 3 alle load aankunnen. En dat is dus wel echt heel wat meer dan 300 gebruikers per server. Je zit er zo een factor 100 naast.

[ Voor 19% gewijzigd door Hydra op 31-10-2020 10:00 ]

[Hydra]

dakathefox schreef op vrijdag 30 oktober 2020 @ 19:37:
Nee, zeker niet. Deze investeerder wil ik er juist uit hebben.

Mooi verhaal man.

[Flapmo]

Als je de investeerder er toch uit wilt hebben dan zeg je hem toch gewoon dat je gaat doen wat je zelf het beste acht en als het hem niet bevalt dat hij niet hoeft te investeren .

offtopic:
Hier stond een lap tekst maar eigenlijk kan je er weinig over zeggen. Te weinig informatie dus alle discussie gaat over het schetsen van een mogelijke situatie die je dan beantwoord met je eigen gedachten .

.

[ Voor 121% gewijzigd door Flapmo op 31-10-2020 13:27 ]

[Ed Vertijsment]

Hydra schreef op zaterdag 31 oktober 2020 @ 09:55:
[...]


Het is in deze context echt gewoon complete larie. Sowieso in microservice architecturen reken je sowieso niet met "aantallen gebruikers". Je hebt te maken met een gemiddeld en piek aantal transacties per seconde. En daar moet je dus rekening mee houden bij het ontwikkelen van zowel de individuele services als de architectuur in z'n geheel.

Klopt, ik had het ook over een cluster setup en niet over een microservice setup. Ik heb ook aangegeven dat het exacte aantal uiteraard afwijkt maar dat is niet het punt. Punt is dat "honderden gebruikers" geen reden geeft voor een microservice setup. Dat kun je prima aan met een paar dikke machines.

Hydra schreef op zaterdag 31 oktober 2020 @ 09:55:Er zijn monolitische applicaties die echt wel heel veel meer dan 300 simultane gebruikers serveren. Heck; ik heb echt heel lang geleden voor D-Reizen werk gedaan en daar werd in de piek alles gedaan door 3 application servers waarbij het zo opgezet was dat 2 van de 3 alle load aankunnen. En dat is dus wel echt heel wat meer dan 300 gebruikers per server. Je zit er zo een factor 100 naast.

Ik heb ook niet gezegd dat meer niet haalbaars is, maar dat 300 in de meeste gevallen WEL haalbaar moet zijn (minimum). Ik werk ook aan een project met een miljoenenpubliek die op 2 webservers en een db server draait welke ook prima op 1 webserver draait. Werkt prima, maar als een applicatie veel minder dan 300 simultane gebruikers aankan gaan we bottlenecks zoeken en oplossen.

[Hydra]

Ed Vertijsment schreef op zaterdag 31 oktober 2020 @ 11:37:
Ik heb ook niet gezegd dat meer niet haalbaars is, maar dat 300 in de meeste gevallen WEL haalbaar moet zijn (minimum). Ik werk ook aan een project met een miljoenenpubliek die op 2 webservers en een db server draait welke ook prima op 1 webserver draait. Werkt prima, maar als een applicatie veel minder dan 300 simultane gebruikers aankan gaan we bottlenecks zoeken en oplossen.

Het punt is; die 300 is volledig arbitrair. Het is volkomen afhankelijk van wat er onderwater gebeurt. M'n raspberry pi zero kan 300 users aan als HTML serveren alles is wat 'ie moet doen. Als je gewoon een applicatie bouwt zonder vooraf over schaling na te denken (of dat nu 30 of 3 miljoen gebruikers is), dan heb je een flink probleem.

Als die applicatie waar je het over hebt maar 30 gebruikers aan moet kunnen (en nogmaals; de term 'gebruikers' is zo nietszeggend dat ik hem echt in jaren niet in die context gebruikt heb, we hebben het algemeen over transacties of events) is tijd besteden aan een theoretische 300 natuurlijk tijdsverspilling. Als hij aan de andere kant 3000 aan moet kunnen en je komt er dan pas achter dat je op 300 max zit, moet je je software architect misschien voor een niet incompetente inwisselen

[Hydra]

Flapmo schreef op zaterdag 31 oktober 2020 @ 11:23:
• 2 software devs voor een service met honderden gebruikers klinkt niet heel reëel. Met honderden gebruikers tegelijkertijd heb je 1000(0)en gebruikers in totaal. Daar moet je toch meer marge op hebben dan 2 software devs (in NL 250-300K). Doe jezelf een plezier en vraag minstens 5(-10) man voor zo'n service zodat je een goed team neer kan zetten. Software is je key product, niet iets wat je ook nog even erbij doet voor zo weinig mogelijk geld. (Al is dit gissen voor dit topic want je moet wel de omzet hebben natuurlijk om dit te kunnen bekostigen. Ga iig geen absurde uitdagingen aan, zal je niet helpen).
[/list]

Hier ben ik het echt niet mee eens. Zoals eerder gezegd; aantallen gebruikers zegt niks. Mijn blog heeft duizenden 'gebruikers'.

Hoeveel developers met welk ervaringsniveau je nodig hebt, is afhankelijk van de complexiteit van het systeem afgezet tegen hoe snel de ontwikkelingen moeten gaan. De hoeveelheid gebruikers heeft echt geen enkele relatie hiermee. Sterker nog; dit is een voorbeeld waarbij je vaak veel beter af bent met 1 ervaren develper dan 10 onervaren devs.

[Ed Vertijsment]

Hydra schreef op zaterdag 31 oktober 2020 @ 11:45:
[...]


Het punt is; die 300 is volledig arbitrair. Het is volkomen afhankelijk van wat er onderwater gebeurt. M'n raspberry pi zero kan 300 users aan als HTML serveren alles is wat 'ie moet doen. Als je gewoon een applicatie bouwt zonder vooraf over schaling na te denken (of dat nu 30 of 3 miljoen gebruikers is), dan heb je een flink probleem.

Klopt, maar zonder verdere kennis van de applicatie en aangenomen dat het op servers draait en niet op raspberry pi's en aangenomen dat de applicatie meer omvat dan een puur statische frontend is het denk ik een redelijk startpunt.

Hydra schreef op zaterdag 31 oktober 2020 @ 11:45:
[...]
Als die applicatie waar je het over hebt maar 30 gebruikers aan moet kunnen (en nogmaals; de term 'gebruikers' is zo nietszeggend dat ik hem echt in jaren niet in die context gebruikt heb, we hebben het algemeen over transacties of events) is tijd besteden aan een theoretische 300 natuurlijk tijdsverspilling.

True, maar we weten simpelweg niet meer dan het aantal gebruikers. Ik ga ook geen exacte setup/aantallen voorschrijven maar verwacht, tenzij er een hele bijzondere unieke workload™ is microservices niet nodig zijn en dat je prima af kunt met X applicatieservers die elk N gebruikers/transacties/events doen.

Het is al eerder gezegd maar je gaat dan waarschijnlijk met microservices wel de nadelen maar niet de voordelen van microservices krijgen.

Hydra schreef op zaterdag 31 oktober 2020 @ 11:45:
[...]
Als hij aan de andere kant 3000 aan moet kunnen en je komt er dan pas achter dat je op 300 max zit, moet je je software architect misschien voor een niet incompetente inwisselen

True

[Flapmo]

Hydra schreef op zaterdag 31 oktober 2020 @ 12:00:
[...]


Hier ben ik het echt niet mee eens. Zoals eerder gezegd; aantallen gebruikers zegt niks. Mijn blog heeft duizenden 'gebruikers'.

Hoeveel developers met welk ervaringsniveau je nodig hebt, is afhankelijk van de complexiteit van het systeem afgezet tegen hoe snel de ontwikkelingen moeten gaan. De hoeveelheid gebruikers heeft echt geen enkele relatie hiermee. Sterker nog; dit is een voorbeeld waarbij je vaak veel beter af bent met 1 ervaren develper dan 10 onervaren devs.

Goed punt. Ik ging er inderdaad teveel vanuit dat het wat complexere software was gezien hij het had over "tegelijkertijd in werken" en microservices "echt nodig waren". Na nog eens even nadenken; je kan er eigenlijk helemaal niets over zeggen zonder zelf eerst een mooie situatie te schetsen en je eigen vraag te beantwoorden . Bovenstaande reactie ook maar aangepast.

[ Voor 29% gewijzigd door Flapmo op 31-10-2020 13:29 ]