Bouwen van een platform discussie, advies en fun topic.

Pagina: 1
Acties:
  • 877 views

Acties:
  • 0 Henk 'm!

  • R.G
  • Registratie: Januari 2009
  • Laatst online: 12:57
Goedendag mede tweakers en devs,

Momenteel heb ik een idee bedacht en wil ik het nu eens vanaf aankomende week ook echt oppakken en gaan uitvoeren. Geen execuses meer en geen wacht tijd gewoon beginnen.
Oh en nee het is geen school opdracht en of opdracht het is een hobby projectje waarmee ik hoop ooit mijn vaste lasten te kunnen opbrengen en van te leven.


Diegene die mij assisteren en of geholpen hebben beloof ik dat als dit platform eenmaal bestaat ik ze niet vergeet.


-------------------------------------------------------------------------------------------------------------------
Requirements / eisen van het platform:
  • Platform moet overna worden gedacht en vanaf de fundering goed opgebouwd zijn.
  • Platform moet tasks kunnen uitvoeren voor minimaal 1.000.000.000 gebruikers.
  • Platform moet een api hebben waarmee externe apps kunnen communiceren.
  • Platform moet bruikbaar zijn via een app op android
  • Platform moet bruikbaar zijn via een app op IOS
  • Platform moet bruikbaar zijn via een app op Windows tablets
  • Platform moet video beelden, gifs, plaatjes ondersteunen
  • Platform moet externe services kunnen koppelen, dit betekent dat je dynamisch iets nieuws zou kunnen toevoegen
  • Platform moet future proof zijn voor web3.0
  • Platform moet een leden pagina hebben.
Mijn eerste vraag is al: zijn dit goede "Requirements" of zou iemand deze anders verwoorden?
Tweede vraag: Is het van belang en of handig om een architectuur ontwerp te maken
-------------------------------------------------------------------------------------------------------------------
Keuze software:

Liefst een keer code maken en daaruit voor de verschillende OS en apparaten een native versie te generen.
  • Xamarin, zou dit vroeger zijn geweest, maar volgens mij is Xamarin niet meer zo future proof en wordt ook niet meer echt ontwikkelt en gebruikt toch? Wat zou hier een goede vervangen voor zijn?
  • Flutter voor apps om platform te benaderen, volgens mij is dit het modernst en werkt dit ook voor cross platforms zoals IOS, android toch?
  • Database, Postgresql, denken jullie dat deze database 1.000.000 database requests kan afhandelen op een single VPS dedicated postgresql installatie?
Docker / kubernetes oplossing
Kan je een docker image maken van het platform en dit gebruiken om nieuwe machines / containers op te spinnen. Zoals de postgresql service en het platform. Hoe pas je hier container health check op, dus wanneer een container overbelast raakt en of down gaat, dat kubernetes dan een nieuwe container opstart en of het probleem probeert te verhelpen?

Issue hier is al deze containers moeten naar dezeflde datasource / data bron kijken.
De containers worden dus alleen opgestart / aangemaakt als de huidige server niet meer de requesten aankan. Kan je dit software technisch oplossen?

overzicht images:
  • NodeJS, image, liefst denk ik een compose file?
  • Postgresql, image, liefst denk ik een compose file?
Waar en hoe bouw je scaling voor deze 2 images? Moet je daar iets voor regelen in de image zelf of erbuiten om of beiden?
Hoe maak je een image? Moet je hiervoor eerst een machine installeren met bijvoorbeeld Ubuntu server en helemaal inrichten en dan daarvan een image maken en deze uploaden op docker image hosting site?
-------------------------------------------------- -----------------------------------------------------------------

Cloud:
Hoe zet je het platform in de cloud , waarop draait het platform.

Eigen hersen spinsel :
  • NodeJS, Server en tevens Rest API? Kan je met NodeJS opschalen?
  • PostgreSQL, Service voor data opslag?
Dan zou je minimaal een eigen vps nodig hebben om een NodeJS server en een postgreSQL service te kunnen installeren of niet?


Hoe zit het met je cloud / host omgeving. Ik zie bijvoorbeeld host providers die ondersteunen alleen een ww folder of home folder waarin je static html , css , javascript , videos en afbeeldingen kan neerzetten.

