Micro-servers en gedistribueerde data

[SymbolicFrank]

Is dat hier al voorbij gekomen?

SQL-databases schalen slecht en zijn moeilijk te distribueren. Je krijgt dan al snel no-sql databases, die vooral platte tabellen met sleutels en waardes opslaan. Maar als je daarop selecties wilt draaien, moet je iedere keer een heleboel data over de lijn trekken. Het is daarom eenvoudiger om voor iedere selectie een aparte server te maken.

Dan zit je met verschillenden dingen. Om te beginnen, als je er een aparte IIS of Apache server met zijn eigen SQL-database voor gebruikt, nemen ze veel ruimte en capaciteit in beslag. Maar dat hoeft natuurlijk niet. Het is heel eenvoudig om je eigen, unieke protocol te gebruiken en aan een poort te hangen. En als het absoluut HTTP moet zijn, kun je in C# bijvoorbeeld een HttpListener gebruiken.

Daarna zit je met de distributie en de beveiliging. SSL zegt bijvoorbeeld niets over de identiteit als je geen certificaten gebruikt. En om nou iedere micro-server zijn eigen certificaat te geven gaat wel erg ver. Ook is dat een vrij zware versleuteling die niet eenvoudig zelf te bouwen is.

En je wil waarschijnlijk die dingen "on-demand" kunnen opstarten. Het is het mooiste als ze zelf schalen: je verzoekt de hoofd-server om een bepaalde service, die controleert je identiteit en geeft je de sleutel en het adres van de server. Als die service nog niet actief is of de belasting te hoog is, start hij een nieuwe, met zijn eigen adres (minimaal een ander poortnummer). En als die service een tijdje geen aanvragen krijgt, geeft hij dat door aan de hoofd-server en sluit zichzelf af. Je moet natuurlijk ook iets inbouwen waardoor je kunt controleren of ze nog actief zijn.

Ik heb zoiets een paar keer gebouwd en vroeg me af of er meer mensen mee bezig zijn, en of hier al een kant en klare oplossing voor bestaat.

[hellum]

Ik snap het probleem niet helemaal. Je kunt toch gewoon 1 grote SQL database neerzetten waar alle clients mee praten? Zou ook nog mogelijk zijn om een SQL database as a service te doen bij bijvoorbeeld Azure, die kun je echt laten schalen.

Als het binnen je eigen netwerkt blijft hoef je tussen de servers helemaal geen SSL certificaten te hebben. Je kunt 1 server inrichten als loadbalancer waar al het verkeer op binnenkomt, waarna het naar de juiste server gerouteerd wordt.

[McKaamos]

Even uit de theorie, ben echt geen kenner van hoe het precies in elkaar steekt, maar volgens mij praat je hier over twee dingen die los staan van elkaar.

Opspinnen van extra nodes op basis van load is waar Docker o.a. voor uitgevonden is toch? of K8S?
En in Docker kan je gewoon wat variables mee geven bij het opspinnen, dus een certificaatje genereren om de identiteit te bepalen en die dan mee geven mag ook geen issue zijn.
Maak je die certificaatjes op basis van een root certificate, dan heb je volgens mij ook geen issue met het distribueren van de public-key van dat nieuwe certificaat, want je kan gewoon checken m.b.v. het root certificate.
Daarbij zijn docker images relatief klein, gezien die alleen de specifieke applicatie bevatten en de daarbij behorende configuratie. Geen hele VM die je hoeft te genereren en starten.

Ik weet verder niet wat voor data het om gaat, maar als het persé SQL moet zijn, kan je dan iets met 'eventual consistency'? Dat doen partijen als Youtube en Twitter met counters en comments.
Zie ook: https://www.youtube.com/watch?v=RY_2gElt3SA
Kort gezegd: je hebt een master SQL server (of cluster, of meerdere) en een aantal kleinere cache servers achter een loadbalancer die de front-end bedienen. Ze tellen ieder voor zich de views en raporteren eens per X tijd terug aan de master, zodat die niet overloaded raakt.

En anders, misschien is er een alternatief voor het gebruik van SQL? Moet de data persé in een relationele database staan? Mag het ook iets anders zijn wat beter schaalt?

[The Eagle]

Beveiliging kan op vele manieren. Ssl tussen servers hoeft wellicht technisch miet, maar kan wel een vereiste zijn vanuit beleid natuurlijk.

---

"SQL-databases schalen slecht en zijn moeilijk te distribueren"
Das nogal een boude stelling. Schalen alle SQL DB's slecht? En wat definieer jij als slecht? En zoek je naar horizontale of verticale schaling?
Als ik naar RDBMS'en kijk: SQL server en Oracle schalen prima, zowel horizontaal als verticaal. En dat zijn wel de meest gebruikte smaken eigenlijk.

NoSQL kent natuurlijk ook vele smaken, om die nou over 1 kam te scheren.... En dan zijn er nog gedistribueerde platformen als Cassandra, Hbase en Kudu icm Impala. Heeft ook allemaal zijn toepassing.

Veel data over de lijn trekken hoeft totaal geen issue te zijn. Ja, in een hobbyomgeving misschien. Maar cloudbased of op bedrijfsniveau met een >10Gbit backbone: echt niet.

Het probleem van RDBMS'en icm distributie is meer de toepassing (OLTP) en de ACID compliancy die daar bij komt kijken. Having said that: een database van 10TB op een enkele compute instance mag tegenwoordig geen enkel probleem meer zijn. En daarboven ben je toch hele andere dingen met je datasets aan het doen, en kom je al snel in de wereld van Hadoop en co terecht.

Wil je met microservices werken, check dan even bij https://robin.io/solutions/technology/databases/

[SymbolicFrank]

McKaamos schreef op donderdag 27 augustus 2020 @ 17:16:
Even uit de theorie, ben echt geen kenner van hoe het precies in elkaar steekt, maar volgens mij praat je hier over twee dingen die los staan van elkaar.

Opspinnen van extra nodes op basis van load is waar Docker o.a. voor uitgevonden is toch? of K8S?
En in Docker kan je gewoon wat variables mee geven bij het opspinnen, dus een certificaatje genereren om de identiteit te bepalen en die dan mee geven mag ook geen issue zijn.
Maak je die certificaatjes op basis van een root certificate, dan heb je volgens mij ook geen issue met het distribueren van de public-key van dat nieuwe certificaat, want je kan gewoon checken m.b.v. het root certificate.
Daarbij zijn docker images relatief klein, gezien die alleen de specifieke applicatie bevatten en de daarbij behorende configuratie. Geen hele VM die je hoeft te genereren en starten.

Dat klopt. Maar het hangt er maar van af wat je wilt doen. Docker is leuk als je bijvoorbeeld allemaal vergelijkbare dingen wilt doen, die liefst allemaal op dezelfde opslag staan. Zodat je er 1 af kan halen en op een server kunt zetten die nog ruimte heeft.

Als je het snel wilt kunnen benaderen kun je het beste geen database gebruiken en het gewoon in het geheugen houden. Dat is ook goed te distribueren. Bijvoorbeeld een postcode database. Dat is een paar gigabyte, maar die wijzigt zelden en een snelle index (die je in het geheugen wilt hebben) is al gauw net zo groot als de data zelf.

Of het benaderen van speciale hardware, zoals een server vol met videokaarten waarop een neuraal netwerk draait.

Als je alles opsplitst in losse functies die allemaal andere eisen hebben, dan kun je er beter allemaal native applicaties van maken en die rechtstreeks op een beschikbare server draaien. Dan heb je veel minder overhead.

En als het geen HTTP is, dan hoef je ook niet automatisch SSL en een certificaat te gebruiken. Sommige services blijven binnen het netwerk, andere zijn publiekelijk toegankelijk, voor weer andere wil je wel authenticatie (RSA of zo) maar hoeft het resultaat niet versleuteld te worden, enzovoorts.

Ik weet verder niet wat voor data het om gaat, maar als het persé SQL moet zijn, kan je dan iets met 'eventual consistency'? Dat doen partijen als Youtube en Twitter met counters en comments.
Zie ook: https://www.youtube.com/watch?v=RY_2gElt3SA
Kort gezegd: je hebt een master SQL server (of cluster, of meerdere) en een aantal kleinere cache servers achter een loadbalancer die de front-end bedienen. Ze tellen ieder voor zich de views en raporteren eens per X tijd terug aan de master, zodat die niet overloaded raakt.

En anders, misschien is er een alternatief voor het gebruik van SQL? Moet de data persé in een relationele database staan? Mag het ook iets anders zijn wat beter schaalt?

Youtube en Twitter hebben een miljard gebruikers die allemaal tegelijkertijd dezelfde acties kunnen uitvoeren. Die gaan bijvoorbeeld ook zo weinig mogelijk opslaan op schijf. Ze zorgen er gewoon voor dat er overal per wereld een paar servers zijn die die gegevens in hun geheugen hebben zitten. En die hebben ook overal van dat soort unieke services draaien. Een SQL database is veel te inefficiënt. Of een webserver voor de speciale functies.

Zoiets, dus. Maar dan wat eenvoudiger.

[SymbolicFrank]

The Eagle schreef op donderdag 27 augustus 2020 @ 17:18:
"SQL-databases schalen slecht en zijn moeilijk te distribueren"
Das nogal een boude stelling. Schalen alle SQL DB's slecht? En wat definieer jij als slecht? En zoek je naar horizontale of verticale schaling?
Als ik naar RDBMS'en kijk: SQL server en Oracle schalen prima, zowel horizontaal als verticaal. En dat zijn wel de meest gebruikte smaken eigenlijk.

Schalen is zowel distributie als replicatie: in stukken hakken en die stukken synchroniseren. Als je een hele grote database wilt waar veel gebruikers bij kunnen , heb je minimaal een hele grote, gedeelde opslag nodig. En als die gebruikers er ook naar schrijven, het liefste ook een hele grote server. Want anders moet je bij een schrijfactie minimaal tegen de andere servers zeggen dat ze hun cache moeten flushen, of (als je ook de opslag distribueert) moet je alle writes doorsturen naar alle servers en loop je achter de feiten aan.

NoSQL kent natuurlijk ook vele smaken, om die nou over 1 kam te scheren.... En dan zijn er nog gedistribueerde platformen als Cassandra, Hbase en Kudu icm Impala. Heeft ook allemaal zijn toepassing.

Veel data over de lijn trekken hoeft totaal geen issue te zijn. Ja, in een hobbyomgeving misschien. Maar cloudbased of op bedrijfsniveau met een >10Gbit backbone: echt niet.

Het probleem van RDBMS'en icm distributie is meer de toepassing (OLTP) en de ACID compliancy die daar bij komt kijken. Having said that: een database van 10TB op een enkele compute instance mag tegenwoordig geen enkel probleem meer zijn. En daarboven ben je toch hele andere dingen met je datasets aan het doen, en kom je al snel in de wereld van Hadoop en co terecht.

Het kan wel, maar er hangt ook een prijskaartje aan. En veel grote bedrijven staan er helemaal niet om te springen om al hun data zomaar uit handen te geven, als ze dat al mogen (wet op de privacy en zo). Die hebben liever hun eigen servers. En als alles op 1 locatie staat, valt het ook makkelijker om als er wat fout gaat met bijvoorbeeld hun internet verbinding.

Wil je met microservices werken, check dan even bij https://robin.io/solutions/technology/databases/

Dat zal ik doen.

[Woy]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 16:16:
SQL-databases schalen slecht en zijn moeilijk te distribueren.

Dat is erg afhankelijk van welke database je gebruikt en wat je wensen zijn. Het is veel te kort door de bocht om dat zo algemeen te stellen.

Je krijgt dan al snel no-sql databases, die vooral platte tabellen met sleutels en waardes opslaan.

Dat is ook veel te kort door de bocht. Je hebt legio verschillende type databases, elke heeft zo zijn sterke en minder sterke kanten.

Maar als je daarop selecties wilt draaien, moet je iedere keer een heleboel data over de lijn trekken. Het is daarom eenvoudiger om voor iedere selectie een aparte server te maken.

Ik zie niet in waarom je voor iedere selectie een aparte server zou willen hebben. Soms zul je inderdaad wel data redundant opslaan/bewaren voor performance doeleinden, maar dat is bij een oplossing met een RDBMS niet anders.

