Bedrijfskritische applicatie aanbieden als service

[-DarkShadow-]

Ik ben op zoek naar een manier om een bedrijfskritische applicatie aan te bieden als service (SaaS dus). Ik open dit topic om me te oriënteren. De applicatie wordt gebruikt in het MKB (2 tot 100 medewerkers) en down-time tijdens kantooruren is zo goed als onacceptabel. Het gaat om een CRM achtige applicatie en veiligheid is dus zeer belangrijk. Medewerkers moeten veel met de applicatie werken, dus snelheid is ook belangrijk. Voor ieder bedrijf moet de applicatie op kleine punten aangepast worden. De kosten moeten in de hand gehouden worden omdat de meeste klanten 2 - 10 medewerkers zullen hebben.

Dus:

• SaaS
• High availability
• Veilig
• Snel
• Betaalbaar

Nu ben ik op zoek naar hosting die aan alle eisen voldoet en die weinig management vergt. In verband met al bestaande onderdelen wordt het liefst PHP gebruikt.

Alle klanten op één VPS (bij een gerenomeerde VPS hoster in een cloud)
+ Vrije keuze van de omgeving (PHP, etc...)
- Management is vrij duur doordat backups, updates e.d. tijd vergen van een specialist
- Meest kwetsbare oplossing

Voor iedere klant een VPS (bij een gerenomeerde VPS hoster in een cloud)
+ Vrije keuze van de omgeving (PHP, etc...)
+ Veilig omdat iedere klant een eigen virtuele machine met eigen database heeft
+ Snel omdat resources makkelijk op te schalen zijn
- Management is vrij duur doordat backups, updates e.d. tijd vergen van een specialist
- Applicatie updaten en onderhoud misschien lastig omdat dit op vele virtuele machines moet gebeuren?

Amazon Web services
+ High availability, backups, etc... kunnen meteen afgedekt worden.
- Als je het hele pakket aan mogelijkheden neemt, nemen de kosten flink toe.
o Per klant moet er een app "geïnstalleerd" en geüpdate worden. (geen multi-tenancy en multi-tenancy in de app implementeren vind ik te risicovol)

Google App Engine (evt. Enterprise)
+ Kost bijna niets
+ High availability, backups, etc... kunnen meteen afgedekt worden.
- Geen relational database
- Alleen Python en Java worden ondersteund en er moet gebruik worden gemaakt van Google's framework (groot nadeel!)
o Multi-tenant, maar kan dit de modificaties per klant afvangen?

[ Voor 5% gewijzigd door -DarkShadow- op 18-09-2010 16:16 ]

[Kalentum]

Ik snap iets niet: waarom niet 1 server waar alle klanten op zitten?

[-DarkShadow-]

rutgerw schreef op vrijdag 17 september 2010 @ 16:46:
Ik snap iets niet: waarom niet 1 server waar alle klanten op zitten?

Vergeten. Toegevoegd.

[Boudewijn]

Niet echt redundant, zowel op hardware als infrastructuur niveau.

[-DarkShadow-]

Alle klanten op één server lijkt mij niet veilig genoeg. Eén foutje bij één klant kan dan alle klanten uit de lucht halen.

[Boudewijn]

Uhh dat heet netjes onafhankelijk van elkaar opbouwen (met dingen als vhosts of VMs).

[Snake]

Al eens gekeken naar Azure?

[-DarkShadow-]

Boudewijn schreef op zaterdag 18 september 2010 @ 16:57:
Uhh dat heet netjes onafhankelijk van elkaar opbouwen (met dingen als vhosts of VMs).

Ik heb weinig verstand van server management en dat wordt dus netjes uitbesteed.

Snake schreef op zaterdag 18 september 2010 @ 16:59:
Al eens gekeken naar Azure?

Ziet er netjes uit (PHP, relational db). Multi-enterprise business applications zijn niet vreemd voor Azure. Wel lijkt het zich erg op ASP.NET te richten.