Soms kan je nog php of wordpess installeren en dan houdt het wel op.
Wil je zoiets uberhaupt daar hosten of vereist mijn idee al gauw een eigen vps?
Is het realistisch om te denken dat een VPS wel 1.000.000 miljoen requesten kan verwerken.

-------------------------------------------------------------------------------------------------------------------
Web3.0 ondersteuning:
Hoe ontwikkel je het platform zo dat het web3.0 ondersteunt?
Hoe ontwikkel je de Flutter apps zo dat het web3.0 ondersteunt?


Ps: bij nieuwe info zal ik deze post updaten / aanpassen op basis van nieuwe feedback en discussie hier.
( lijst maken in een topic is een drama ofniet?, je krijgt echt de html te zien? Met de blokhaken met LI )

TLDR:
Ik wil een Platform bouwen, welke geschikte tools passen daar het best bij om aan de requirements te voldoen.

Opsomssing vragen
1e vraag: Zijn dit goede "Requirements" of zou iemand deze anders verwoorden? Zie requirements en geef een verbeterd voorbeeld.
2e vraag: Is het van belang en of handig om een architectuur ontwerp te maken
3e vraag: Xamarin, Flutter goede vervanger voor maken cross platform apps?
4e vraag: NodeJS, is dat geschikt om 1.0000.0000.0000 requesten te verwerken?
5e vraag: PostgreSQL, is dat geschikt om 1.0000.0000.0000 requesten te verwerken?
6e vraag: Waar en hoe bouw je scaling voor container images?
7e vraag: Hoe bouw je een docker image van een clean opgerichte machine?
8e vraag: Hoe zet je het platform weg in de cloud?
9e vraag: Hoe ontwikkel je een website die web3.0 ondersteunt?
10e vraag: Hoe ontwikkel je een app die web3.0 ondersteunt?

Acties:
  • +1 Henk 'm!

  • ieperlingetje
  • Registratie: September 2007
  • Niet online
Ik denk dat je je eerst wat in de basics zult moeten inlezen. Leer eerst wat docker is, wat Kubernetes is, wat een VPS is.Nu lijkt het er op dat je wat hippe termen hebt gevonden maar geen idee hebt wat je ermee moet aanvangen. De getallen die je noemt qua requests / aantal queries zul je met geen enkele single instance kunnen verwerken.

[ Voor 19% gewijzigd door ieperlingetje op 16-06-2024 17:59 ]

Tijdmachine | Nieuws trends


Acties:
  • +1 Henk 'm!

  • CodeCaster
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

Qua requests: íeder platform kan miljoenen requests afhandelen als je geen limiet stelt aan de periode waarin dit moet gebeuren. Deze eeuw moet zeker lukken.

Web 3.0: geef me één Bitcoin en ik zal zien wat ik voor je kan doen.

"Dynamisch": het grootste buzzword in de programmeerwereld sinds circa 2000. Alles is dynamisch.

Schaling: dat is niet een bitje dat je aanzet op een container, dat is een ontwerpfilosofie waar je vanaf het begin af aan rekening mee houdt.

Laatste opmerkingen: een idee is een stuiver waard, een uitwerking miljoenen (of hoe ging die quote?). Begin met bouwen en overtuig anderen (met name betalende klanten) dat je iets in handen hebt. Tot die tijd ben je niet zoveel waard, en hoef je je echt geen zorgen te maken dat de volledige op dat moment wakkere, internettende wereld op jouw platform zit.

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...


Acties:
  • 0 Henk 'm!

  • R.G
  • Registratie: Januari 2009
  • Laatst online: 12:57
ieperlingetje schreef op zondag 16 juni 2024 @ 17:57:
Ik denk dat je je eerst wat in de basics zult moeten inlezen. Leer eerst wat docker is, wat Kubernetes is, wat een VPS is.Nu lijkt het er op dat je wat hippe termen hebt gevonden maar geen idee hebt wat je ermee moet aanvangen. De getallen die je noemt qua requests / aantal queries zul je met geen enkele single instance kunnen verwerken.
Daar ben ik al mee bezig maar goede tip.
Vps is een server in de cloud met root rechten
Kubernetes is een orchestra tool waarmee je containers beheerst en managed.
Docker is een framework waarmee je containers beheerd . Container is een soort virutele machine die de kernel gebruikt van de host machines om nieuwe machines te starten.


Wel moet ik ook rekening met het beveiliigen van de data ivm de wetgeving en privacy. Wat ook een hele uitdaging zal zijn.