Dan zit je met verschillenden dingen. Om te beginnen, als je er een aparte IIS of Apache server met zijn eigen SQL-database voor gebruikt, nemen ze veel ruimte en capaciteit in beslag.

Ik zie de relatie tussen een webserver en een DB server niet zo. Je kunt prima meerdere applicatieservers met een DB server laten praten, of een enkele applicatieserver met met meerdere DB servers.

Maar dat hoeft natuurlijk niet. Het is heel eenvoudig om je eigen, unieke protocol te gebruiken en aan een poort te hangen. En als het absoluut HTTP moet zijn, kun je in C# bijvoorbeeld een HttpListener gebruiken.

Waarom zou je over je eigen unieke protocol nadenken. Zo goed als de hele wereld draait bovenop het HTTP protocol. Natuurlijk zijn er ook gevallen waar een low-level TCP protocol voorkeur behoeft, maar ik zie niet in hoe dat met micro-services of gedistribueerde data te maken heeft.

Daarna zit je met de distributie en de beveiliging. SSL zegt bijvoorbeeld niets over de identiteit als je geen certificaten gebruikt.

Daarvoor gebruik je natuurlijk gewoon iets als OpenID connect, of een andere vorm van proven authenticatie/authorisatie.

En om nou iedere micro-server zijn eigen certificaat te geven gaat wel erg ver. Ook is dat een vrij zware versleuteling die niet eenvoudig zelf te bouwen is.

Wat is het probleem van elke server/service zijn eigen certificaat geven? En hoezo zou je versleuteling zelf gaan bouwen?

En je wil waarschijnlijk die dingen "on-demand" kunnen opstarten. Het is het mooiste als ze zelf schalen: je verzoekt de hoofd-server om een bepaalde service, die controleert je identiteit en geeft je de sleutel en het adres van de server. Als die service nog niet actief is of de belasting te hoog is, start hij een nieuwe, met zijn eigen adres (minimaal een ander poortnummer). En als die service een tijdje geen aanvragen krijgt, geeft hij dat door aan de hoofd-server en sluit zichzelf af. Je moet natuurlijk ook iets inbouwen waardoor je kunt controleren of ze nog actief zijn.

Dit zijn allemaal vrij standaard zaken, bij cloud-providers kun je prima automatische scaling en load-balancing doen. Ook d.m.v K8S of andere orchestratiesoftware kun je het prima zelf regelen. Ik zie geen noodzaak om hier zelf weer het wiel uit te gaan vinden.

Al met al zie ik een hele hoop ongerelateerde vragen/gedachtenspinsels die niet echt een samenhangend verhaal maken.

[SymbolicFrank]

Woy schreef op donderdag 27 augustus 2020 @ 18:09:
Dit zijn allemaal vrij standaard zaken, bij cloud-providers kun je prima automatische scaling en load-balancing doen. Ook d.m.v K8S of andere orchestratiesoftware kun je het prima zelf regelen. Ik zie geen noodzaak om hier zelf weer het wiel uit te gaan vinden.

Al met al zie ik een hele hoop ongerelateerde vragen/gedachtenspinsels die niet echt een samenhangend verhaal maken.

Ik weet wel hoe het nu gebeurd, ik wil het gewoon graag anders doen. Meer zoals Google, Facebook en Twitter dat bijvoorbeeld doen. En ik heb dat in het verleden zelf ook al meerdere keren zo gedaan. Daar wil ik graag over praten.

[Woy]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 17:56:
[...]
Dat klopt. Maar het hangt er maar van af wat je wilt doen. Docker is leuk als je bijvoorbeeld allemaal vergelijkbare dingen wilt doen, die liefst allemaal op dezelfde opslag staan. Zodat je er 1 af kan halen en op een server kunt zetten die nog ruimte heeft.

Hoezo is docker/containerization alleen interessant als je vergelijkbare dingen wilt doen? Je kunt toch ook verschillende containers hosten, en wat heeft het met opslag te maken? Je kunt toch prima over een cluster verdelen en verschillende type storage gebruiken, of gewoon dingen in memory doen.

Als je het snel wilt kunnen benaderen kun je het beste geen database gebruiken en het gewoon in het geheugen houden. Dat is ook goed te distribueren. Bijvoorbeeld een postcode database. Dat is een paar gigabyte, maar die wijzigt zelden en een snelle index (die je in het geheugen wilt hebben) is al gauw net zo groot als de data zelf.

Natuurlijk is memory sneller, maar je wil ook persistentie hebben. Vaak wordt er gewoon een "traag" medium gebruikt als persistentie, en daar worden dan dingen als caching en (in-memory) read-models aan toegevoegd.

En als het geen HTTP is, dan hoef je ook niet automatisch SSL en een certificaat te gebruiken. Sommige services blijven binnen het netwerk, andere zijn publiekelijk toegankelijk, voor weer andere wil je wel authenticatie (RSA of zo) maar hoeft het resultaat niet versleuteld te worden, enzovoorts.

Wat is de reden dat je geen HTTP(S) wil gebruiken?

Youtube en Twitter hebben een miljard gebruikers die allemaal tegelijkertijd dezelfde acties kunnen uitvoeren. Die gaan bijvoorbeeld ook zo weinig mogelijk opslaan op schijf.

Youtube en twitter slaan echt nog steeds zo goed als alles op op disk, dat er voor het uitlezen meerdere lagen caching tussen zit veranderd dat niet.

[Woy]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 18:14:
[...]
Ik weet wel hoe het nu gebeurd, ik wil het gewoon graag anders doen. Meer zoals Google, Facebook en Twitter dat bijvoorbeeld doen.

Juist die bedrijven doen het op die manier. Kubernetes is juist door Google ontwikkeld om zo hun services makkelijk te kunnen orchestreren.

Ook bij google/facebook/twitter gebruiken ze verschillende soorten storage, ook daar zullen gewoon RDBMS'en tussen zitten, soms een Redis cluster, een MongoDB hier en daar, soms een GraphDB. Afhankelijk van het type data dat ze willen opslaan.

[Woy]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 18:14:
[...]
En ik heb dat in het verleden zelf ook al meerdere keren zo gedaan. Daar wil ik graag over praten.

Dan zou ik je willen vragen om een wat meer concrete vraag neer te zetten. Ik zie nu alleen een hele hoop losse flarden die weinig samenhang hebben?

Heb je een probleem met SQL?
Heb je een probleem met no-SQL?
Heb je een probleem met HTTP(S)?
Heb je een probleem met Authenticatie/Authorisatie?
Heb je een probleem met service discovery?
Heb je een probleem met (auto)-scaling?

En dat zijn nog maar een paar van de facetten die ik terug zie komen.

[ Voor 6% gewijzigd door Woy op 27-08-2020 18:23 ]

[SymbolicFrank]

Woy schreef op donderdag 27 augustus 2020 @ 18:19:
Juist die bedrijven doen het op die manier. Kubernetes is juist door Google ontwikkeld om zo hun services makkelijk te kunnen orchestreren.

Ook bij google/facebook/twitter gebruiken ze verschillende soorten storage, ook daar zullen gewoon RDBMS'en tussen zitten, soms een Redis cluster, een MongoDB hier en daar, soms een GraphDB. Afhankelijk van het type data dat ze willen opslaan.

Google heeft natuurlijk een heleboel verschillenden producten en diensten. Een filmpje op youtube waar niemand naar kijkt zal vast wel op een paar harde schijven terecht komen, maar hun zoekdata zit allemaal in het geheugen, op speciale computers die hun eigen besturingssysteem draaien.

Dus als ze zoveel verschillende opslagvormen gebruiken, hebben ze ook veel verschillende services. Nou is Google natuurlijk wel heel sterk op HTTP gericht. Zij verplichten bijvoorbeeld het gebruik van SSL en certificaten voor websites (het groene slotje). Dus de meeste oplossingen die ze uitdragen zullen ook de productie van toepassingen die in een browser draaien (liefst Chrome, natuurlijk) promoten. Aan toepassingen die op jouw eigen server draaien en geen browser gebruiken kunnen zij geen geld verdienen.

Ik ben ook meer geïnteresseerd in het zelf bouwen van zulke systemen dan er 1 van de plank trekken, omdat ik graag weet hoe het allemaal in elkaar zit.

[Woy]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 18:30:
[...]
Google heeft natuurlijk een heleboel verschillenden producten en diensten. Een filmpje op youtube waar niemand naar kijkt zal vast wel op een paar harde schijven terecht komen, maar hun zoekdata zit allemaal in het geheugen, op speciale computers die hun eigen besturingssysteem draaien.

De zoek data wordt ook echt wel ergens gepersisteerd, of dat nou in een BigTable van Google is, of gestructureerde files. Nee dat zal geen RDBMS zijn, want daar is dat niet het type data voor.

Natuurlijk zijn er ook allemaal caching servers, er zijn ook indexing servers e.d.

Dus als ze zoveel verschillende opslagvormen gebruiken, hebben ze ook veel verschillende services.

Dat is oorzaak gevolg omdraaien. Ze hebben een hoop services, en elk van die services heeft andere eisen, en dus kiezen ze verschillende storages. Er is niet 1 gouden ei.

Nou is Google natuurlijk wel heel sterk op HTTP gericht. Zij verplichten bijvoorbeeld het gebruik van SSL en certificaten voor websites (het groene slotje). Dus de meeste oplossingen die ze uitdragen zullen ook de productie van toepassingen die in een browser draaien (liefst Chrome, natuurlijk) promoten. Aan toepassingen die op jouw eigen server draaien en geen browser gebruiken kunnen zij geen geld verdienen.

Voor de inrichting van hun backend/architectuur laten ze zich echt niet leiden door hun browser. De keuze voor HTTP is gewoon omdat het een industriestandaard, lightweight simpel protocol is, waar al een enorme infrastructuur voor is ( Zoals loadbalancers en monitoring ).

Ik ben ook meer geïnteresseerd in het zelf bouwen van zulke systemen dan er 1 van de plank trekken, omdat ik graag weet hoe het allemaal in elkaar zit.

NOFI, maar ik krijg een enorm klok/klepel gevoel bij je post. Je hebt het over "zulke" systemen, haalt er een hele hoop zaken bij, zonder ook maar daadwerkelijk een concreet probleem te hebben. Er is niet iets als "zulke" systemen, ook bij google/facebook/twitter zoeken ze per probleem de juiste oplossing

Als je wil weten hoe dingen werken zul je veel concreter moeten zijn, want dit is ongeveer vragen hoe het universum werkt, want de zee is zo nat, door zwaartekracht val je naar beneden, dus je kunt betere en vliegtuig nemen, als je dan maar wel met euro's betaald want dollars accepteren ze niet in europa.

[Herko_ter_Horst]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 18:30:
[...]
Aan toepassingen die op jouw eigen server draaien en geen browser gebruiken kunnen zij geen geld verdienen.

Google Cloud is het niet met je eens (uiteraard niet op je eigen server, maar in de Google Cloud, als vervanging van jouw eigen server, want waarom wil je veel moeite stoppen in het opzetten en onderhouden van een server, als je je eigenlijk druk wilt maken om je applicatie en het probleem dat die moet oplossen). Uiteraard heeft niet alleen Google dit door, maar ook Microsoft met Azure en Amazon met AWS.

De voorkeur voor http(s) heeft meer te maken met het feit dat het een bewezen protocol is, met een heleboel features die je ook bij gebruik buiten de browser goed kunt gebruiken.

Dat maakt weer dat populaire programmeertalen standaard libraries hebben voor de communicatie over http(s) en dat maakt weer dat veel programmeurs daar bekend mee zijn en mee om kunnen gaan.

Natuurlijk kun je dat allemaal zelf gaan verzinnen en om te leren kan dat best leuk zijn. Maar dan zou ik eerder beginnen met uitzoeken hoe bijvoorbeeld iets als Kubernetes (K8s) werkt. Die kennis kan je namelijk zowel lokaal, als in cloud-omgevingen inzetten.

[ Voor 65% gewijzigd door Herko_ter_Horst op 27-08-2020 18:54 ]