[cariolive23]

Je hebt het over High availability en gelijktijdig over kantooruren. Dan heb je het dus over 5x10 uur beschikbaarheid, wat erg weinig is per week. High availability is ook meer dan alleen het platform wat in de lucht is, ook jouw onderhoud wordt daar in meegerekend.

Verder begin je over snelheid en ga je vervolgens verder met VPS, cloud en nog meer langzame oplossingen. Databases vragen veel RAM en nog veel meer I/O waar je gewoon snelle schijven en RAID-controles voor wilt gebruiken. Dus welke snelheid zoek je?

Veiligheid is iets waar je zelf keihard aan moet werken, SQL Server en PostgreSQL zijn in elk geval databases die standaard zeer veilig zijn. Wanneer je kiest voor Linux, kun je ook met SELinux aan de slag, maakt de boel nog weer veiliger. En wanneer je daarmee bezig bent, kun je ook met SEPostgreSQL aan de slag. Uiteraard vertrouw je nooit een gebruiker en ga je alle input correct beveiligen. Ga voor de beveiliging een lijst met software maken die je goed moet inrichten, met alleen een database en PHP ben je er niet, er is ook nog FTP, SSH, Apache, etc. etc. wat je allemaal moet gaan configureren.

Hoeveel klanten heb je nu en hoeveel verwacht je er de komende 6 maanden te krijgen?

[Jory]

Je hebt het over High availability en gelijktijdig over kantooruren. Dan heb je het dus over 5x10 uur beschikbaarheid, wat erg weinig is per week.

Maar het kan natuurlijk een eis zijn, dat de applicatie gedurende die 40 uur per week "altijd" beschikbaar is. Dit levert dus in ieder geval een deel van de problemen op die "standaard" HA eisen opleveren. (Je onderhoud kun je gaan plannen in een periode dat het toch niet uitmaakt, maar failures zijn -tijdens kantoor uren- nog steeds een probleem waarop geanticipeerd moet worden.)

- Applicatie updaten en onderhoud misschien lastig omdat dit op vele virtuele machines moet gebeuren?

Nee hoor. Aangezien je die updates toch op een geautomatiseerde manier moet uitrollen (omdat het anders fout gaan) en je toch al meerdere omgevingen hebt (development, test, staging?, productie), maakt het hebben van al je klanten op 1 of n systemen niets uit.
Ook de beheer kosten van je systemen is ongeacht het aantal systemen nagenoeg gelijk. (Of misschien beter gezegd, die kosten zijn verre van liniair - een goede systeembeheerder is erg "schaalbaar" wat aantal systemen betreft.)

[CrankyGamerOG]

Ik heb maar 1 vraag : Wat is je budget?

[defcon84]

hebben de meeste klanten onder de 50 werknemers niet zoiets als een SBS draaien? daar kan je toch lekker gebruik van maken dan? :-)

[Verwijderd]

Volgens mij moet je beginnen met een SLA. Alle dingen die je noemt kosten gewoon serieus tijd om te realiseren.

Wij richting ons primair op saas, en als we in onze klantenkring kijken, en daar zitten flink wat grote jongens bij, dan is het aantal SLA's op mission critical, 24x7, gold support enz. op een hand te tellen.

Tenzij je een bank bent, of er mensen dood kunnen gaan door je infrastructuur, kiest men vrijwel nooit voor de 24x7 support, de hoogste uptime, of maandelijkse onafhankelijke security audits. Die laatste procentjes kosten het meeste, en er zijn niet veel bedrijven die dat er voor over hebben en zeker niet in het MKB.

[CrankyGamerOG]

Verwijderd schreef op maandag 20 september 2010 @ 09:27:
Volgens mij moet je beginnen met een SLA. Alle dingen die je noemt kosten gewoon serieus tijd om te realiseren.