[ Voor 19% gewijzigd door R.G op 16-06-2024 18:05 ]


Acties:
  • 0 Henk 'm!

  • R.G
  • Registratie: Januari 2009
  • Laatst online: 12:57
CodeCaster schreef op zondag 16 juni 2024 @ 18:01:
Qua requests: íeder platform kan miljoenen requests afhandelen als je geen limiet stelt aan de periode waarin dit moet gebeuren. Deze eeuw moet zeker lukken.

Web 3.0: geef me één Bitcoin en ik zal zien wat ik voor je kan doen.

"Dynamisch": het grootste buzzword in de programmeerwereld sinds circa 2000. Alles is dynamisch.

Schaling: dat is niet een bitje dat je aanzet op een container, dat is een ontwerpfilosofie waar je vanaf het begin af aan rekening mee houdt.

Laatste opmerkingen: een idee is een stuiver waard, een uitwerking miljoenen (of hoe ging die quote?). Begin met bouwen en overtuig anderen (met name betalende klanten) dat je iets in handen hebt. Tot die tijd ben je niet zoveel waard, en hoef je je echt geen zorgen te maken dat de volledige op dat moment wakkere, internettende wereld op jouw platform zit.
Het idee van het platform is dat dit platform voor iedereen toegangelijk is en voor alle mensen in de wereld een probleem oplost. Ik kijk niet naar nl alleen , ik heb een visie dat dit voor iedereen is.

Dus billions users uiteindelijk. Denk alleen Al stel dat india en midden oosten en china 20% van hun bevolking gebruikt het platform hoeveel users heb je dan wel niet?

Acties:
  • +2 Henk 'm!

  • CodeCaster
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

R.G schreef op zondag 16 juni 2024 @ 18:07:
[...]


Het idee van het platform is dat dit platform voor iedereen toegangelijk is en voor alle mensen in de wereld een probleem oplost. Ik kijk niet naar nl alleen , ik heb een visie dat dit voor iedereen is.

Dus billions users uiteindelijk. Denk alleen Al stel dat india en midden oosten en china 20% van hun bevolking gebruikt het platform hoeveel users heb je dan wel niet?
Zulke ideeën heb ik dagelijks, ze komen op als poepen. Laat maar weten wanneer je iets hebt draaien.

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...


Acties:
  • 0 Henk 'm!

  • R.G
  • Registratie: Januari 2009
  • Laatst online: 12:57
Stel de website naam van platform is.

Platform.anything.com

Nodejs server 1 is overbelast

Alleen de link van de website moet wel zelfde blijven.

Hoe weet een nameserver dat / domein isp?

Heb je Dan een device bijv load balancer met public IP xxx en die stuurt door naar intern device 1 of 2 en Device 1 of 2 gaan beiden naar postgresql db server?

Want je kan niet 2 devices zelfde ip geven toch?

Acties:
  • +2 Henk 'm!

  • Merethil
  • Registratie: December 2008
  • Laatst online: 28-09 21:34
R.G schreef op zondag 16 juni 2024 @ 18:20:
Stel de website naam van platform is.

Platform.anything.com

Nodejs server 1 is overbelast

Alleen de link van de website moet wel zelfde blijven.

Hoe weet een nameserver dat / domein isp?

Heb je Dan een device bijv load balancer met public IP xxx en die stuurt door naar intern device 1 of 2 en Device 1 of 2 gaan beiden naar postgresql db server?

Want je kan niet 2 devices zelfde ip geven toch?
Daar heb je inderdaad load balancers voor. Als je iets als Kubernetes gebruikt dan heb je ook nog een autoscaler die bepaalt wanneer oude pods vervangen of nieuwe pods bijgezet moeten worden; dit kan je met iets als KEDA helemaal customizen zodat hij op basis van eigen metrics wordt gestuurd. Naast pods kan je zo ook nodes opschalen en eventueel ook nodes in specifieke zones bijzetten als een andere zone eruit ligt.

Dit soort zaken vereist veel tweaking, correct opzetten van je code en rekening houden met o.a. downtime, scaling-acties, verplaatsen van je workload als je netwerk in een regio eruit ligt etc. Allemaal erg fijn om op orde te hebben, maar ongeveer 1000 stappen verwijderd van het traject waar je nu nog in zit; bepalen hoe je start en wat je gaat doen met je project.