[SPee]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 16:16:
Maar als je daarop selecties wilt draaien, moet je iedere keer een heleboel data over de lijn trekken. Het is daarom eenvoudiger om voor iedere selectie een aparte server te maken.

Je kunt ook de query laten uitvoeren door de nodes. Dan heb je niet "iedere keer een heleboel data", maar alleen je resultaat over de lijn.
Daar is al een oplossing voor. Vrij oud zelfs: Hadoop

En daar vindt je gelijk ook antwoord op je vraag

Het is het mooiste als ze zelf schalen: je verzoekt de hoofd-server om een bepaalde service, die controleert je identiteit en geeft je de sleutel en het adres van de server.

Zookeeper

[The Eagle]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 18:30:
[...]


Google heeft natuurlijk een heleboel verschillenden producten en diensten. Een filmpje op youtube waar niemand naar kijkt zal vast wel op een paar harde schijven terecht komen, maar hun zoekdata zit allemaal in het geheugen, op speciale computers die hun eigen besturingssysteem draaien.

Dus als ze zoveel verschillende opslagvormen gebruiken, hebben ze ook veel verschillende services. Nou is Google natuurlijk wel heel sterk op HTTP gericht. Zij verplichten bijvoorbeeld het gebruik van SSL en certificaten voor websites (het groene slotje). Dus de meeste oplossingen die ze uitdragen zullen ook de productie van toepassingen die in een browser draaien (liefst Chrome, natuurlijk) promoten. Aan toepassingen die op jouw eigen server draaien en geen browser gebruiken kunnen zij geen geld verdienen.

Ik ben ook meer geïnteresseerd in het zelf bouwen van zulke systemen dan er 1 van de plank trekken, omdat ik graag weet hoe het allemaal in elkaar zit.

Je stelt heel veel, maar eigenlijk wil je gewoon weten hoe eea in elkaar steekt en kun je dus niet zo heel veel stellen (omdat je zelf aangeeft dat je niet helemaal weet hoe het zit).

Zoals al gezegd, jongens als Google, FB, Uber etc maken vast wel gebruik van RDBMS maar ook van andere platforms. Ik krijg het idee dat jij eigenlijk alleen relationele DB's en transacties kent. Das prima, maar er is meer dan Mysql en Nosql. Hadoop is al genoemd, daar breng je de code naar de data. Bij Apache Spark doe je dat ook, maar daar zit het in memory.

[SymbolicFrank]

Ok. Kortom, ik wil graag discussieren over andere en nieuwe methodes, jullie willen mij alleen vertellen hoe ik het moet doen zoals jullie dat ook allemaal doen.

Zeker in de IT zijn er heel veel verschillende manieren om iets te doen. Ik doe dingen zelden zoals iedereen vind dat het moet. Als er hier nog andere mensen rondhangen die dat ook doen, wil ik daar graag met hun over praten.

Edit: Ik vraag web devs (ie. de meeste programmeurs tegenwoordig) vaak of ze weten hoe het HTTP protocol werkt. De meeste weten dat niet. Aan de mensen die dat wel weten vraag ik dan: heb je zelf wel eens een HTTP server gebouwd? Ik doe dat regelmatig. Bijna niemand antwoord bevestigend. En het zelfde geldt voor een database, load balancer en al die andere dingen die iedereen gebruikt.

[ Voor 33% gewijzigd door SymbolicFrank op 27-08-2020 22:22 ]

[The Eagle]

Geef eens een goede reden waarom je zelf het wiel opnieuw uit zou vinden?

[TweakMDS]

Ik begrijp uit dit topic niet echt waar het over gaat, of waar het naartoe gaat, maar als we aan het freewheelen zijn doe ik graag mee.
Neem bijvoorbeeld eens een kijkje naar https://vitess.io/
Dat is een mysql variant (dus traditionele rdbms) die zich probeert te onderscheiden door beter te clusteren. Lost best een aantal problemen op, maar introduceert ook vast een hoop nieuwe.

Een tiental jaar geleden ben ik bedrijfsmatig ook begonnen met databases "sharden" door gewoon data op basis van logische keys over verschillende databases te plaatsen.
Daarmee hebben we één identity provider, en elke voor elke user die inlogt wordt de connectie gelegd naar de database waar de data op staat. Dat kan op een andere server zijn, maar hoeft niet. Op zich een mooi systeem, maar het heeft ook keerzijdes. Met name het balanceren of verhuizen van data tussen verschillende nodes is erg lastig.

Maar zoals hier al meer genoemd, als je schaalbare systemen wil bouwen moet je echt wel eens naar kubernetes gaan kijken. Dat heeft op dit moment enorm veel voorzieningen om een schaalbaar systeem op te bouwen, of het nou volledig zelfbouw is of iets off-the-shelf. Met name als je applicatie landschap meer wordt dan enkel een DB server en een webserver loont het enorm om goeie orchestration te hebben.

Vwb zelf bouwen of iets wat al bestaat gebruiken, voor beide is wat te zeggen, als het tenminste om een hobby of leer traject gaat. Het is enorm waardevol om iets zelf op te zetten of zelfs van de grond af aan te bouwen, en precies alles te leren en te ontdekken. Maar doe het dan ook echt vanaf de grond. Op het moment dat je in een high level taal zoals C# een HttpListener gebruikt is het meer component-gebaseerd.

Zo kan je prima een webserver bouwen, of bijvoorbeeld een reverse proxy, met een aantal regels / een pagina code. Ik ken trouwens weinig developers die niet weten hoe het http protocol in elkaar zit, of dit tenminste op een functioneel niveau goed doorgronden.

[.oisyn]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 22:08:
Edit: Ik vraag web devs (ie. de meeste programmeurs tegenwoordig) vaak of ze weten hoe het HTTP protocol werkt. De meeste weten dat niet. Aan de mensen die dat wel weten vraag ik dan: heb je zelf wel eens een HTTP server gebouwd? Ik doe dat regelmatig. Bijna niemand antwoord bevestigend. En het zelfde geldt voor een database, load balancer en al die andere dingen die iedereen gebruikt.

Ok, wat is nu precies de relevantie van dit verhaal?

Als je wil praten over hoe je zelf iets maakt, dan is het denk ik handig om je focus daar op te leggen, in plaats van allerlei ongenuanceerde stellingen te poneren die eigenlijk niets met het door jou beoogde doel van het topic te maken hebben, anders komen daar alleen maar (terecht) reacties op.

En zeg dan niet "ik wil praten over X", maar kom met een gedetailleerd verhaal over wat je zelf al gedaan hebt, hoe je dingen hebt opgelost, waar je tegenaan liep, etc. Dan valt er ergens een gerichte discussie over te voeren.

Overigens wil ik hier nog wel even op reageren:

Zeker in de IT zijn er heel veel verschillende manieren om iets te doen. Ik doe dingen zelden zoals iedereen vind dat het moet.

Dat klinkt een beetje als het not-invented-here syndroom. Daar ben ik in mijn hobbyprojecten ook heer en meester in, ik maak dingen zelf omdat ik de ins- en outs wil weten en daar van wil leren, niet omdat ik uiteindelijk een afgemaakt product wil hebben wat iedereen kan gebruiken. Maar als dat ook je professionele werk-ethos is dan heb ik daar toch echt sterk mijn vraagtekens bij. Er is een reden waarom iedereen zegt dat iets het beste op een bepaalde manier kan. Dat is niet omdat ze er ook maar net even over hebben nagedacht, dat komt uit jaren ervaring van getalenteerde software-ontwikkelaars.

[ Voor 28% gewijzigd door .oisyn op 27-08-2020 23:17 ]

[Postman]

Ik heb zoiets een paar keer gebouwd en vroeg me af of er meer mensen mee bezig zijn, en of hier al een kant en klare oplossing voor bestaat.

Ik haal uit je eerste post een beetje dat je op zoek bent naar een API gateway/Edge service (verschillende namen, zelfde beestje). Nu weet ik bijna niets hierover, maar toevallig een zeer goede uitleg over het concept gezien deze week en dat is volgens mij wat je zoekt.

Ik ben ook meer geïnteresseerd in het zelf bouwen van zulke systemen dan er 1 van de plank trekken, omdat ik graag weet hoe het allemaal in elkaar zit.

Alleen hier wil je opeens weer iets zelf gaan bouwen. Dit strookt niet echt met je eerste post.
Ik sluit me dan aan bij mijn collega Tweakers: leuk voor hobby en om iets te leren, voor productie omgeving iets minder. Los van dat je iets gaat maken dat wellicht ooit moet onderhouden worden door iemand anders (en hoe gaat die persoon dat doen zonder dat hij/zij hier kennis van heeft), is er een reden dat iedereen dezelfde techniek gebruikt. En die reden is simpelweg dat er door heel veel mensen, heel veel tijd in gestoken is. Tijd die jij, hoe efficiënt en geweldig je ook bent, nooit gaat inhalen.
Op het vlak van bijvoorbeeld beveiliging zul je dus altijd een x aantal stappen achterlopen. Leuk voor de script kiddies onder ons zou ik denken. En dat is maar een van de vele redenen die ik kan bedenken om voor een "standaard" oplossing te kiezen.

Als je echt een discussie wil, open deze vraag op Stackoverflow. Daar heb je veel meer kans om iemand te treffen die hetzelfde heeft gedaan wat jij wil (alhoewel ik twijfel of je dat zelf wel duidelijk hebt).

[CodeCaster]

Postman schreef op zaterdag 29 augustus 2020 @ 10:08:
[...]
Als je echt een discussie wil, open deze vraag op Stackoverflow. Daar heb je veel meer kans om iemand te treffen die hetzelfde heeft gedaan wat jij wil (alhoewel ik twijfel of je dat zelf wel duidelijk hebt).

Stack Overflow is geen discussieforum. Een vraag à la "HTTP en SQL sucks, amirite? Ik wil het net zo doen als de big boys, maar zonder precies te zeggen wat" zal ongeveer drie minuten open blijven.

[Ed Vertijsment]

Om even wat inhoudelijks proberen toe te voegen.

Deze discussie komt neer op een tradeoff/balans tussen een aantal factoren zoals data-integriteit(checks), performance, overhead in beheer en kosten.

Het is absoluut waar dat traditionele SQL servers minder goed schalen dan NoSQL databases, maar de eerste bied bijna altijd meer garanties m.b.t. data-integriteit dan de tweede. Er is dan weer een combinatievorm mogelijk maar dat het maakt het weer moeilijker/duurder in beheer. Ditzelfde geld voor het verspreiden van inhoud over verschillende database servers (ik heb overigens ooit eens gehoord dat Justin Bieber zijn eigen database server heeft bij Instagram, simpele effectieve manier van load balancen).

Het schalen is technisch heel mooi maar zelden nodig. Ik ken niet zo veel situaties waar een performance probleem van de database niet met of configuratie of meer hardware opgelost kan worden. Ik ben wel bekend met overijverig opsplitsen zonder echt valide reden anders dan leuk.

Het is een beetje een hype geworden om alles op te splitsen in micro services om elk theoretisch schaal probleem op te lossen maar voor de overgrootte meerderheid is dit simpelweg niet nodig en lever je al snel in op integriteit of stijgen je (beheer)kosten.

Zaken als microservices database partitioning zijn IMO dingen waar je naar kijkt op het moment dat het relevant word en niet iets dat je bij het begin van ieder project gelijk zo inricht.

[Verwijderd]

Ed Vertijsment schreef op dinsdag 1 september 2020 @ 11:24:

Het schalen is technisch heel mooi maar zelden nodig.

Inderdaad, helaas hebben veel programmeurs de neiging om dingen te overcompliceren om zo een "mooiere" oplossing te realiseren.

[The Eagle]

Het schalen is technisch heel mooi maar zelden nodig. Ik ken niet zo veel situaties waar een performance probleem van de database niet met of configuratie of meer hardware opgelost kan worden. Ik ben wel bekend met overijverig opsplitsen zonder echt valide reden anders dan leuk.

Nofi, maar meer hardware IS schalen. Schalen kan horizontaal (meer ijzer) en verticaal (uitbreiden capaciteit bestaand ijzer). Kennelijk snap jij het verschil niet, en daarmee ontkracht je de rest vn je post.