Wij richting ons primair op saas, en als we in onze klantenkring kijken, en daar zitten flink wat grote jongens bij, dan is het aantal SLA's op mission critical, 24x7, gold support enz. op een hand te tellen.

Tenzij je een bank bent, of er mensen dood kunnen gaan door je infrastructuur, kiest men vrijwel nooit voor de 24x7 support, de hoogste uptime, of maandelijkse onafhankelijke security audits. Die laatste procentjes kosten het meeste, en er zijn niet veel bedrijven die dat er voor over hebben en zeker niet in het MKB.

Amen...... helaas moet ik hem gelijk geven

[ReenL]

CrankyGamerOG schreef op zondag 19 september 2010 @ 22:19:
Ik heb maar 1 vraag : Wat is je budget?

Dit vraag ik me ook af.

Aangezien je het over VPS hebt.. 2x VPS met master-master replication db en een loadbalancer ervoor? Is niet 100% maar ligt in elk geval in je budget.

Je kunt het zo gek maken als je zelf wilt (en kan betalen). Denk bijvoorbeeld aan een derde server die altijd de laatste backup zou kunnen draaien indien bovenstaande setup kapot is.

[Standeman]

Voor ons SaaS platform hebben we eigenlijk een alleen een loadbalancer en twee machines met tomcat/mysql draaien. Als er een machine er mee ophoud, dan blijft de services gewoon wel draaien. Tot nu toe meer dan voldoende. Overige problemen (bijvoorbeeld een bom op het datacenter) hebben we uitgesloten in de SLA's.

Een punt waar je ook over na kan denken zijn escrow services. Wat gebeurt er met je platform wanneer je failliet gaat? Je klanten willen daar wel enige zekerheid in dat alles blijft doordraaien, aangezien het bedrijfskritische applicaties zijn.

[-DarkShadow-]

Jory167 schreef op zondag 19 september 2010 @ 22:14:
[...]
Maar het kan natuurlijk een eis zijn, dat de applicatie gedurende die 40 uur per week "altijd" beschikbaar is. Dit levert dus in ieder geval een deel van de problemen op die "standaard" HA eisen opleveren. (Je onderhoud kun je gaan plannen in een periode dat het toch niet uitmaakt, maar failures zijn -tijdens kantoor uren- nog steeds een probleem waarop geanticipeerd moet worden.)

Klopt. De applicatie dient altijd online te zijn, maar tijdens kantooruren kost downtime geld bij de klant.

CrankyGamerOG schreef op zondag 19 september 2010 @ 22:19:
Ik heb maar 1 vraag : Wat is je budget?

Hoe lager de kosten, hoe meer winst

Standeman schreef op maandag 20 september 2010 @ 10:29:
..

Een punt waar je ook over na kan denken zijn escrow services. Wat gebeurt er met je platform wanneer je failliet gaat? Je klanten willen daar wel enige zekerheid in dat alles blijft doordraaien, aangezien het bedrijfskritische applicaties zijn.

Dat is een goed punt inderdaad. Wiki linkje

[ Voor 8% gewijzigd door -DarkShadow- op 20-09-2010 21:55 ]

[MADG0BLIN]

-DarkShadow- schreef op maandag 20 september 2010 @ 21:51:

Klopt. De applicatie dient altijd online te zijn, maar tijdens kantooruren kost downtime geld bij de klant.

Hoe lager de kosten, hoe meer winst

Dat lijkt me logisch, maar wat is acceptabel? Altijd online met 3x failover redundancy is duur, erg duur.
Dus als je het dan over lage kosten hebt, dan wordt dat misschien een wat lastigere oplossing en kun je beter gaan kijken naar een service die bijvoorbeeld 99,0% uptime heeft ipv 99,9% uptime.