Even wat dooddoeners die toch passen: Rome is niet in één dag gebouwd, Facebook heeft er jaren over gedaan om van 1 naar 1 miljoen gebruikers te gaan en zelfs Pokémon Go lag er de eerste dagen uit omdat ze niet in één keer alle load aan konden, zelfs terwijl ze heel gefaseerd uitrolden over de hele wereld heen.
Begin dus vooral met een solide basis, maar maak je niet vanaf moment 1 druk om miljoenen gelijktijdige gebruikers. Elk project start klein en zou een MVP moeten hebben waarbij je waarde toevoegt. Als je userbase dan groeit kan je op basis van de gemeten waardes aan gebruik, de feedback van de gebruikers en de inzichten in belangrijkste features bepalen wat je vervolgstappen zijn. Tot die tijd is alles heel leuk bedacht, maar een solide infrastructuur zonder gebruikers is vooral erg duur en zonde van je tijd ;)

Acties:
  • +3 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
R.G schreef op zondag 16 juni 2024 @ 17:51:
het is een hobby projectje waarmee ik hoop ooit mijn vaste lasten te kunnen opbrengen en van te leven.
[...]
  • Platform moet tasks kunnen uitvoeren voor minimaal 1.000.000.000 gebruikers.
Aparte hobby heb je.
Je beseft dat er, op dit moment, pakweg 8.1 miljard mensen op deze planeet rondlopen? Dat is 1 op de 8 personen die je jouw dienst wil laten gebruiken. Er zijn bar weinig bedrijven die dat halen. Dan hebben we 't dus over Facebooks, Googles, Amazons, dat soort bedrijven. Dat is geen "hobby" meer :>
R.G schreef op zondag 16 juni 2024 @ 17:51:
Mijn eerste vraag is al: zijn dit goede "Requirements" of zou iemand deze anders verwoorden?
Ik wil dit geen requirements noemen maar hardop (héél hard) dagdromen over hoe hou zou zijn om Mark Zuckerberg te zijn.
R.G schreef op zondag 16 juni 2024 @ 17:51:
Tweede vraag: Is het van belang en of handig om een architectuur ontwerp te maken
Ik denk dat als je die vraag moet stellen terwijl je een platform wil gaan opzetten voor minimaal een miljard gebruikers je niet de juiste persoon bent voor dat platform ;)


Er zijn tot nu toe hele nette antwoorden gegeven die met je meedoen met je "what if"-spelletje, maar ik ga je denk ik even wat realiteit voorhouden en je teleurstelling naar voren halen in de tijd: veruit de meeste vragen zou je - als je énigszins kans zou maken zo'n platform in de verste verte waarheid te kunnen maken - helemaal niet stellen. Je, we zijn allemaal ergens begonnen, en dat moet ook, maar dan moet je ook realistische(re) doelen stellen. Wat je nu doet is "ik vind maanlandingen mooi, ik heb er wel eens plaatjes van gezien, ik wil volgend jaar op planeet X staan met mijn eigen, in mijn uppie gebouwde, raket waarbij ik tot op elk schroefje zelf ontworpen en gemaakt heb en daar binnen een week een complete beschaving optuigen en daar dan mijn hobby van maken.

Realistischer: begin eens met een platform en richt je op 100, of 1.000 gebruikers en als je die mijlpaal (en dat is het dan!) bereikt kun je misschien eens gaan nadenken over aannemen van personeel en op zoek naar kapitaal enzovoorts enzovoorts en héél misschien ben je een van de lucky few die de 1 of 10 of 100 miljoen gebruikers haalt. En tegen die tijd heb je als het goed is een heleboel capabele mensen die je betaalt om al die vragen van je te beantwoorden én voor je op te lossen.
R.G schreef op zondag 16 juni 2024 @ 17:51:
4e vraag: NodeJS, is dat geschikt om 1.0000.0000.0000 requesten te verwerken?
5e vraag: PostgreSQL, is dat geschikt om 1.0000.0000.0000 requesten te verwerken?
Per eeuw? Vast wel. Per jaar? Oef, dat wordt al lastig. Per maand? Per dag? Per uur? Forgetaboutit. Heb je de nullen (en de decimaalscheidingstekens) in je eigen vraag al eens goed bekeken?