Verder: ja, je kunt een performance issue op meerdere manieren aanvliegen. Werk je in de cloud, heb je globaal twee opties: engineer laten onderzoeken waar de piek vandaan komt, software aanpassen. Week werk kost je zo 4k ex btw zonder enige garantie. Optie twee: met een (al dan niet autoscaling) een stuk identiek ijzer tijdelijk bijschalen en daarna weer afschalen, instant problem solved. Kost stukken minder, levert veel meer op.
Tenzij je nog aan fysieke hardware gebonden bent die echt niet schaalt is dat tegenwoordig het credo.

[TweakMDS]

Aangezien we toch tot een debat aan het komen zijn over schaalbaarheid:

Verwijderd schreef op dinsdag 1 september 2020 @ 11:29:
[...]
Inderdaad, helaas hebben veel programmeurs de neiging om dingen te overcompliceren om zo een "mooiere" oplossing te realiseren.

Ik zit hier een beetje dubbel in. Je kan je development uren natuurlijk maar één keer uitgeven, maar ik vind het juist heel bruikbaar om enigszins tegen groot succes bestand te zijn.

Stel, ik maak vandaag een website waarbij je op huizen kan bieden (noem maar iets raars). Ik zou dan zo verwachten dat ik in de eerste 3 maanden rustig een pilot begin, en contact op neem met een aantal makelaars. Maar stel je voor dat ik ineens genoemd word op BNR, en een miljoen gebruikers in die week krijg. Dat is onrealistisch, maar niet ondenkbaar.

Ik zou het van developers tegenwoordig niet meer accepteren als er niet tenminste een risico inschatting doet op de effort en mogelijkheden van opschalen, en eigenlijk moet dit ook vanzelf gaan. Tractie krijg je misschien maar één keer, en als net dan je applicatie eruit ligt, dan heb je pech en mag je het met de volgende startup nog eens proberen.
Het hangt natuurlijk enorm af van je segment of product, maar een goede schaalbaarheid kan "mission critical" zijn, als je aan performance tijdens een virale groei overgeleverd bent.

The Eagle schreef op dinsdag 1 september 2020 @ 20:36:
[...]

Nofi, maar meer hardware IS schalen. Schalen kan horizontaal (meer ijzer) en verticaal (uitbreiden capaciteit bestaand ijzer). Kennelijk snap jij het verschil niet, en daarmee ontkracht je de rest vn je post.

Verder: ja, je kunt een performance issue op meerdere manieren aanvliegen. Werk je in de cloud, heb je globaal twee opties: engineer laten onderzoeken waar de piek vandaan komt, software aanpassen. Week werk kost je zo 4k ex btw zonder enige garantie. Optie twee: met een (al dan niet autoscaling) een stuk identiek ijzer tijdelijk bijschalen en daarna weer afschalen, instant problem solved. Kost stukken minder, levert veel meer op.
Tenzij je nog aan fysieke hardware gebonden bent die echt niet schaalt is dat tegenwoordig het credo.

Absoluut mee eens, maar die is naar mijn inzien niet het enige, schaalbaarheid is een combinatie tussen software schalen (horizontaal) en onderliggend ijzer schalen (horizontaal en/of verticaal).
Als je software niet dusdanig is ontworpen dat deze überhaupt horizontaal schaalbaar is vervalt die mogelijkheid. Dat komt ook op het vorige puntje uit.

Verder noem je nog wel een héél sterk punt; opschalen in een cloud omgeving kan natuurlijk prima zolang je de juiste technieken hebt gebruikt, zoals bijvoorbeeld lambda in AWS of Azure functions (of een vergelijkbaar cloud-agnostische oplossing zoals OpenFAAS).
Afschalen is ook zeker een ding wat je enorm kosten kan besparen.

[Ed Vertijsment]

The Eagle schreef op dinsdag 1 september 2020 @ 20:36:
[...]

Nofi, maar meer hardware IS schalen. Schalen kan horizontaal (meer ijzer) en verticaal (uitbreiden capaciteit bestaand ijzer). Kennelijk snap jij het verschil niet, en daarmee ontkracht je de rest vn je post.

Ik snap het verschil prima, en had her hier over de overhead die je vrij snel krijgt als je horizontaal gaat schalen tegen verticaal schalen waar een limiet aan zit. Punt was (en is) dat maar weinig use cases aan dat limiet komen.

The Eagle schreef op dinsdag 1 september 2020 @ 20:36:
[...]
Verder: ja, je kunt een performance issue op meerdere manieren aanvliegen. Werk je in de cloud, heb je globaal twee opties: engineer laten onderzoeken waar de piek vandaan komt, software aanpassen. Week werk kost je zo 4k ex btw zonder enige garantie. Optie twee: met een (al dan niet autoscaling) een stuk identiek ijzer tijdelijk bijschalen en daarna weer afschalen, instant problem solved. Kost stukken minder, levert veel meer op.
Tenzij je nog aan fysieke hardware gebonden bent die echt niet schaalt is dat tegenwoordig het credo.

Ik moet de eerste use case nog tegenkomen van autoscaling die onder de streep qua kosten (TCOO) voordeliger is, er zijn soms aanvullende redenen om het te doen maar het is niet per definitie de beste oplossing.

Scaling clouds zijn duur, domme dozen goedkoop. De individuele domme nodes zijn vaak krachtiger en niet elke opdracht heeft meer aan meer schaalbare capaciteit, soms is een taak gewoon gebaar bij een hele dikke cpu in plaats van de mogelijkheid 300 keer tegelijk gedraaid te worden.

Een piek oplossen is trouwens nog steeds iets wat je je engineer wilt laten oplossen anders autoscaled je cloud rustig je budget leeg.

[Verwijderd]

Ik snap wat je bedoelt, maar tegenwoordig is het toch vrij eenvoudig om in korte tijd enorm snel op te schalen. Bijvoorbeeld de snelste server op DigitalOcean: 192GB ram, 32 cpu cores...

[The Eagle]

Kijk, het ijzer an sich is het probleem vaak niet. Of je dat nou bij de leverancier bestelt, danwel in de cloud bijplust. Probleem zit hem in de mensen en de beschikbaarheid daarvan, plus de procedures er omheen.

Als ik NU tegen een issue loop en ik ga schalen:
Fysiek: Machine er bij, bestellen, handling, in rek hangen, configureren...je bent zo een paar maanden verder met alle impact op business van dien. En een relatief peperdure machine (40k ex ofzo, plus 5k personeelslasten voor alle redtape en engineering) voor een piek, die verder uit zijn neus staat te vreten.
Cloud: ga maar eens bij datascience en data engineering kijken. Uren zijn heel erg duur. Daar maak je de vergelijking zo. Bovendien heb je daar ook regelmatig een processingplatform voor vele typen procesing. Ga maar eens iemand snel vinden die daar ook nog eens snel een node bij kan plussen met die technologie. Vind je niet op korte termijn, en vind je hem wel praat je over uurtarieven van 100/150+ euro ex. Die gast moet gewoon kunnen werken, als ie een dag stilstaat kost ie al klauwen met geld, en zijn dure collegas ook. Businesscase is heel snel gemaakt, ook omdat je in die hoek gewoon af kunt schalen. Die technologie hoeft niet 24/7 te draaien namelijk.

Wanneer kun je wel een case maken: als de hardware echt dedicated gebruikt wordt. Maar dan praat je over de ondersteuning van een specifiek businessproces. En dan heeft IT dus eigenlijk niks te besluiten maar is het een businessprobleem.

[TweakMDS]

Wij doen werk-gerelateerd erg veel met factureringsprocessen.

Als je één dag in de maand 1,6 miljoen PDF-jes wil maken, die ook nog eens binnen ~24 uur gegenereerd, gearchiveerd en verstuurd moeten worden, inclusief allerlei business rule en workflow processen daaromheen is schalen best bruikbaar.
Op dit moment zijn er ongeveer 6 tot 8 machines mee bezig die de rest van de maand weinig aan het doen zijn.
Het is in ieder geval iets waar we nu ernstig naar aan het kijken zijn. Omdat ons platform inmiddels ook helemaal over is naar kubernetes ligt het ook veel meer voor de hand om dat te doen.

Wat het overigens weer moeilijker maakt is dat dit spul toch bij veel van onze klanten on-premise moet staan, dus uiteindelijk moet het onderliggende ijzer daar toch wel staan. Dat maakt de business case weer wat moeilijker.

[Ed Vertijsment]

The Eagle schreef op dinsdag 1 september 2020 @ 21:54:
Kijk, het ijzer an sich is het probleem vaak niet. Of je dat nou bij de leverancier bestelt, danwel in de cloud bijplust. Probleem zit hem in de mensen en de beschikbaarheid daarvan, plus de procedures er omheen.

Als ik NU tegen een issue loop en ik ga schalen:
Fysiek: Machine er bij, bestellen, handling, in rek hangen, configureren...je bent zo een paar maanden verder met alle impact op business van dien. En een relatief peperdure machine (40k ex ofzo, plus 5k personeelslasten voor alle redtape en engineering) voor een piek, die verder uit zijn neus staat te vreten.
Cloud: ga maar eens bij datascience en data engineering kijken. Uren zijn heel erg duur. Daar maak je de vergelijking zo. Bovendien heb je daar ook regelmatig een processingplatform voor vele typen procesing. Ga maar eens iemand snel vinden die daar ook nog eens snel een node bij kan plussen met die technologie. Vind je niet op korte termijn, en vind je hem wel praat je over uurtarieven van 100/150+ euro ex. Die gast moet gewoon kunnen werken, als ie een dag stilstaat kost ie al klauwen met geld, en zijn dure collegas ook. Businesscase is heel snel gemaakt, ook omdat je in die hoek gewoon af kunt schalen. Die technologie hoeft niet 24/7 te draaien namelijk.

Wanneer kun je wel een case maken: als de hardware echt dedicated gebruikt wordt. Maar dan praat je over de ondersteuning van een specifiek businessproces. En dan heeft IT dus eigenlijk niks te besluiten maar is het een businessprobleem.

Ik vind het een beetje onsamenhangend maar volgens mij zeg je kort samengevat dit:

On-premise dedicated hardware = duur want dure machines dure aanschaf.
Scaling cloud = goedkoop want alleen betalen voor wat je nodig hebt.

Er zit natuurlijk nog veel meer daartussen. Zo kan ik bij menig hoster gewoon een dedicated bak aanklikken en met een paar uurtjes een Ansible playbook afschieten en gaan. Geen dedicated hardware nodig? Nog makkelijker, VPS aanklikken en gaan.

Een scaling cloud is eigenlijk vooral interessant als je een hele gevarieerde (hoge) workload hebt op onvoorspelbare tijden. Maar in de praktijk past dat profiel gewoon heel weinig projecten. Veruit de meeste hebben meer dan genoeg aan een simpele sterke server. Nogal saai, maar het werk meestal prima.

[Hydra]

Bedoel je niet micro-services?

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 16:16:
Is dat hier al voorbij gekomen?

SQL-databases schalen slecht en zijn moeilijk te distribueren. Je krijgt dan al snel no-sql databases, die vooral platte tabellen met sleutels en waardes opslaan. Maar als je daarop selecties wilt draaien, moet je iedere keer een heleboel data over de lijn trekken. Het is daarom eenvoudiger om voor iedere selectie een aparte server te maken.