Wat willen je klanten ervoor betalen, dat afzetten tegen wat jij kan bieden.
Ik heb ook klanten die roepen: Ik wil altijd online blijven, alles moet redundant en het moet feilloos blijven werken zonder storingen. Prima, maar als ik dan met een offerte kom dan schrikt de helft zich wezenloos omdat ze denken dat je voor een dubbeltje op de eerste rang kan zitten.. Zo werkt het niet met dit soort dingen is mijn ervaring. Hoe hogere uptime, hoe duurder het wordt. En de laatste paar procenten zijn het duurste.

Eigenlijk wat Def!ance en Gordijnstok dus ook zeggen maar waar geen antwoord is op gegeven voor zover ik nu zie.

[ Voor 5% gewijzigd door MADG0BLIN op 20-09-2010 22:36 ]

[Exhar]

Ik ben zelf werkzaam bij een bedrijf welke dit kan bieden, zowel shared als dedicated. Nu ben ik er niet op uit dat je me een DM/PM stuurt voor de bedrijfsnaam, ik wil je er alleen op wijzen dat hetgeen je vraagt tegen absoluut redelijke prijzen mogelijk is.

Als je dit zelf wilt gaat opzetten, zit je al snel aan een torenhoge setup qua kosten (zeker als redundantie zo belangrijk is). Een VPS zou ik zelf nooit vertrouwen voor redundantie, als er op software niveau iets niet lekker gaat ben je alsnog klaar.

VPS/eigen setup vergen ook een hele hoop beheer, waardoor de prijs snel hoger wordt. De alternatieven die je noemt zijn leuk, maar voor zover mij bekent lopen de kosten erg snel op ja (zoals je zelf al noemt).

Binnen Nederland zou ik denken aan bedrijven als Pins (of IS Interned Services tegenwoordig) als je een professionele setup wilt die voor jou gebouwd is of een respectabele (managed) webhoster.

[CrankyGamerOG]

Exhar schreef op maandag 20 september 2010 @ 22:52:

Als je dit zelf wilt gaat opzetten, zit je al snel aan een torenhoge setup qua kosten (zeker als redundantie zo belangrijk is). Een VPS zou ik zelf nooit vertrouwen voor redundantie, als er op software niveau iets niet lekker gaat ben je alsnog klaar.

Zou je deze uitspraak eens kunnen toelichten? ik vind het nogal wat om te verklaren dat een VPS minder betrouwbaar is dan een dedi.

Sterker nog een VPS is in mijn optiek juist betrouwbaarder, denk aan de versitaliteit die je met VPSen hebt.

En nog mooier waarom zou een VPS cluster in een heartbeat en haproxy setup minder betrouwbaar zijn dan dedicated servers in diezelfde setup?

Je maakt nogal een statement en wil graag dat je deze wat verder uitlegt.

[ Voor 3% gewijzigd door CrankyGamerOG op 21-09-2010 09:25 ]

[Verwijderd]

Exhar schreef op maandag 20 september 2010 @ 22:52:
dat hetgeen je vraagt tegen absoluut redelijke prijzen mogelijk is.

Wat richtingen;

Ik wil graag 24x7 support, en dan niet alleen een telefonist die een script afwerkt.
Ik wil graag dat zowel servers alsmede de ondersteunende hardware en dienstverleningen redundant zijn uitgevoerd. Ook over meerdere datacentra graag.
Ik wil graag dat er een escrow regeling komt, ik heb 4 mayor releases in het jaar en elke maand een minor release.
Ik wil graag een uptime van 99.9% binnen business hours, en buiten business hours 99.7%
Ik wil graag een maximale reactietijd van twee uur op issues, en een oplostijd van maximaal acht uur op issues in de garantieperiode.

Knappe kerel als je dat voor een appel en een ei voor elkaar krijgt. Ligt er ook aan wat je verstaat onder 'redelijke prijzen'. De orderwaarde van een SLA overtreft regelmatig die van het project en de bijkomende licenties. Zie door mijn richtingen waarom dat zo is.

[Exhar]