[ Voor 16% gewijzigd door RobIII op 16-06-2024 20:50 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • R.G
  • Registratie: Januari 2009
  • Laatst online: 12:57
RobIII schreef op zondag 16 juni 2024 @ 20:36:
[...]

Aparte hobby heb je.
Je beseft dat er, op dit moment, pakweg 8.1 miljard mensen op deze planeet rondlopen? Dat is 1 op de 8 personen die je jouw dienst wil laten gebruiken. Er zijn bar weinig bedrijven die dat halen. Dan hebben we 't dus over Facebooks, Googles, Amazons, dat soort bedrijven. Dat is geen "hobby" meer :>


[...]

Ik wil dit geen requirements noemen maar hardop (héél hard) dagdromen over hoe hou zou zijn om Mark Zuckerberg te zijn.


[...]

Ik denk dat als je die vraag moet stellen terwijl je een platform wil gaan opzetten voor minimaal een miljard gebruikers je niet de juiste persoon bent voor dat platform ;)


Er zijn tot nu toe hele nette antwoorden gegeven die met je meedoen met je "what if"-spelletje, maar ik ga je denk ik even wat realiteit voorhouden en je teleurstelling naar voren halen in de tijd: veruit de meeste vragen zou je - als je énigszins kans zou maken zo'n platform in de verste verte waarheid te kunnen maken - helemaal niet stellen. Je, we zijn allemaal ergens begonnen, en dat moet ook, maar dan moet je ook realistische(re) doelen stellen. Wat je nu doet is "ik vind maanlandingen mooi, ik heb er wel eens plaatjes van gezien, ik wil volgend jaar op planeet X staan met mijn eigen, in mijn uppie gebouwde, raket en daar binnen een week een complete beschaving optuigen en daar dan mijn hobby van maken.

Realistischer: begin eens met een platform en richt je op 100, of 1.000 gebruikers en als je die mijlpaal (en dat is het dan!) bereikt kun je misschien eens gaan nadenken over aannemen van personeel en op zoek naar kapitaal enzovoorts enzovoorts en héél misschien ben je een van de lucky few die de 1 of 10 of 100 miljoen gebruikers haalt. En tegen die tijd heb je als het goed is een heleboel capabele mensen die je betaalt om al die vragen van je te beantwoorden én voor je op te lossen.
Klopt, alleen het architectuur plaatje kan ook in je hoofd zitten zonder dat je al die tijd steekt in het mooi en netjes neer te zetten in een file of blaadje.

ik ga je tip aannemen laat ik eens minimaal eerst 100 gebruikers gaan regelen.
Alleen ik zeg juist explicitiet meerder gebruikers, omdat ik uiteindelijk niet tegen een muur aanlopen dat het blijkt dat ik niet kan opscalen naar 100.000 + users plus.

Liever een hele karig eerst platform die zon sterke basis en fundering heeft dat ik later meerwaarde kan toevoegen zonder dat de onderste plank / fundering herbouwd moet worden.

Ik heb altijd geleerd van mijn programmeer leraar vroeger, zorg voor een sterke fundering en maak die adaptive modulair, maar heel eerlijk vaak wordt het dan toch een chaos of er wordt teveel tegelijk gedaan waardoor het allemala net niet is.


Over de requirements die leiden vaak tot use cases.

Als x wil ik dat dit kan y zodat Z.

volgens mij zijn requirements gewoon eisen / wat iets moet kunnen.
Die je dan gebruiken als referentie om je eindproduct / platform te testen.

Requirements -> Test cases -> acceptatie

en de requirements zeggen ook vaak wat de functionaliteit en eigenschappen zijn van het platform.


Zoals ik melde van alle opties zoals discussie forum op het platform, misschien is dat niet de meerwaarde of het belangrijkste om dat toe te voegen en kan dat een mindere requirement zijn of zoals het MOSCOW model

a could zijn.

Maar hoe lastig zal het zijn om op een gegeven moment als nog een discussie feature toe te voegen waar gebruikers met elkaar kunnen samenwerken / delen en praten?

Dat vind ik wel best meerwaarde hebben.

Platform zou bijvoorbeeld ook een ticket systeem kunnen gebruiken voor hulp voor gebruikers.
Alleen kan je dan niet beter weer een pakket aanschaffen die al 10+ jaar ervaring hebben en daar al een goed product voor hebben zoals JIRA , GITLAB dat je dat dan aanschaft en implementeerd als addon?


ik denk even hard op hoor.

Acties:
  • +1 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