Dit is zo kort door de bocht dat er weinig zinnigs over te zeggen is. SQL databases schalen niet oneindig, maar dat doet eigenlijk geen enkel systeem, of niet zonder hele flinke beperkingen op te leggen in ieder geval. En micro-services en SQL databases zijn een prima match. Het is alleen een no-no om databases (of schema's tenminste) te sharen tussen services.

Dan zit je met verschillenden dingen. Om te beginnen, als je er een aparte IIS of Apache server met zijn eigen SQL-database voor gebruikt, nemen ze veel ruimte en capaciteit in beslag. Maar dat hoeft natuurlijk niet. Het is heel eenvoudig om je eigen, unieke protocol te gebruiken en aan een poort te hangen. En als het absoluut HTTP moet zijn, kun je in C# bijvoorbeeld een HttpListener gebruiken.

Euh, wat?

Daarna zit je met de distributie en de beveiliging. SSL zegt bijvoorbeeld niets over de identiteit als je geen certificaten gebruikt. En om nou iedere micro-server zijn eigen certificaat te geven gaat wel erg ver. Ook is dat een vrij zware versleuteling die niet eenvoudig zelf te bouwen is.

Daar is mutual TLS voor uitgevonden. Da's een industry standard tussen microservices en daar zijn ook genoeg tools voor (envoy, istio). Waarom zou je dat zelf gaan bouwen?

En je wil waarschijnlijk die dingen "on-demand" kunnen opstarten. Het is het mooiste als ze zelf schalen: je verzoekt de hoofd-server om een bepaalde service, die controleert je identiteit en geeft je de sleutel en het adres van de server. Als die service nog niet actief is of de belasting te hoog is, start hij een nieuwe, met zijn eigen adres (minimaal een ander poortnummer). En als die service een tijdje geen aanvragen krijgt, geeft hij dat door aan de hoofd-server en sluit zichzelf af. Je moet natuurlijk ook iets inbouwen waardoor je kunt controleren of ze nog actief zijn.

Ik heb zoiets een paar keer gebouwd en vroeg me af of er meer mensen mee bezig zijn, en of hier al een kant en klare oplossing voor bestaat.

Je bent Kubernetes aan het nabouwen geweest? K...

[Hydra]

Ed Vertijsment schreef op dinsdag 1 september 2020 @ 21:03:
Ik moet de eerste use case nog tegenkomen van autoscaling die onder de streep qua kosten (TCOO) voordeliger is, er zijn soms aanvullende redenen om het te doen maar het is niet per definitie de beste oplossing.

Ik doe veel grote enterprise projecten en op plekken waar er een grote variabele load is, is het de normaalste zaak van de wereld. Er zijn genoeg plekken waar data in grote happen naar binnen komt.

Daarnaast vind ik het best bizar om in 2020 nog verhalen te lezen over met de hand meer servers erbij klikken. Die shit kan tegenwoordig bij AWS/GCP gewoon enorm simpel volledig geautomatiseerd worden. Toevallig op dit moment met DataFlow (apache beam) bezig en die autoscaled volledig automatisch gebaseerd op throughput.

[ Voor 13% gewijzigd door Hydra op 02-09-2020 10:27 ]

[Ed Vertijsment]

Hydra schreef op woensdag 2 september 2020 @ 10:26:
[...]


Ik doe veel grote enterprise projecten en op plekken waar er een grote variabele load is, is het de normaalste zaak van de wereld. Er zijn genoeg plekken waar data in grote happen naar binnen komt.

Prima, maar niet valt onder de enterprise wereld.

Hydra schreef op woensdag 2 september 2020 @ 10:26:
[...]
Daarnaast vind ik het best bizar om in 2020 nog verhalen te lezen over met de hand meer servers erbij klikken. Die shit kan tegenwoordig bij AWS/GCP gewoon enorm simpel volledig geautomatiseerd worden. Toevallig op dit moment met DataFlow (apache beam) bezig en die autoscaled volledig automatisch gebaseerd op throughput.

Dat is simpelweg niet altijd wenselijk. Vaak zijn de kosten hiervan niet transparant en onder des streep duurder. Deze diensten zijn allerminst goedkoop. Ze kunnen dan wel efficient ingezet worden, de basis prijs ligt vaak nog steeds hoger dan een simpele VPS die zonder problemen kan draaien. Controle over de kosten/capaciteit is vaak gewoon een wens.

Daarnaast is de capaciteit van servers tegenwoordig zo hoog dat er met een hele simpele setup gigantische goedkope capaciteit behaalt kan worden.

Even een voorbeeld, een van de drukbezochtste culturele instellingen van Nederland (en misschien daar buiten), zeer groot publiek en gebruik, zowel nationaal als internationaal (doet ook andere dingen dan een cultuurinstelling zij ). Kan simpel op 1 webserver en 1db draaien met de nodige optimalisaties. Draait voor de vorm op 2.

Ander voorbeeld overheidsprojeect. Draait op full blown kubernetes (en giga duur). Gigantisch gezeik om simpele resources aan te spreken omdat alles weggeabstraheerd is. Voor een ploeg van 2 man die paar keer per dag dingen aanklikken.

[Hydra]

Ed Vertijsment schreef op woensdag 2 september 2020 @ 10:44:
Prima, maar niet valt onder de enterprise wereld.

Punt is dat dat jij het niet gezien hebt, geen argument is.

Dat is simpelweg niet altijd wenselijk. Vaak zijn de kosten hiervan niet transparant en onder des streep duurder. Deze diensten zijn allerminst goedkoop.

Developers zijn duurder.

[Ed Vertijsment]

Hydra schreef op woensdag 2 september 2020 @ 10:46:
[...]
Punt is dat dat jij het niet gezien hebt, geen argument is.

Absoluut, ben er overigens niet onbekend mee maar enterprise is een buitencategorie waar dingen anders gaan. Ik heb het over de grote meerderheid, an dat is niet enterprise en heeft vaak niet de noodzaak van autoscaling alles.

Hydra schreef op woensdag 2 september 2020 @ 10:46:
[...]Developers zijn duurder.

Ja, maar die heb je nodig om de software uberhaubt te maken, en als die software niet rockt schaalt een elastic cloud je budget op en ben je alsnog duurder uit. Qua beheer is zo'n bak echt peanuts. Aanklikken, Ansible afschieten en weer door met de orde van de dag.

[ Voor 33% gewijzigd door Ed Vertijsment op 02-09-2020 10:50 ]

[TweakMDS]

Ed Vertijsment schreef op woensdag 2 september 2020 @ 10:44:
[...]
Ander voorbeeld overheidsprojeect. Draait op full blown kubernetes (en giga duur). Gigantisch gezeik om simpele resources aan te spreken omdat alles weggeabstraheerd is. Voor een ploeg van 2 man die paar keer per dag dingen aanklikken.

Wat bedoel je precies met "alles weggeabstraheerd"?, Weet je hier meer van?
Ik kan het namelijk niet echt plaatsen. Met een jaartje of wat ervaring in Kubernetes vind ik het op geen enkele manier complexer of meer gecompliceerd. Een heleboel problemen met traditionele hosting en deployments worden juist een heel stuk makkelijker. Juist omdat je hele infrastructuur gebaseerd is op standaarden merk ik dat je juist enorm veel tijd gaat besparen tussen reproduceerbaar maken van bevindingen op productie vs testomgevingen, en het fatsoenlijk en deterministisch deployen van een nieuwe versie.

Er is uiteraard een leercurve, maar die vind ik zelf verre van problematisch.

[Ed Vertijsment]

SndBastard schreef op woensdag 2 september 2020 @ 12:04:
[...]


Wat bedoel je precies met "alles weggeabstraheerd"?, Weet je hier meer van?
Ik kan het namelijk niet echt plaatsen. Met een jaartje of wat ervaring in Kubernetes vind ik het op geen enkele manier complexer of meer gecompliceerd. Een heleboel problemen met traditionele hosting en deployments worden juist een heel stuk makkelijker. Juist omdat je hele infrastructuur gebaseerd is op standaarden merk ik dat je juist enorm veel tijd gaat besparen tussen reproduceerbaar maken van bevindingen op productie vs testomgevingen, en het fatsoenlijk en deterministisch deployen van een nieuwe versie.

Er is uiteraard een leercurve, maar die vind ik zelf verre van problematisch.

Wat je met Kubernetes in een container zou moeten draaien draai je anders direct op je node. Alleen is toegang tot die node voor maintenance dingen simpeler dan dan toegang tot een container. Nu wil je doorgaans niet "ambachtelijk" dingen in een server of container doen maar voor sommige dingen is het heel fijn om gewoon niets in de weg te hebben zitten. Als de noodzaak voor K8s er niet is voegt het niets to om het op te tuigen.

Ik ervaar geen enkele problemen met "traditionele hosting" of "traditionele" deployment. Alles staat software defined en is met een enkel commando te deployen. Of het nou kubectl of een ander commando is maakt dan ook niet veel meer uit.

Er zijn absoluut use cases voor Kubernetes maar niet alles is er een, daarnaast is het doorgaan duurder in onderhoud en lost het niet elk probleem op.

[Hydra]

Ed Vertijsment schreef op woensdag 2 september 2020 @ 15:53:
Wat je met Kubernetes in een container zou moeten draaien draai je anders direct op je node. Alleen is toegang tot die node voor maintenance dingen simpeler dan dan toegang tot een container.

Wat bedoel je hiermee?

[Ed Vertijsment]

Hydra schreef op donderdag 3 september 2020 @ 12:59:
[...]


Wat bedoel je hiermee?

Of je draait een load in een machine, of in een container, in een machine. Daar zit je extra laag aan abstractie die bepaalde dingen lastiger maakt.

[The Eagle]

Ed Vertijsment schreef op woensdag 2 september 2020 @ 15:53:
[...]


Wat je met Kubernetes in een container zou moeten draaien draai je anders direct op je node. Alleen is toegang tot die node voor maintenance dingen simpeler dan dan toegang tot een container. Nu wil je doorgaans niet "ambachtelijk" dingen in een server of container doen maar voor sommige dingen is het heel fijn om gewoon niets in de weg te hebben zitten. Als de noodzaak voor K8s er niet is voegt het niets to om het op te tuigen.

Ik ervaar geen enkele problemen met "traditionele hosting" of "traditionele" deployment. Alles staat software defined en is met een enkel commando te deployen. Of het nou kubectl of een ander commando is maakt dan ook niet veel meer uit.

Er zijn absoluut use cases voor Kubernetes maar niet alles is er een, daarnaast is het doorgaan duurder in onderhoud en lost het niet elk probleem op.

Dan neem ik aan dat je bij je voorgaande reacties cloud ook sec als IAAS ziet en niet de PaaS of SaaS componenten. Terwijl daar nou juist de kracht en de kostenbesparing en de echte scalability zit, want nauwelijks beheer en pay as you go.

[Ed Vertijsment]

The Eagle schreef op donderdag 3 september 2020 @ 14:55:
[...]

Dan neem ik aan dat je bij je voorgaande reacties cloud ook sec als IAAS ziet en niet de PaaS of SaaS componenten. Terwijl daar nou juist de kracht en de kostenbesparing en de echte scalability zit, want nauwelijks beheer en pay as you go.

Dit kostenbesparing is in mijn ervaring (zoals ik ook al eer zij) er meestal niet, want je gebruikt de meeste efficiënte manier van een (te) dure omgeving die per saldo (in de meeste gevallen) nog steed duurder is dan een simpele dedicated bak of VPS. Dan heb je best nog wat marge om af een toe een update door te voeren.

Overigens pretendeer je hier dat, dat onderhoud zoveel tijd kost. Dat stelt in de praktijk ook niets voor omdat alles in Ansible staat en security updates/backups ook gewoon automatisch draaien.

[Hydra]

Ed Vertijsment schreef op donderdag 3 september 2020 @ 13:02:
Of je draait een load in een machine, of in een container, in een machine. Daar zit je extra laag aan abstractie die bepaalde dingen lastiger maakt.

Zoals?

[Ed Vertijsment]

Hydra schreef op donderdag 3 september 2020 @ 16:12:
[...]


Zoals?

Je K8s infrastructuur.

[Hydra]

Ed Vertijsment schreef op donderdag 3 september 2020 @ 16:19:
Je K8s infrastructuur.

Ja maar wat is lastiger?

[TweakMDS]

Hydra schreef op vrijdag 4 september 2020 @ 07:15:
[...]

Ja maar wat is lastiger?

Op zich is dit ook een erg lastige inschatting om te maken. Met redelijk wat Kubernetes kennis vind ik het niet-kubernetes proces nu een stuk omslachtiger. Daarbij denk ik aan de traditionele ansible + vagrant-achtige constructies. "Droge docker" zie ik eigenlijk niet als een compleet proces in productie. Swarm zou nog kunnen, maar dan kan je imho toch beter voor K8s gaan.

Als je bedreven bent in ansible of vergelijkbare tools is het best makkelijk en laagdrempelig, maar om het goed te doen moet je met zo ontzettend veel extra dingen rekening houden waar je in K8s toch een wat meer standaard aanpak hebt. Je kan natuurlijk alles scripten, maar als ik morgen een nieuwe collega zou moeten uitleggen hoe alles werkt ben ik een heel stuk sneller klaar als ik dat met standaard technieken moet doen, dan als dat op basis van allerlei eigen scripts is.

In ons geval hebben we zo'n 30 microservices, een aantal DB servers en een heleboel "machines" die onderling file-shares of shared storage nodig hebben. Punt is een beetje, wij begonnen ook ooit met 3 servers; een webserver, database en processing / applicatie server. Er is een omslagpunt waarin de traditionele manier van hosting gewoon minder efficient wordt.

Voor ons lag dat hem met name in het on-premise in moeten zetten bij enkele klanten, die allerlei aanvullende eisen gingen stellen. Op dat moment werkt een Kubernetes gebaseerde oplossing voor ons gewoon beter.

[The Eagle]

Ed Vertijsment schreef op donderdag 3 september 2020 @ 16:00:
[...]


Dit kostenbesparing is in mijn ervaring (zoals ik ook al eer zij) er meestal niet, want je gebruikt de meeste efficiënte manier van een (te) dure omgeving die per saldo (in de meeste gevallen) nog steed duurder is dan een simpele dedicated bak of VPS. Dan heb je best nog wat marge om af een toe een update door te voeren.

Overigens pretendeer je hier dat, dat onderhoud zoveel tijd kost. Dat stelt in de praktijk ook niets voor omdat alles in Ansible staat en security updates/backups ook gewoon automatisch draaien.

Ok, en als ik nou geen ansible of automation ingericht heb, of dat nauwelijks in de kinderschoenen staat? Sure, als je het wel hebt ingericht heb je minder beheerslast, maar heb je ook meteen het punt van standaard bouwblokken bereikt. Merendeel vn de organisaties is nog lang niet zover, dat durf ik wel te stellen.
En ja, dan kun je full focus gaan op automation, maar dat kost je ook klauwen met geld aan ontwikkelingskosten. Verschuiving van uitgaven / investeringen dus. Ik zal je dit zeggen: als business nu geen automation hebben en ze hebben slechts "een ding" nodig, gaan ze niet zomaar een fully fledged ansible omgeving neerzetten omdat dat handiger is
Daarbij: ansible is leuk boor het provisonen van een OS en wat standaard opensource apps. Als jij met (semi) enterprise applicatie spul aan de slag gaat, zul je die playbooks ook zelf moeten ontwikkelen. Doe dan maar een PaaS boublokw in de cloud, stuk sneller en goedekoper dan de hele zut zelf opzetten.
Oh ja, als jij een ansible playbook hebt om een node bij een Oracle RAC DB bij te zetten hoor ik het graag. Sommige dingen zijn niet zo makkelijk te automaten als je zou willen

[Douweegbertje]

We moeten ook gewoon niet vergeten dat we ook naar de applicatie moeten kijken, de cultuur, de kennis, expertise, etc. etc. etc. Er spelen gewoon heel veel factoren en eigenlijk is techniek is daar vrij irrelevant in.

In de juiste organisatie, met de juiste mensen, de juiste cultuur, de juist mindset, de juiste middelen, de juiste funds, de juiste visie, de juiste ... - is het pas echt mogelijk om echt fancy meuk te gaan doen.

Er bestaan zoveel mooie technieken maar die komen pas tot hun recht als ze ook op recht op de juiste manier worden gebruikt. Het feit is gewoon dat 99.9% van de bedrijven hier niet aan toe zijn. En die enkele die het wel doen nemen niet voor niets alleen seniors aan. *kuch* netflix *kuch* - wat ook weer zijn effecten heeft;

Netflix has a policy to only hire senior engineers. A broken engineering culture where juniors are seen as a burden and seniors cannot develop their leadership skills to the fullest.

Ik ben juist iemand die bij veel organisaties heeft binnen gekeken en vaak opdrachten doe m.b.t. "help - we hebben k8s, we willen cloud native - wat nu?!"

90% van mijn werk, hell, 95% is simpelweg vertrouwen kweken, processen aanpassen, cultuur veranderen en noem het maar op.

tl;dr de tech is er al lang, er moeten andere dingen veranderen wil je verder komen.

[SymbolicFrank]

Er bestaan al veel methodes om tot een resultaat te komen. De gebruikte zijn vooral afhankelijk van de populariteit, die weer grotendeels afhankelijk is van wat de ontwikkelaars geleerd hebben op school en hoe eenvoudig het is om over te schakelen naar een nieuwe manier.

Samen als groep bepalen de ontwikkelaars zo hoe je het beste een applicatie kunt maken. En tegenwoordig is dat meestal een webapp en soms embedded. De rest is vooral onderhoud van bestaande applicaties, onderzoek en ontwikkeling.

Die populariteit wordt ook heel sterk beïnvloed door hoe de dingen die de grote 3 doen er aan de buitenkant uitzien. Zo zie je bijvoorbeeld steeds vaker dat je de gebruikersnaam en het wachtwoord op verschillende pagina's moet invoeren. Ook hun specificaties zijn heel populair.

Bijvoorbeeld: Exact gebruikt REST met OAuth 2.0 authenticatie. Want dat doet iedereen. Nou is hun implementatie nogal knullig, wat het niet eenvoudiger maakt. Ik heb dus een Exact app gemaakt, die alles implementeerde volgens hun specificaties, waar ik twee servers en een embedded Chromium voor nodig had om het te kunnen automatiseren. Om er dan achteraf achter te komen dat het zo ingewikkeld is dat vrijwel niemand het voor elkaar krijgt en de sessie-sleutel dus statisch gegenereerd wordt en nooit verloopt...


Maar zolang we er van uitgaan dat alle bollebozen bij Google werken en het dus geen zin heeft om zelf onderzoek en ontwikkeling te doen, hebben we ook geen inspraak. En dat onderzoek is ook een geweldige manier om te begrijpen hoe de dingen nu in elkaar zitten en wat de mogelijkheden zijn.

[RobIII]

SymbolicFrank schreef op zaterdag 5 september 2020 @ 01:17:
Bijvoorbeeld: Exact gebruikt REST met OAuth 2.0 authenticatie. Want dat doet iedereen. Nou is hun implementatie nogal knullig, wat het niet eenvoudiger maakt. Ik heb dus een Exact app gemaakt, die alles implementeerde volgens hun specificaties, waar ik twee servers en een embedded Chromium voor nodig had om het te kunnen automatiseren. Om er dan achteraf achter te komen dat het zo ingewikkeld is dat vrijwel niemand het voor elkaar krijgt en de sessie-sleutel dus statisch gegenereerd wordt en nooit verloopt...

Als iemand die zelf de OAuth met Exact geïmplementeerd heeft in een headless applicatie (een soort batch factuur importeer ding) kan ik je vertellen dat ik het hier ronduit mee oneens ben. Je hebt écht geen embedded Chromium en twee servers nodig (Ook niet één van die dingen overigens). De implementatie was pretty straightforward en weinig bijzonders aan. En de sessie-sleutels verlopen wel degelijk; daar heb je de refresh tokens voor...

Voor de rest vind ik je verhaal, met alle respect, behoorlijk abstract en, dare I say, warrig. Als je op de radio hoort dat er een spookrijder gesignaleerd is en jij denkt "maar ik zie er wel honderd" moet je misschien toch eens achter je oren krabben. Er is echt geen conspiracy waarin een boel developers hebben besloten "en zo gaan we het doen en al het andere is dom" en ik denk dat de meeste developers een prima eigen verstand hebben om hun eigen keuzes te maken; dat dat resulteert in een hele zwik developers die 'tzelfde doen betekent in mijn ogen dat ze (onafhankelijk) tot dezelfde conclusie zijn gekomen (yay!) en dat 't dus blijkbaar een goed idee is om iets zus of zo te doen. Niet omdat er een 'grote 3" achter zit met alle "breinen" uit 't wereldje.

SymbolicFrank schreef op zaterdag 5 september 2020 @ 01:17:
En tegenwoordig is dat meestal een webapp en soms embedded

Van wat je (misschien wel in je eigen omgeving) ziet misschien. Maar voor elke "webapp" of "(mobile) game" of ander hip flashy project dat ontwikkeld wordt zit er ook ergens iemand in een donker hoekje nog aan een COBOL applicatie te sleutelen bij een verzekeringsmaatschappij of bank of wordt er (zoals bij ons) een zoveelste service geschreven die data/input (her)kauwt en z'n ding doet/output. Dat "het grote publiek" die dingen nooit ziet maakt niet dat ze niet bestaan. 90% van wat ik doe zal nooit iemand (lees: eindgebruikers) onder ogen krijgen.

[ Voor 32% gewijzigd door RobIII op 05-09-2020 01:42 ]

[Freeaqingme]

Ik kan dit topic maar lastig volgen. Het begint over distributed databases, en even later gaat het over ijzer vs cloud (wat uiteindelijk ook op iemands ijzer draait). Voorzover het over databases moest gaan wil ik ook nog wel even Cockroachdb genoemd hebben, wat een (in beginsel) postgres-compatible distributed RDBMS is.

Verder hoor ik inderdaad ook wel van veel devs dat ze nu zelf ineens ops kunnen, omdat ze nu met 1 yaml file een container in kubernetes kunnen drukken. Dat kubernetes cluster wordt vervolgens nooit geupgrade, noch gemonitored. En als er dan toch problemen zijn dan is er paniek, want vanwege alle extra abstractielaagjes zijn er meer punten waarop er iets fout kan gaan. Uiteraard _kan_ je dat allemaal goed inrichten, maar dan ben je wel weer veel uren kwijt die je ook aan andere dingen had kunnen besteden ("developers zijn duurder").

Vergelijk dat met 1 Debian VM - meeste softwareprojecten hebben echt geen autoscaling nodig - waarop je doet apt-get install nginx mariadb-server grafana etc, en je hebt 1 werkend systeem wat goed te troubleshooten is. Dat is zeker niet voor alles de oplossing, maar ik denk dat voor projecten tot 2 FTE het bijna altijd de juiste oplossing is. Eventueel echt periodieke loads (X eens per maand), zou je eventueel specifiek dan extern kunnen draaien. Maar ook daarvoor geldt dat ik ook wel eens gezien heb dat men singlethreaded 200K facturen aanmaakte 2 keer per maand en dat gewoon op 1 machine deed. Dat dat 4 uur duurde nam men voor lief.

Edit: Tot slot:
- Waarop slaat het 'micro' stukje in de titel?
- ExactOnline API (geen ervaring met Exact Globe) is best oke wat mij betreft, hoewel de documentatie iets uitgebreider had gemogen, en ik de validatie soms wel erg streng vind (bijv. debiteur geweigerd omdat het btw-nummer uit Timbuktu in het verkeerde formaat is, of landcode voor Kosovo niet meer bestaat). Enige jammere is als het refreshen van je refreshtoken mislukt, dan moet je opnieuw handmatig zo'n token aanmaken. Gebeurt bij mijn klant zo'n 2 a 3 keer per jaar.

[ Voor 15% gewijzigd door Freeaqingme op 05-09-2020 01:51 ]

[SymbolicFrank]

RobIII schreef op zaterdag 5 september 2020 @ 01:30:
Als iemand die zelf de OAuth met Exact geïmplementeerd heeft in een headless applicatie (een soort batch factuur importeer ding) kan ik je vertellen dat ik het hier ronduit mee oneens ben. Je hebt écht geen embedded Chromium en twee servers nodig De implementatie was pretty straightforward en weinig bijzonders aan. En de sessie-sleutels verlopen wel degelijk; daar heb je de refresh tokens voor...

Ja, zolang jullie altijd de klant zijn. Op het moment dat je data gaat importeren in de boekhoudingen van je eigen klanten moeten die zelf inloggen en wordt het een heel ander verhaal.

Van wat je (misschien wel in je eigen omgeving) ziet misschien. Maar voor elke "webapp" of "mobile game" die ontwikkeld wordt zit er ook ergens in een donker hoekje nog aan een COBOL applicatie te sleutelen of wordt er (zoals bij ons) een zoveelste service geschreven die data (her)kauwt en z'n ding doet. Dat "het grote publiek" die dingen nooit ziet maakt niet dat ze niet bestaan. 90% van wat ik doe zal nooit iemand (lees: eindgebruikers) onder ogen krijgen.

Ja, ook C++ is hier in Nederland heel onpopulair. C#, ASP.NET en JavaScript + PHP zijn hier gangbaar. Je komt ook Java tegen, vooral bij de overheid. En je ziet niet veel Linux, het is nog steeds vooral Windows. Die mannen die aan die oude applicaties sleutelen kom je hier ook zelden tegen. En je hebt hier meer PLC dan embedded programmeurs. Alleen de overheid en de banken hebben een historie van mainframes en die andere oude dingen.

[RobIII]

SymbolicFrank schreef op zaterdag 5 september 2020 @ 01:47:
[...]
Ja, zolang jullie altijd de klant zijn. Op het moment dat je data gaat importeren in de boekhoudingen van je eigen klanten moeten die zelf inloggen en wordt het een heel ander verhaal.

offtopic:
Daar is OAuth juist voor bedoeld... Maar laten we daar dit topic niet verder mee vervuilen.

[SymbolicFrank]

RobIII schreef op zaterdag 5 september 2020 @ 01:50:
[...]

offtopic:
Daar is OAuth juist voor bedoeld... Maar laten we daar dit topic niet verder mee vervuilen.

offtopic:
En dat is dus heel moeilijk te automatiseren, als je er niet van uitgaat dat de persoon die kan inloggen altijd achter zijn computer zit en je die niet iedere keer een popup in zijn gezicht wilt duwen als jouw app wat moet doen.

[Freeaqingme]

SymbolicFrank schreef op zaterdag 5 september 2020 @ 01:54:
[...]

offtopic:
En dat is dus heel moeilijk te automatiseren, als je er niet van uitgaat dat de persoon die kan inloggen altijd achter zijn computer zit en je die niet iedere keer een popup in zijn gezicht wilt duwen als jouw app wat moet doen.

Maar dat is in beginsel toch maar eenmalig? Daar komt een token uitrollen en die kan je vanaf dat moment gebruiken? Of zou jij ook zonder dat ik daar als klant toestemming voor geef aan ExactOnline in mijn administratie willen kunnen?

offtopic:
is dit hip?

[SymbolicFrank]

Freeaqingme schreef op zaterdag 5 september 2020 @ 02:00:
[...]


Maar dat is in beginsel toch maar eenmalig? Daar komt een token uitrollen en die kan je vanaf dat moment gebruiken? Of zou jij ook zonder dat ik daar als klant toestemming voor geef aan ExactOnline in mijn administratie willen kunnen?

offtopic:
is dit hip?

Nee. De klant moet altijd via een browser inloggen op een server van Exact, waarna de browser een tijdelijk token krijgt van die server waarmee het sessie tokens kan aanvragen die 10 minuten geldig zijn. Zo'n tijdelijk token is meestal 24 uur geldig.

Je moet dus de communicatie binnen de browser onderscheppen om het te kunnen automatiseren. Of doen wat Exact heeft gedaan: een procedure publiceren om een sessie token eenmalig aan te vragen (met postman) en dat nooit te laten verlopen.

[Freeaqingme]

SymbolicFrank schreef op zaterdag 5 september 2020 @ 02:08:
[...]


Nee. De klant moet altijd via een browser inloggen op een server van Exact, waarna de browser een tijdelijk token krijgt van die server waarmee het sessie tokens kan aanvragen die 10 minuten geldig zijn. Zo'n tijdelijk token is meestal 24 uur geldig.

Dan zou ik toch nog maar even goed de documentatie doornemen. Mijn klant logt in principe 1 keer in in Exact om de app te authorizeren, en vanaf dat moment kan de app zelf zijn tokens refreshen. Komt mijn klant niet meer aan te pas, en dat draait maanden zonder interrupties.

offtopic:
En zonder wat dan ook te onderscheppen in browsers of anderzins te MITM'en

[ Voor 6% gewijzigd door Freeaqingme op 05-09-2020 02:10 ]

[SymbolicFrank]

Freeaqingme schreef op zaterdag 5 september 2020 @ 02:09:
[...]


Dan zou ik toch nog maar even goed de documentatie doornemen. Mijn klant logt in principe 1 keer in in Exact om de app te authorizeren, en vanaf dat moment kan de app zelf zijn tokens refreshen. Komt mijn klant niet meer aan te pas, en dat draait maanden zonder interrupties.

Dat klopt, zolang de klant zelf die app draait. Hij neemt een abonnement en de app heeft dan alleen toegang tot zijn boekhouding. Als jij een service aanbied om voor al je klanten die een Exact boekhouding hebben deze automatisch bij te werken is het een ander verhaal. Jij hebt zelf namelijk een ander Exact account. Je mag niet bij de boekhouding van je klanten, behalve als zij iedere keer via een browser op de server van Exact inloggen om daar toestemming voor te geven. Dat is OAuth.

De vraag is dan of dat het juiste toegangsprotocol is voor deze toepassing. Maar Google gebruikt het, dus is dat automatisch het beste.

[Gomez12]

Qua Exact-koppeling vraag ik me toch af of jij wel de juiste programmeur bent voor een OAuth-koppeling...

Want ik zie toch wel erg veel van je eerder genoemde woorden terugkomen als ik ga bedenken hoe iemand 2 servers en een embedded chromium nodig heeft voor een OAuth koppeling.

Maar het valt wel enigszins te verklaren met :
- "Ik weet wel hoe het nu gebeurd, ik wil het gewoon graag anders doen."
- "heb je zelf wel eens een HTTP server gebouwd? Ik doe dat regelmatig. Bijna niemand antwoord bevestigend. En het zelfde geldt voor een database, load balancer en al die andere dingen die iedereen gebruikt."

Het verbaast me wat dat betreft nog dat je een embedded chromium gebruikt, had je die ook niet beter zelf kunnen schrijven op een 3e server oid?

De vraag is dan of dat het juiste toegangsprotocol is voor deze toepassing. Maar Google gebruikt het, dus is dat automatisch het beste.

Tja, ik vraag me voornamelijk af of het wel the right man for the right job was.

Ik zie iemand hier vooral high & mighty & extreem vaag vertellen hoe iemand gigantisch complexe dingen waar decennia zo niet eeuwen programmeerwerk inzit dat zelf wel even zegt na te bouwen, maar een exact oauth koppeling dat is dan weer bijna onmogelijk te bouwen...

[SymbolicFrank]

Sorry, ik ben maar een domme sukkel die er niets van begrijpt. Vergeef mij. Ik zal het in het vervolg eerst aan jullie vragen.

[WK100]

SymbolicFrank schreef op zaterdag 5 september 2020 @ 02:18:
[...]
Je mag niet bij de boekhouding van je klanten, behalve als zij iedere keer via een browser op de server van Exact inloggen om daar toestemming voor te geven. Dat is OAuth.

De vraag is dan of dat het juiste toegangsprotocol is voor deze toepassing. Maar Google gebruikt het, dus is dat automatisch het beste.

Het eerste is niet waar als je het correct implementeert, en dat laatste is te kort door de bocht. Zie deze passage uit RFC 6749.
Een mailtje van Exact uit 2018 gaat nader in op hun implementatie van de refresh tokens:


Ik denk dat dit voldoende informatie is om je probleem op te lossen

[Erapaz]

SymbolicFrank schreef op donderdag 27 augustus 2020 @ 16:16:
Is dat hier al voorbij gekomen?

SQL-databases schalen slecht en zijn moeilijk te distribueren. Je krijgt dan al snel no-sql databases, die vooral platte tabellen met sleutels en waardes opslaan. Maar als je daarop selecties wilt draaien, moet je iedere keer een heleboel data over de lijn trekken. Het is daarom eenvoudiger om voor iedere selectie een aparte server te maken.

Dan zit je met verschillenden dingen. Om te beginnen, als je er een aparte IIS of Apache server met zijn eigen SQL-database voor gebruikt, nemen ze veel ruimte en capaciteit in beslag. Maar dat hoeft natuurlijk niet. Het is heel eenvoudig om je eigen, unieke protocol te gebruiken en aan een poort te hangen. En als het absoluut HTTP moet zijn, kun je in C# bijvoorbeeld een HttpListener gebruiken.

Daarna zit je met de distributie en de beveiliging. SSL zegt bijvoorbeeld niets over de identiteit als je geen certificaten gebruikt. En om nou iedere micro-server zijn eigen certificaat te geven gaat wel erg ver. Ook is dat een vrij zware versleuteling die niet eenvoudig zelf te bouwen is.

En je wil waarschijnlijk die dingen "on-demand" kunnen opstarten. Het is het mooiste als ze zelf schalen: je verzoekt de hoofd-server om een bepaalde service, die controleert je identiteit en geeft je de sleutel en het adres van de server. Als die service nog niet actief is of de belasting te hoog is, start hij een nieuwe, met zijn eigen adres (minimaal een ander poortnummer). En als die service een tijdje geen aanvragen krijgt, geeft hij dat door aan de hoofd-server en sluit zichzelf af. Je moet natuurlijk ook iets inbouwen waardoor je kunt controleren of ze nog actief zijn.

Ik heb zoiets een paar keer gebouwd en vroeg me af of er meer mensen mee bezig zijn, en of hier al een kant en klare oplossing voor bestaat.

Dat dit topic met zo’n vage vraag nog open is. Welk probleem probeer je op te lossen? Tegen de tijd dat je zoveel gebruikers/data hebt dat je SQL database niet meer schaalt heb je in het algemeen al genoeg omzet voor een dik engineering team waarmee je je probleem kan oplossen. Ga nou eerst maar eens die applicatie bouwen op 1 server met een cold standby, schalen komt later wel. Genoeg projecten financieel de mist is zien gaan omdat de klant een ultiem schaalbare oplossing wilde van dag 1.

eBay gebruikt ook gewoon een Oracle DB voor transactie data, zoals het bieden en winnen van een veiling. Daar zit dan een Queue oplossing voor zodat de webapplicatie onafhankelijk van de DB kan schalen en de requests netjes op volgorde via de Queue daar kunnen worden aangeboden.

NoSql heeft zijn plaats, maar je kunt niet zomaar roepen dat SQL niet schaalt en dat je daarom maar NoSQL gaat gebruiken. Elk probleem heeft zijn oplossing.

Qua OAuth, het idee is dat jij als Service Provider een dienst aanbied waarbij een andere partij de Identity Provider is. Je klant logt in bij exact en krijgt een token wat hij weer bij jou aanbiedt, vaak via HTTP (bijv. JWT). Door dit token te valideren tegen de public key van de IdP weet je dat het van hun afkomstig is. De refresh token kun je vervolgens gebruiken om steeds een nieuwe sessie op te halen bij de IdP voor de gebruiker. Zo kun je dus juist voor iemand anders bij een derde partij inloggen.

[TweakMDS]

SymbolicFrank schreef op zaterdag 5 september 2020 @ 01:47:
Ja, ook C++ is hier in Nederland heel onpopulair. C#, ASP.NET en JavaScript + PHP zijn hier gangbaar. Je komt ook Java tegen, vooral bij de overheid. En je ziet niet veel Linux, het is nog steeds vooral Windows. Die mannen die aan die oude applicaties sleutelen kom je hier ook zelden tegen. En je hebt hier meer PLC dan embedded programmeurs. Alleen de overheid en de banken hebben een historie van mainframes en die andere oude dingen.

Even los van de Exact discussie, waar baseer je deze conclusies op? Ik zie in Nederland juist nog meer C++ dan ik zou verwachten. Bijna overal waar iets embedded wordt gemaakt ben ik C++ tegen gekomen, en toen ik op de TUE zat was dit juist de taal die werd geleerd (na C), geen java, geen C# (bestond ook nog niet).
Misschien is het goed om wat meer context te geven over wat je doet en waar je zoal komt. Ik heb zelf een achtergrond in de logistiek en telecom. Daar kom ik zelf bij onze klanten ook nog aardig veel "legacy" tegen. Dat is niet enkel bij banken en overheden, hoewel banken wel grotere problemen lijken te hebben met uitfaseren van legacy systemen, waar Telecom operators gelukkig nog wel eens een modernisering toepassen.

Bij web development, apps, en end-user applicaties zie ik zelf ook wat meer high level talen, maar dat is enkel het oppervlak van wat er gebeurt.
Op de desktop zie ik bijna alleen windows of mac. Aan de server kant zie ook nog steeds een toename van Linux, zeker ook als je docker en k8s mee gaat tellen.

[Webgnome]

SymbolicFrank schreef op zaterdag 5 september 2020 @ 01:17:
Er bestaan al veel methodes om tot een resultaat te komen. De gebruikte zijn vooral afhankelijk van de populariteit, die weer grotendeels afhankelijk is van wat de ontwikkelaars geleerd hebben op school en hoe eenvoudig het is om over te schakelen naar een nieuwe manier.

Samen als groep bepalen de ontwikkelaars zo hoe je het beste een applicatie kunt maken. En tegenwoordig is dat meestal een webapp en soms embedded. De rest is vooral onderhoud van bestaande applicaties, onderzoek en ontwikkeling.

Die populariteit wordt ook heel sterk beïnvloed door hoe de dingen die de grote 3 doen er aan de buitenkant uitzien. Zo zie je bijvoorbeeld steeds vaker dat je de gebruikersnaam en het wachtwoord op verschillende pagina's moet invoeren. Ook hun specificaties zijn heel populair.

Bijvoorbeeld: Exact gebruikt REST met OAuth 2.0 authenticatie. Want dat doet iedereen. Nou is hun implementatie nogal knullig, wat het niet eenvoudiger maakt. Ik heb dus een Exact app gemaakt, die alles implementeerde volgens hun specificaties, waar ik twee servers en een embedded Chromium voor nodig had om het te kunnen automatiseren. Om er dan achteraf achter te komen dat het zo ingewikkeld is dat vrijwel niemand het voor elkaar krijgt en de sessie-sleutel dus statisch gegenereerd wordt en nooit verloopt...


Maar zolang we er van uitgaan dat alle bollebozen bij Google werken en het dus geen zin heeft om zelf onderzoek en ontwikkeling te doen, hebben we ook geen inspraak. En dat onderzoek is ook een geweldige manier om te begrijpen hoe de dingen nu in elkaar zitten en wat de mogelijkheden zijn.

Weet niet waar je deze wijsheid vandaan haalt maar de Exact rest api is er eentje die bijna volgens het boekje verloopt. Tuurlijk er zitten gekkigheden in (zoals bijna alle entiteiten hebben een ID maar invoices, als ik het goed herinner, heeft een INVOICE id..)

Dat je inhoudelijke kennis dient te hebben van wat exact is en doet staat daar los van. Het benoemen dat je er twee servers voor nodig hebt kunnen we natuurlijk niets mee als we de case niet kennen.

SymbolicFrank schreef op zaterdag 5 september 2020 @ 02:18:
[...]


Dat klopt, zolang de klant zelf die app draait. Hij neemt een abonnement en de app heeft dan alleen toegang tot zijn boekhouding. Als jij een service aanbied om voor al je klanten die een Exact boekhouding hebben deze automatisch bij te werken is het een ander verhaal. Jij hebt zelf namelijk een ander Exact account. Je mag niet bij de boekhouding van je klanten, behalve als zij iedere keer via een browser op de server van Exact inloggen om daar toestemming voor te geven. Dat is OAuth.

De vraag is dan of dat het juiste toegangsprotocol is voor deze toepassing. Maar Google gebruikt het, dus is dat automatisch het beste.

offtopic:
Als ik dit zo lees heb ik maar een tip. Maak een standaard applicatie en zorg dat in de app center van Exact je de klant zelf een app in elkaar laat zetten met naam, client id en callback url etc. Zorg dat de klant met zijn credentials daar op kan inloggen via oauth in jou eigen applicatie en dan heeft de persoon in kwestie / app in kwestie als het goed is al toegang tot de juiste administraties. Dat hoeft maar een keer in het half jaar als je het goed doet. En als de token onverhoopt toch verloopt leg de klant uit waar dat hij de token kan verversen.

[ Voor 22% gewijzigd door Webgnome op 05-09-2020 10:35 ]

[technorabilia]

SymbolicFrank schreef op zaterdag 5 september 2020 @ 02:42:
Sorry, ik ben maar een domme sukkel die er niets van begrijpt. Vergeef mij. Ik zal het in het vervolg eerst aan jullie vragen.

Niemand zegt dat. Ik denk dat je instelling van zaken van de andere kant bekijken een goede instelling is. Ik heb zelf een vergelijkbare instelling. Ik wil graag van de hoed en de rand weten en graag méér. Ik heb wel in de loop der jaren geleerd om een goede balans te vinden tussen mijn ideeën en wat in de praktijk het beste is. Ik ben (was) vaak erg (te) enthousiast om al mijn ideeën in de praktijk toe te passen. Ondanks dat het vaak best goede ideeën zijn *kuch*, is het in de praktijk vaak beter om een iets "conservatievere" houding aan te nemen. Uiteindelijk ben je (meestal) niet alleen op de wereld en moeten dingen ook worden onderhouden en worden begrepen door anderen. Dit wil niet zeggen dat je je ideeën moet laten varen, maar de situatie ook van andere perspectieven te bekijken (dat geldt voor de IT maar is eigenlijk best toepasbaar op alle aspecten van het leven). Ik zie mij als een redelijk intelligent persoon maar een feit is dat ik gewoon niet alles weet, en er meer is dan mijn beperkte blikveld. Aan het begin van een leven/carrière misschien wat ontluisterend, maar hey dat is hoe het is. Het scheelt een hoop als je dat accepteert. Daar wordt het alleen maar beter van. Voor iedereen.

Ik wil niet belerend zijn. Dit is mijn ervaring. Want een andere kijk op de zaak blijft natuurlijk goed. Zo ontstaan nieuwe ideeën en implementaties. Ook al zit je er meer dan een keer naast kan het voor meer inzicht zorgen en innovatie. Toch is het meestal zoals ik schrijf.

[SymbolicFrank]

Ok. De Exact API werkt naar verwachting als je een webapp hebt. Dan heb je inderdaad geen embedded Chromium nodig, want dan draait het al in een browser en werkt de redirect ook. In alle andere gevallen is hij bijna onbruikbaar. Dat leek me duidelijk, maar dat was het blijkbaar niet.

"Als je alleen een hamer webapp hebt, lijkt alles op een spijker alleen HTTP en browsers te bestaan."

Maar ik heb het wel weer gehad.

[RobIII]

SymbolicFrank schreef op dinsdag 8 september 2020 @ 00:03:
Ok. De Exact API werkt naar verwachting als je een webapp hebt. Dan heb je inderdaad geen embedded Chromium nodig, want dan draait het al in een browser en werkt de redirect ook. In alle andere gevallen is hij bijna onbruikbaar. Dat leek me duidelijk, maar dat was het blijkbaar niet.

"Als je alleen een hamer webapp hebt, lijkt alles op een spijker alleen HTTP en browsers te bestaan."

RobIII schreef op zaterdag 5 september 2020 @ 01:30:
[...]

Als iemand die zelf de OAuth met Exact geïmplementeerd heeft in een headless applicatie (een soort batch factuur importeer ding)

SymbolicFrank schreef op dinsdag 8 september 2020 @ 00:03:
Maar ik heb het wel weer gehad.

Jammer. Ik zou toch écht eens kijken of je misschien iets kritischer naar jezelf kunt zijn. Niemand weet alles en we hebben allemaal onze problemen waar we tegenaan lopen. En we leren allemaal elke dag.

[SymbolicFrank]

SndBastard schreef op zaterdag 5 september 2020 @ 09:26:
[...]


Even los van de Exact discussie, waar baseer je deze conclusies op? Ik zie in Nederland juist nog meer C++ dan ik zou verwachten. Bijna overal waar iets embedded wordt gemaakt ben ik C++ tegen gekomen, en toen ik op de TUE zat was dit juist de taal die werd geleerd (na C), geen java, geen C# (bestond ook nog niet).
Misschien is het goed om wat meer context te geven over wat je doet en waar je zoal komt. Ik heb zelf een achtergrond in de logistiek en telecom. Daar kom ik zelf bij onze klanten ook nog aardig veel "legacy" tegen. Dat is niet enkel bij banken en overheden, hoewel banken wel grotere problemen lijken te hebben met uitfaseren van legacy systemen, waar Telecom operators gelukkig nog wel eens een modernisering toepassen.

Bij web development, apps, en end-user applicaties zie ik zelf ook wat meer high level talen, maar dat is enkel het oppervlak van wat er gebeurt.
Op de desktop zie ik bijna alleen windows of mac. Aan de server kant zie ook nog steeds een toename van Linux, zeker ook als je docker en k8s mee gaat tellen.

Ik doe al jarenlang vooral C++ omdat er niet veel mensen meer zijn die dat kunnen. En veel toepassingen lenen zich erg slecht om er een webapp van te maken, meestal als je ook hardware hebt, zoals een kassasysteem, meetapparatuur of productiemachines in een fabriek (daar heb ik allemaal aan gewerkt, alhoewel het merendeel in C# en Delphi was).

Voor mobiel is het heel variabel: alhoewel daar ook de meeste applicaties eigenlijk webapps zijn (die vaak lokaal draaien), zie je daar ook andere dingen, meestal ObjectiveC voor Apple en Java voor Android, maar C++ kom je ook tegen. Ook mijn laatste applicatie op een Mac was in C++ (en het is interessant om te zien dat de kernel van een Mac meer Apple-specifieke code bevat, die vaak al 30+ jaar oud is, dan BSD code).

Voor webontwikkeling doe ik meestal de bibliotheken, interfaces en backend, alhoewel ik ook een keer een site volledig in JavaScript heb gebouwd. Het eerste wat hij deed: document.body.innerHTML = "". Dat werkt vooral prachtig om alles mooi te laten schalen en in kolommen in te delen waar nodig, zonder CSS problemen, maar Google begrijpt dat niet zo goed, dus moet je alle zoekwoorden toch in de html koptekst stoppen.

[SymbolicFrank]

RobIII schreef op dinsdag 8 september 2020 @ 00:45:
Jammer. Ik zou toch écht eens kijken of je misschien iets kritischer naar jezelf kunt zijn. Niemand weet alles en we hebben allemaal onze problemen waar we tegenaan lopen. En we leren allemaal elke dag.

Ik ben autodidact. Ik heb alleen Mavo. Ik vond (onder andere) elektronica en computers leuk, dus ik speel er al 40 jaar mee. En daar ik het niet op school heb geleerd, moet ik het zelf uitzoeken. Experimenteren en een functionele demo maken. Te beginnen met mijn eigen computer bouwen op een breadboard, zelf een besturingssysteem, programmeertaal, editor en WIMPS GUI schrijven (alhoewel dat op een DOS computer was). En dat doe ik nog steeds als ik iets tegenkom wat ik nog niet ken: uitzoeken en zelf bouwen.

De communicatie met andere IT-ers verloopt soms wat stroef. Vroeger maakten we bijvoorbeeld zelf onze eigen objecten van gelinkte lijsten, in C of Turbo Pascal. Met pointers. De eerste constructies (types) in die talen die dat ondersteunden heetten ook "object". En die werkten nog steeds met pointers. De laatste keer dat ik daar hier over heb geposts viel ook iedereen over me heen, want een object maak je niet zo, een object is een instance. Je maakt classes en er komen nergens pointers aan te pas.

Of wat er bij een webapp allemaal achter de schermen gebeurt, natuurlijk.

[Creepy]

Jammer dat je niet reageert op de vragen van Rob over het nodig hebben van 2 servers voor de oauth ondersteuning in Exact, terwijl Rob je vertelt dat hij een headless appliciatie heeft geschreven waar het prima mee werkt. Andere vragen lijk je ook te negeren om vervolgens een ongerelateerd verhaal te schrijven waar andere mensen dan alweer vragen bij gaan stellen.Dat lijk je nu weer te doen met met je verhaal over C/Pascal waarin je naar mijn idee een struct door elkaar haalt met een object.

Omdat je niet inhoudelijk op vragen lijkt te willen reageren en het topic alle kanten op springt, ga ik dit topic dan ook sluiten.