CrankyGamerOG schreef op dinsdag 21 september 2010 @ 09:24:
[...]

Zou je deze uitspraak eens kunnen toelichten? ik vind het nogal wat om te verklaren dat een VPS minder betrouwbaar is dan een dedi.

Sterker nog een VPS is in mijn optiek juist betrouwbaarder, denk aan de versitaliteit die je met VPSen hebt.

En nog mooier waarom zou een VPS cluster in een heartbeat en haproxy setup minder betrouwbaar zijn dan dedicated servers in diezelfde setup?

Je maakt nogal een statement en wil graag dat je deze wat verder uitlegt.

Ho! Een single VPS tegen 2 dedi's die goed ingericht zijn bedoelde ik. Veel mensen zien een VPS als betrouwbaarder omdat (Als 't goed is) deze op een goede host omgeving staan (meerdere nodes, bij problemen kan 'r verhuisd worden). Mijn punt is dat hardware 9 van de 10 keer 't probleem niet is. Meestal is het software (apache, whatever) die niet lekker werkt. Dan kan je hardware (VPS) nog zo goed zijn, je service is alsnog offline.

Verwijderd schreef op dinsdag 21 september 2010 @ 10:03:
[...]


Wat richtingen;

Ik wil graag 24x7 support, en dan niet alleen een telefonist die een script afwerkt.
Ik wil graag dat zowel servers alsmede de ondersteunende hardware en dienstverleningen redundant zijn uitgevoerd. Ook over meerdere datacentra graag.
Ik wil graag dat er een escrow regeling komt, ik heb 4 mayor releases in het jaar en elke maand een minor release.
Ik wil graag een uptime van 99.9% binnen business hours, en buiten business hours 99.7%
Ik wil graag een maximale reactietijd van twee uur op issues, en een oplostijd van maximaal acht uur op issues in de garantieperiode.

Knappe kerel als je dat voor een appel en een ei voor elkaar krijgt. Ligt er ook aan wat je verstaat onder 'redelijke prijzen'. De orderwaarde van een SLA overtreft regelmatig die van het project en de bijkomende licenties. Zie door mijn richtingen waarom dat zo is.

Als ik kijk naar 't bedrijf waar ik werk, zet ik alleen een vraagteken bij 24x7 support (waarom? hardware falen hebben wij niet mee te maken doordat echt alles redundant is... Tuurlijk, er faalt genoeg, maar de impact voor klanten is 0). Qua redundantie leveren wij nog niet in meerdere DC's (alleen wat backup services).

De kosten voor meerdere DC's zijn erg hoog (fibers, routing, etc). Meerdere partijen in Nederland hebben dat overigens wel (Uniserver, Pins). Wij zijn er mee bezig, maar tot nu toe hebben we nog geen issues met 't DC gehad (*afkloppen*)

Uptime van 99.9% kunnen wij ook bieden, en de reactietijden zijn iets ruimer: 4 uur initieel, 8 uur oplostijd. De prijzen waar ik 't over heb hangen heel erg af van de ruimte die je nodig hebt.

Ruimte omdat een HA oplossing met SAN's werkt (bij ons) en dat duur is...

De reden waarom wij 't relatief goedkoop kunnen aanbieden is omdat 't door veel mensen gebruikt wordt. Normaal wordt een dergelijke setup custom neergezet voor iemand en betaal je alle hardware, kennis etc zelf... Nu deel je die in principe (alhoewel wij ook klanten hebben die een dergelijke setup met dedi's bij ons laten hosten)

Overigens heeft dit 'n hoog sales-gehalte. Is niet mijn bedoeling! Voornamelijk wat uitleg.

[CrankyGamerOG]

Als je al geen afzonderlijke dc's hebt met afzonderlijke fibers en afzonderlijke stroomtoevoer dan kun je al niet van een werkelijke HA setup spreken in mijn optiek. (gelukkig hebben wij dat wel )

Ho! Een single VPS tegen 2 dedi's die goed ingericht zijn bedoelde ik. Veel mensen zien een VPS als betrouwbaarder omdat (Als 't goed is) deze op een goede host omgeving staan (meerdere nodes, bij problemen kan 'r verhuisd worden). Mijn punt is dat hardware 9 van de 10 keer 't probleem niet is. Meestal is het software (apache, whatever) die niet lekker werkt. Dan kan je hardware (VPS) nog zo goed zijn, je service is alsnog offline.

Appels en peren ?

Je vergelijkt een dedicated server in een ha setup met een single VPS setup.
Nogal goedkoop om zo het hele VPS systeem als onbetrouwbaar neer te zetten.

Een single dedi tegen een single vps is exact hetzelfde, apache stuque, is site niet bereikbaar.
Multiple ha dedi tegen multiple ha vps is ook exact hetzelfde.

Een single VPS tov van een single dedi is wel degelijk handiger in sommige gevallen, zoals ik al zei, een vps is versatiler.
Vooral als de data op een geclusterde data storage staat, en je dus elke VPS op ELKE hwnode online kunt laten komen zonder migraties

Naar mijn mening probeer je hier gewoon je eigen product te verkopen onder het mom dat het zoveel beter is.(moet je verder zelf weten natuurlijk, beter dat je gelukkig vertrouwen in je product hebt)

Maar ik vind het ook nogal gewaagd zoals ik bovenaan al zei dat je het een ha durft te noemen als beide kanten afhankelijk zijn van dezelfde stroomtoevoer en dezelfde glaslink.


Vat dit dan ook aub niet op als een persoonlijke aanval, maar je uitspraken vragen gewoon om verduidelijking.

[ Voor 85% gewijzigd door CrankyGamerOG op 21-09-2010 10:39 ]

[Exhar]

CrankyGamerOG schreef op dinsdag 21 september 2010 @ 10:23:
Als je al geen afzonderlijke dc's hebt met afzonderlijke fibers en afzonderlijke stroomtoevoer dan kun je al niet van een werkelijke HA setup spreken in mijn optiek. (gelukkig hebben wij dat wel )


[...]


Appels en peren ?

Je vergelijkt een dedicated server in een ha setup met een single setup
Nogal goedkoop om zo het hele VPS systeem als onbetrouwbaar neer te zetten.

Een single dedi tegen een single vps is exact hetzelfde, apache stuque, is site niet bereikbaar.
Multiple ha dedi tegen multiple ha vps is ook exact hetzelfde.

Een single VPS tov van een single dedi is wel degelijk handiger in sommige gevallen, zoals ik al zei, een vps is versatiler.
Vooral als de data op een geclusterde data storage staat, en je dus elke VPS op ELKE hwnode online kunt laten komen zonder migraties

Naar mijn mening probeer je hier gewoon je eigen product te verkopen onder het mom dat het zoveel beter is.(moet je verder zelf weten natuurlijk, beter dat je gelukkig vertrouwen in je product hebt)

Maar ik vind het ook nogal gewaagd zoals ik bovenaan al zei dat je het een ha durft te noemen als beide kanten afhankelijk zijn van dezelfde stroomtoevoer en dezelfde glaslink.


Vat dit dan ook aub niet op als een persoonlijke aanval, maar je uitspraken vragen gewoon om verduidelijking.

Gelukkig kan ik heel veel hebben en zoals ik al zei: 'mijn' product probeer ik ook niet te verkopen, anders had ik wel 'n bedrijfsnaam genoemd!

Appels en peren klopt misschien, mijn fout en daarin had ik duidelijker moeten zijn! Overigens heb ik niets tegen VPSsen, zeker niet omdat hardware problemen echt 't hatelijkste zijn om op te lossen in 'n DC, 's nachts... Oftewel: ik had even duidelijker moeten zijn

Overigens is de reden dat wij bare-metal gebruiken en geen VPSsen een puur economische (althans, dat was het vroeger). Voor de hoeveelheid servers die wij hebben (+250) met de huidige specs zouden we een aantal enorme hosts moeten kopen. Toendertijd was 't goedkoper om bare-metal neer te hangen. Om op dit moment een virtuele omgeving op te bouwen moet er een enorme tijds-investering plaats vinden. Hogeraf heeft besloten dat dat nu nog niet wenselijk is...


Overigens, wij maken gebruik van een grote partij als netwerk leverancier (zegt niet natuurlijk) met meerdere verbindingen (gescheiden) naar buiten. We hebben meerdere uplinks en alles zit op de A & B feed.

Al met al gaan we nu meer over in een welles-nietes spelletje wat niet de bedoeling is van dit topic Eventueel kunnen we verder in DM/PM natuurlijk!

[bat266]

Buiten alle opmerkingen wil ik even in gaan op een van je keuzes.

Een belangrijk nadeel (misschien) van Google app engine is dat elke request naar de server maar 30 seconden mag duren. Anders wordt de request afgekapt. Er is wel een mechanisme om je taak op te splitsen door tasks in een queue te zetten, maar dat is niet altijd een oplossing.

[-DarkShadow-]

Bedankt voor alle hulp, tips en opmerkingen!

Ik heb Google App Engine bestudeerd en ik denk niet dat dit geschikt is voor enterprise applicaties.
1. Google geeft geen enkele garantie op service en er worden af en toe grote veranderingen doorgevoerd in de API zonder deze lang van te voren aan te kondigen. Hier wordt wel aan gewerkt, maar het platform is nog niet volwassen.
2. Google behoudt het recht om door alle data te snuffelen. Daarmee valt GAE direct af.

Dus er gaat een applicatie ontworpen worden met het oog op HA, deze zal gehost worden bij een bekende VPS hoster in NL. Daarbij zal bij alle (ontwerp) processen HA in de gaten gehouden moeten worden.

[Hydra]

cariolive23 schreef op zondag 19 september 2010 @ 18:46:
Verder begin je over snelheid en ga je vervolgens verder met VPS, cloud en nog meer langzame oplossingen. Databases vragen veel RAM en nog veel meer I/O waar je gewoon snelle schijven en RAID-controles voor wilt gebruiken. Dus welke snelheid zoek je?

Sorry maar wut? Wat voor'n systemen denk je dat een omgeving als Azure op draait? Een paar afgedankte 386-machines? Het hele voordeel van een omgeving als Azure is juist dat als je meer capaciteit nodig hebt je dit in een paar klikken bij kunt kopen. Je moet latency niet verwarren met performance.

[_Erikje_]

wat een bullshit cariolive23, die cloudsystemen zijn allemaal retesnel en ook heel betrouwbaar. Daarnaast gaat TS geen spannende dingen doen dus is dedicated hardware helemaal niet nodig. Dedicated hardware maakt opschalen nogal wat moeilijker. Je moet een doos bij prikken, pooling regelen en al die sheit. Bij een VPS (met vmware oid) kan je gewoon lineair runtime opscholen en het is niet meer traag zoals 10 jaar geleden. Ja, je levert iets in op performance maar dat is te overzien.

TS: misschien ben ik simpel, maar waarom denk je zo moeilijk. (daarnaast gooi je nogal met hippe termen (SaaS, multitenant). vroeger noemden we dat gewoon een portal waar verschillende klanten op kunnen inloggen.)

Als je in je datamodel netjes de scheiding van data verwerkt kan je gemakkelijk 1 instantie voor meerdere klanten inzetten.

Mijn keuze zou zijn:
- pak amazon aws
- schaal door wanneer dat nodig is
- scheidt de data netjes per customer. Heel gemakkelijk te doen met rules ed
- gebruik een taal waar je bedrijf het meeste ervaring mee hebt.