R.G schreef op zondag 16 juni 2024 @ 20:50:
Over de requirements die leiden vaak tot use cases.
Als je nog vóór aanvang van je project al requirements hebt dat 't een achtste van de wereldbevolking moet kunnen bedienen en een biljoen(!) requests (per ongedefinieerde tijdseenheid...) aan moet kunnen dan leg je dat lat niet hoog, dan leg je de lat in een ander sterrenstelsel. Dit is niet een héél klein beetje van alle realiteitszin verwijderd ;)
R.G schreef op zondag 16 juni 2024 @ 20:50:
ik denk even hard op hoor.
Nogmaals; with all due respect, ik zou het (héél hard) dagdromen noemen ;)

Zoals @Merethil al aanhaalde: Rome is niet in een dag gebouwd. Natuurlijk wil je een solide basis leggen en vooruit denken, maar met de "requirements" die je nu hebt heeft je basis al miljoenen gekost nog vóórdat je ook maar 1 gebruiker hebt. Geen idee waar je dat (die "hobby" van je) dan van wil gaan betalen, maar misschien heb je inderdaad een paar honderd miljoen op je rekening staan waar je ontzettend graag vanaf wil. Je weet nooit :P

[ Voor 40% gewijzigd door RobIII op 16-06-2024 20:58 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • R.G
  • Registratie: Januari 2009
  • Laatst online: 12:57
Merethil schreef op zondag 16 juni 2024 @ 20:09:
[...]


Daar heb je inderdaad load balancers voor. Als je iets als Kubernetes gebruikt dan heb je ook nog een autoscaler die bepaalt wanneer oude pods vervangen of nieuwe pods bijgezet moeten worden; dit kan je met iets als KEDA helemaal customizen zodat hij op basis van eigen metrics wordt gestuurd. Naast pods kan je zo ook nodes opschalen en eventueel ook nodes in specifieke zones bijzetten als een andere zone eruit ligt.

Dit soort zaken vereist veel tweaking, correct opzetten van je code en rekening houden met o.a. downtime, scaling-acties, verplaatsen van je workload als je netwerk in een regio eruit ligt etc. Allemaal erg fijn om op orde te hebben, maar ongeveer 1000 stappen verwijderd van het traject waar je nu nog in zit; bepalen hoe je start en wat je gaat doen met je project.

Even wat dooddoeners die toch passen: Rome is niet in één dag gebouwd, Facebook heeft er jaren over gedaan om van 1 naar 1 miljoen gebruikers te gaan en zelfs Pokémon Go lag er de eerste dagen uit omdat ze niet in één keer alle load aan konden, zelfs terwijl ze heel gefaseerd uitrolden over de hele wereld heen.
Begin dus vooral met een solide basis, maar maak je niet vanaf moment 1 druk om miljoenen gelijktijdige gebruikers. Elk project start klein en zou een MVP moeten hebben waarbij je waarde toevoegt. Als je userbase dan groeit kan je op basis van de gemeten waardes aan gebruik, de feedback van de gebruikers en de inzichten in belangrijkste features bepalen wat je vervolgstappen zijn. Tot die tijd is alles heel leuk bedacht, maar een solide infrastructuur zonder gebruikers is vooral erg duur en zonde van je tijd ;)
Klopt en bedankt voor je bevestiging, zoiets dacht ik al, ik ga mij eens verdiepen in keda. Ik heb al ooit bij een project met podman en kubernetes wat gedaan voor health checking. Maar de echte essentie heb ik mij nog niet echt in verdiept waar gewonen taken op de backlog met kleine stories voor health checking.

goede opmerking over:
Dit soort zaken vereist veel tweaking, correct opzetten van je code en rekening houden met o.a. downtime, scaling-acties, verplaatsen van je workload als je netwerk in een regio eruit ligt etc

Daarom zei ik ook, met wat zijn de juiste tools en hoe bouw je eerste de juiste fundering dat je deze informatie ook beschikbaar hebt en hoe hou je ze bij.

in hoeverre kan je het ook schalen doe je dat dan allemaal via het orchestra en KEDA? als setting.
Commucieert KEDA dan bijvoorbeeld met je containers ( podman of docker) draait KEDA dan als een special user?


In hoeverre ik nu een architectuur heb zonder te veel prijs gegeven is dan een soort van mind map

in het midden rondje met tekst Platform en daaromheen dan bubbel rodnjes met features van het platform en elke rondje kan ik dan nog uitbreiden met sub bubbels die dan de tools en of eigenschappen van die feature laten zien?

maar dat is meer brainstorming over het probleem, een archictectuur plaatje is meer welke servers, welke omgevingen en welke gescheiden zijn, firewall, servers, databases etc toch?

Ik heb het allemaal ooit wel eens gedaan of is voorgekomen maar is al een tijdje geleden..

Had ik het maar allemaal goed bijgehouden zoals ze met AI zeggen, je mind is voor ideen, je text opslag / data bewaar je in een db of notes en kan je met AI snel zoeken..

Dat is beter en is je brein ook niet te vol. of zeg ik hier iets raars ? :P

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
R.G schreef op zondag 16 juni 2024 @ 20:57:
een soort van mind map

in het midden rondje met tekst Platform en daaromheen dan bubbel rodnjes met features van het platform en elke rondje kan ik dan nog uitbreiden met sub bubbels die dan de tools en of eigenschappen van die feature laten zien?
True, paint (of Powerpoint of...) zal je niet tegenhouden een rondje "Platform" te teken en daar allemaal bubbeltjes met buzzwords omheen te tekenen. That's the easy part ;)

Wat je hier doet is:
R.G's Masterplan:
  1. Idee: <top secret>
  2. Bouw platform dat de Googles en Amazons en Facebooks enzovoorts doet verbleken
  3. ...
  4. Profit!
Nogmaals: Het is heel leuk om te dagdromen, maar denk je nou serieus zelf niet een héél klein beetje dat dit alle realiteitszin totáál voorbij gaat?

Maar goed, misschien ben ik wel een partypooper. "Durf te dromen" zeggen ze wel eens. You go girl! *O*

[ Voor 23% gewijzigd door RobIII op 16-06-2024 21:07 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • R.G
  • Registratie: Januari 2009
  • Laatst online: 12:57
RobIII schreef op zondag 16 juni 2024 @ 21:02:
[...]


Wat je hier doet is:


[...]


Nogmaals: Het is heel leuk om te dagdromen, maar denk je nou serieus zelf niet een héél klein beetje dat dit alle realiteitszin totáál voorbij gaat?
Lastig, tbh ik geloof Erin en wil er voor gaan. Ik geloof dat het vernieuwend is en mensen waarde biedt.

De fundering moet ook mogelijkheid bieden om web 3.0 te integeren dat men kan inloggen met een Blockchain account en seamless Blockchain technology ondersteund.

Stel 1.000 gebruikers via iOS android doen wat acties in een app, Dan worden de acties doorgestuurd naar de nodejs server api? Deze voeren acties uit naar de Blockchain. De users kunnen dan in de app en op het platform de acties en resultaten terug zien.


Dit kan ik theorie 1.000.000.000 acties zijn als je nadenkt over alle mensen op de wereld daar een gedeelte deze app of platform gebruikt?

Dan loop je wel tegen issues aan?

Soms kunnen platformen opeens gigantisch worden.

Denk na over dat flappybird, miljoenen users opeens.

Dream big, go for it mentality.

Misschien ga ik ook mensen hier erbij betrekken en ontwikkelen we het samen.


Idee is nu:
3 containers maken.

Postgresql, nodejs, test server
Dan wat situations schetsen en testen.

Kijken wanneer de postgresql en node js het niet meer aankunnen.

Daarna kijken hoe het met een load balancer en met keda meerdee nodejs en postgresql kan laten spawnen.

Test server ga ik met threads request laten generen richting de node js server.

Is dat een slimme aanpak?

Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
R.G schreef op zondag 16 juni 2024 @ 17:51:
Diegene die mij assisteren en of geholpen hebben beloof ik dat als dit platform eenmaal bestaat ik ze niet vergeet.
R.G schreef op zondag 16 juni 2024 @ 21:11:
Misschien ga ik ook mensen hier erbij betrekken en ontwikkelen we het samen.
Ik ga dit topic sluiten omdat het niets met programmeren te maken heeft en werving hier niet toegestaan is, de vraag(-waterval) (véél) te open en abstract is en het onderwerp totaal los staat van enige realiteitszin. Sorry.

Succes met je project d:)b Ik hoop voor je dat het je lukt!

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij

Pagina: 1

Dit topic is gesloten.