Pentagon wil cloudcontract van 10 miljard dollar nog steeds aan Microsoft geven

Het Amerikaanse ministerie van Defensie zegt na een heroverweging het miljardencontract voor clouddiensten nog steeds aan Microsoft te geven. Er werd opnieuw gekeken naar de aanbesteding naar aanleiding van een rechtszaak, aangespannen door concurrent Amazon.

In een korte bekendmaking op vrijdag stelt Defensie dat 'Microsofts aanbod nog steeds het meeste waar voor het geld van de overheid' vertegenwoordigt. Door het gerechtelijk bevel dat voortkwam uit de Amazon-zaak, is de aanbesteding uitgesteld tot 13 februari.

Amazon blijft bij zijn standpunt dat de aanbesteding aan Microsoft politiek gemotiveerd is. Amazon-hoofd Jeff Bezos is namelijk ook eigenaar van The Washington Post, een nieuwsmedium waar president Donald Trump niet positief tegenover staat. In een reactie op de beslissing laat Amazon weten dat het vindt dat men zich moet afvragen 'of het acceptabel is dat de president het Defensiebudget gebruikt om zijn persoonlijke en politieke doeleinden te bereiken'. Amazon acht het AWS-aanbod 'relatief sterker' en blijft 'een eerlijke, objectieve en onpartijdige beoordeling blijven nastreven'.

Het gaat om een contract met een waarde van tien miljard dollar om Defensie tien jaar van clouddiensten te voorzien. Het zogeheten Joint Enterprise Defense Infrastructure Cloud-project of JEDI moet het leger betere toegang geven tot data van bijvoorbeeld slagvelden of in andere gebieden.

Reacties (135)

[Tomatoman]

Even proberen dat duizelingwekkende bedrag van $ 10 miljard in context te plaatsen.

• Het US Department of Defense (DoD) is onomstotelijk de grootste werkgever ter wereld, met volgens Forbes (2015) 3,2 miljoen werknemers en volgens Wikipedia (2016) 2,8 miljoen werknemers. Laten we heb op 3 miljoen werknemers houden.
• Daarnaast zijn er vele contractors actief in alle delen van de organisatie. Bij dergelijke organisaties zijn tientallen procenten aan inleners gebruikelijk. Ik doe een niet-onderbouwde aanname dat bij DoD 25% van het personeel is ingeleend.
• Daarmee komt het totale personeelsbestand uit op een mooi rond getal: 4 miljoen.
• Met een cloudcontract ter waarde van $ 10 miljard voor tien jaar gaat het om $ 83,3 miljoen per jaar maand. Verdeeld over 4 miljoen personeelsleden is dat $ 20,83 per personeelslid (werknemer of inlener) per maand. Nu is dat wel erg precies, terwijl ik wat grove aannames heb gedaan. Laten we het houden op ordegrootte $ 20 per personeelslid per maand, ongeacht hun functie.
• Is dat bedrag realistisch? Geen idee. Maar het geeft voor mijn gevoel een stuk meer inzicht dan een bedrag van $ 10 miljard voor 10 jaar.

[Reactie gewijzigd door Tomatoman op 24 juli 2024 08:28]

[Sebbo]

Fijn dat je de hoogte van het bedrag even in een wat logischere context kunt zetten voor ons!

Alleen kom ik niet bij 4 miljoen werknemers, aangezien 25% van 3 miljoen 0,75 miljoen is.

[Tomatoman]

Er staat als aanname: 25% is ingeleend, oftewel 25% van de 4 miljoen personeelsleden is ingeleend. De overige 3 miljoen zijn eigen werknemers

[laptopleon]

Dan nog zegt dit me niet veel.

Ik bedoel: Als het vooral voor een cloud-opslag a la Dropbox, iCloud of One Drive voor manschappen is, vind ik $ 20 per maand erg duur.

Maar is het compleet met allerlei maatwerk analytische applicaties, dan is het misschien wel een prima prijs.

[erwindew]

Dit moet je meer zien als mogelijkheden die in Azure draaien en niet alleen cloud opslag.
En dan vind ik 20 dollar per werknemer echt een koopie.

[Patriot]

Je hebt het over 83,3 miljoen dollar per jaar maar dat lijkt me een typefout. Het gaat dan natuurlijk om een maandbedrag. Dat komt ook overeen met de 20,83 dollar per maand per werknemer.

[Highlands]

We also remain grounded in the facts: AWS is the clear leader in cloud computing, and by any objective measure, has superior technology. For ten consecutive years, AWS has been named the leader in Gartner’s Magic Quadrant for Cloud Infrastructure as a Service

Zonder de argumenten van DoD te kennen vermoed ik dat de kern toch ligt in het feit dat juist Microsoft steeds meer diensten levert op PaaS en SaaS niveau. IaaS is wat mij betreft sterfhuis.

[Jeoh]

In 2020 is die categorie dan ook hernoemd naar 'Magic Quadrant for Cloud
Infrastructure & Platform Services'. En daar is Amazon nog altijd veruit de beste: https://pages.awscloud.co...r-mq-cips-2020-learn.html

Niet dat je teveel moet afgaan op Gartner MQs...

[Razwer]

Niet dat je teveel moet afgaan op Gartner MQs

Dat is de spijker op zijn kop.
1) Gartner checkt geen kwaliteit, alleen functionaliteit. Als je een waslijst aan features ondersteund maar ze werken allemaal fluit scoor je alsnog hoog bij Gartner.
2) Gartner is niet geheel transparant over score berekening. Onaangekondigd kunnen ze lichter of zwaarder wegen aan bepaalde zaken die misschien wel of niet relevant zijn voor de markt.

[elmuerte]

Kwestie van Gartner beter betalen.

[Argantonis]

Weet niet of je serieus bent maar je kan idd Gartner gewoon betalen om je te plaatsen (heb voor een softwarebedrijf gewerkt dat dat deed) en mij kan je niet wijsmaken dat dat 0,0% effect op de plaatsing heeft.

[Razwer]

Plaatsing binnen MQ betaal je voor. Scoring binnen MQ is voor zover ik weet niet te koop. Niet legaal iig.

[Rax-IP]

Gartner checkt zeker ook wel kwaliteit alleen dat zijn weer andere diensten dan alleen het magic quarter rapport. Wanneer je tijd gaat inkopen bij hun analysten/consultants van dan kunnen ze allerlei achtergrond informatie geven die je niet in de standaard rapporten ziet.

[Razwer]

Klopt helemaal maar we hadden het specifiek over MQ.

[familyman]

zo'n jeuk krijg ik daarvan.... zeker als ik zie dat het elke gedachte bij senior management doodslaat

[latka]

Bij MQ zie ik meestal een lijst van producten die je dus niet moet kopen: als Gartner het adviseert moet het wel beroerd zijn is mijn motto met MQ.

[supersnathan94]

Nee absoluut niet. Serverless is juist waar Amazon veel makkelijker en beter werkt.

Ja IaaS is een beetje op z’n retour, maar als je nu pas überhaupt nadenkt over een cloud contract heb je dat hard nodig om de overstap te kunnen maken. En dat heeft MS niet perse heel goed voor elkaar.

[fapkonijntje]

Gesproken door iemand met totaal geen kennis van Azure vermoed ik zo. Als je daadwerkelijk goed met beide platformen hebt gewerkt kom je snel genoeg tot de conclusie dat de Microsoft oplossingen completer en geïntegreerder zijn dan AWS. Waarbij AWS vooral losstaande diensten levert en veel minder werkt aan een geïntegreerde omgeving.

AWS en Azure concurreren maar op een beperkt deel van het assortiment. Bij AWS bestaat er geen SharePoint, Dynamics, Office365, PowerBI, Azure devops, AAD, enz.

Op het moment dat je een basis platform zoekt, waarop je zelf je zooi uitrolt is AWS zeker een kandidaat. Zodra de vragen complexer worden is AWS steeds minder interessant.

[Sebast1aan]

Zodra de vragen complexer worden is AWS steeds minder interessant.

Grappig, ik heb precies de tegenovergestelde ervaring. Als de zaken complexer worden missen een heleboel features nog bij Azure of zijn in preview status en moet je zeker wel gebruik maken van IaaS oplossingen om die gaten op te vullen. De "bones", de basis lijkt er wel te zijn, maar ze zijn er nog (lang) niet.

Een volledige PaaS only omgeving kan ik mij niet voorstellen voor large enterprises/financials e.d. die moeten voldoen aan security eisen van allerlei regulators (mijn speelveld). Ik noem b.v. het gebrek aan HSM support op de Front Door en Application Gateway. Je zal naar een IaaS solution moeten om private-keys veilig op te slaan. Met Key Vault ben je er niet. Nu MS komt dan af met marketing BS als "it all about identies now", "don't design, consume", maar kom op. De web application firewall van Microsoft is eerlijk gezegd een joke en je zal een IaaS WAF moeten deployen als je je web app security serieus neemt, of een SaaS versie zoals b.v. Imperva Cloud. Verschillende WAF vendors waar ik mee sprak legden uit dat de PaaS capabilities die beschikbaar zijn voor hun op Azure, simpelweg de low-level OS mogelijkheden niet ontsluiten die nodig zijn voor advanced WAF functionaliteiten, dus vandaar dat er allen IaaS WAF zijn te vinden in de marketplace, met uitzondering van de WAF van MS zelf. En deze Ngix/modsec based WAF vis in mijn ogen een worst of both worlds oplossing, een black-boxed open-sourced WAF. Open source, maar je kan niet bij de source of rules tweaken. En dan nog ook de belachelijke limitatie van 100 custom rules. Uiteindelijk niets anders dan een ik-heb-een-OWASP-compliant-WAF-checkbox voor de regulators.

Anywayz, just my 2 cents.

[sjongenelen]

Bieden bedankt voor het inzicht

[David Mulder]

Het is echt maar wat je nodig hebt, heb met allebei gewerkt en als je het platform gebruikt 'zoals het bedoeld is' zijn het allebei extreem complete oplossingen. Denk persoonlijk dat ik een zwakke preferentie heb voor Azure over AWS, maar bij beide zag ik verschillende geweldige oplossingen die de ander niet had.

[Mellow Jack]

Ik heb gewerkt bij een financial en kan je vertellen dat het zeker te doen is om volledige PaaS applicaties in Azure te draaien. Ik heb natuurlijk niet alle facetten van de financiële wereld omgezet naar een PaaS only oplossing maar als personen bij mij of mijn team kwam met 100 custom rules dan zat er iets flink fout in de architectuur

[K-aroq]

AWS is te prefereren als je je eigen applicaties wilt ontwikkelen en in een cloudomgeving wilt deployen. Wat het Pentagon zoekt gaat veel verder, inderdaad met de zaken die jij noemt. En dan is Azure duidelijk in het voordeel. Je zult het allemaal best wel aan de gang krijgen op AWS, maar dan gebruik je slecht een heel klein stukje van AWS en is de boel niet geoptimaliseerd.

Al moet je, zeker in deze situatie, politieke invloed niet uitsluiten. Bezos en Trump zijn niet bepaald vriendjes.

[Reactie gewijzigd door K-aroq op 24 juli 2024 08:28]

[twizzle]

Bij een contract voor 10 Miljard bieden beide partijen waarschijnlijk compleet andere diensten aan.

Daar worden missende onderdelen gewoon als maatwerk voor je geschreven vermoed ik.

En dat is waarschijnlijk ook de crux, hoeveel support geven beide partijen? Misschien heeft Microsoft wel gezegd we stellen 5 ervaren Senior programmeurs ter beschikking over de hele looptijd die alleen voor dit project werken.

Andere prijzen en andere onderdelen, zonder de aangeboden pakketten te zien kan je hier moeilijk over oordelen.

[Cergorach]

Ik zou willen zeggen dat tussen Amazon en MS, MS heer en meester is op het kantoor automatiseringsvlak. Maar pure webdevelopers zien veel meer in AWS en beperkt in Azure, wellicht komt dat omdat ze nog niet zo bekend zijn met Azure, wellicht dat het meer werk kost om van AWS naar Azure te hangen dan dat het oplevert.

Maar als je organisatie groot genoeg is zou ik willen zeggen dat je niet 100% afhankelijk moet zijn van alleen AWS of alleen Azure. Sla bv. een van je backups op in de ander en neem in je disaster recovery plan op hoe je omgaat met het uitvallen van een van de twee diensten.

[supersnathan94]

Maar even serieus hea. Want ik hoor dat vaker qua disaster recovery, maar dat is voornamelijk iets wat interessant is voor overheids partijen en kritieke infra. Ik snap dat het op SLA gebied gewoon noodzakelijk is om te kunnen zeggen “ja we zijn gewoo. Compliant geweest”, maar even serieus.

Wat gebeurt er als 1 van die twee partijen wegvalt? Ik ben bang dat een heel groot deel van het internet zoals we dat kennen helemaal wegvalt en daarmee dus ook belangrijke infrastructuur van banken, openbaar vervoer en software die gewoon nodig is voor het dagelijks leven. Dat is best wel eng. Er valt dan ook best wel wat voor te zeggen om ziets bijvoorbeeld niet mee te nemen omdat shit gewoon aan is en “onze” applicatie dan het laatste is waar we ons druk over moeten maken.

Mbt tot kantoor automatisering ben ik het met je eens. Dat doet MS gewoon heel erg goed.

[CAPSLOCK2000]

Maar even serieus hea. Want ik hoor dat vaker qua disaster recovery, maar dat is voornamelijk iets wat interessant is voor overheids partijen en kritieke infra. Ik snap dat het op SLA gebied gewoon noodzakelijk is om te kunnen zeggen “ja we zijn gewoo. Compliant geweest”, maar even serieus.

Wat gebeurt er als 1 van die twee partijen wegvalt?

Het is maar hoe je "disaster" definieert.
Iemand die per ongeluk op de verkeerde delete-knop drukt of vergeet een rekening te betalen kan ook een behoorlijk ramp zijn. Zelfs als het gaat om het onderhandelen over een contract kan het fijn zijn om een alternatief te hebben zodat je gesprekspartner je geen poot uit kan draaien met onredelijke eisen/prijzen omdat je toch niet weg kan.

[supersnathan94]

En daar heb je dan ook protocollen voor. Zo kan ik nu geen wijzigingen aanbrengen op het cluster zonder dat dit via bouwstraat loopt. Dan moet je wel hele gekke dingen doen;)

Rekening niet betalen lijkt mij ook zoiets wat niet direct fout zou moeten kunnen gaan overigens.

Neemt niet weg dat je dit soort dingen vanuit compliancy vaak gewoon moet doen zodat je richting klanten geen modderfiguur slaat. Logisch wel, maar soms echt kompleet overkill.

[Cergorach]

Rekening niet betalen lijkt mij ook zoiets wat niet direct fout zou moeten kunnen gaan overigens.

I've seen it happen! Multiple times...

Niet elke betalingsafdeling ziet exact in waarom het zo belangrijk is om zaken op tijd te betalen, zeker wanneer het een handje er van heeft om het liefst alles te laat te betalen... Ligt heel erg aan het bedrijf, dat soort ongein kom je minder vaak tegen in de Enterprise dan in het MKB.

[Cergorach]

Maar even serieus hea. Want ik hoor dat vaker qua disaster recovery, maar dat is voornamelijk iets wat interessant is voor overheids partijen en kritieke infra. Ik snap dat het op SLA gebied gewoon noodzakelijk is om te kunnen zeggen “ja we zijn gewoo. Compliant geweest”, maar even serieus.

Tot op zekere hoogte heb je te maken met compliancy in bepaalde branches en zal je compliant moeten zijn of dat nu zinvol is of niet. Maar er zijn zat branches die niet willen omvallen bij het omvallen van een AWS of Azure. Zeker nu gezien kan het zelfs zo zijn dat 1 partij wordt verboden in een gebied door politiek puntjes scoren.

Zo een uitwijk plan hoeft echt niet miljoenen per jaar te kosten en wel belangrijk voor een bedrijf dat honderden miljoenen zo niet vele miljarden omzet/beheert. In de doorsnee MKB zou het niet zo zinnig zijn.

[Reactie gewijzigd door Cergorach op 24 juli 2024 08:28]

[supersnathan94]

Uiteraard. Is ook gewoon kosten baten analyse, maar het is wel goed dergelijke scenario’s in het hoofd te hebben bij het uitwerken. Wanneer is het goed genoeg.

[Mellow Jack]

wat de cloud providers allemaal heel slim doen is het makkelijk maken om apps te ontwikkelen. Hoe meer je gebruik maakt van dit dingetjes die het je makkelijk maken hoe lastiger het is om weg te gaan.

Vooral pure webdevelopers hebben niet zozeer de behoefte om over te gaan, laat staan dat ze dingen maken die seamless van Cloud x naar cloud y kunnen gaan. Tenmiste, dat is mijn ervaring

[CH4OS]

Kubernetes op Azure werkt anders ook zo geweldig niet, voor een project voor een klant van ons hebben we uiteindelijk moeten migreren naar Google (van Azure af). Wellicht nu niet van toepassing, maar toont wel aan dat Azure ook de heilige graal niet is.

[Reactie gewijzigd door CH4OS op 24 juli 2024 08:28]

[Sfynx]

Als je managed Kubernetes wil gebruiken, dan is GKE sowieso de meest complete oplossing inderdaad. Je kiest dan alleen voor EKS of AKS als je daar al veel hebt draaien en dat goed wil kunnen integreren met je clusters.

(Zo werkt dat Workload Identity bij GKE echt ideaal als je dingen in de cluster toegang wil geven tot andere Google services, geen gedoe met key files die je in k8s secrets moet prakken, maar gewoon direct de k8s en GCP service accounts aan elkaar knopen, de andere cloudproviders zullen ook wel zoiets hebben)

[Reactie gewijzigd door Sfynx op 24 juli 2024 08:28]

[Cergorach]

Helemaal mee eens, Azure (of welke andere oplossing dan ook) is geen heilige graal. Voordat Azure SSD achtige disks aanbood met meer IOPS per disk dan 500 zijn we ook weer terug gegaan naar een andere leverancier, een paar jaar later toch weer richting Azure gegaan omdat MS toch heel erg aan de weg timmert (en ook die andere leverancier had zo zijn issues, maar niet met disk IOPS ;-)...

[Highlands]

Beter? Dat lijkt me afhankelijk van de toepassing. Verder zou ik niet alleen naar ‘Serverless’ kijken maar naar het grotere plaatje waarin integratie (AAD/ Microsoft’365) ook een rol speelt.

Oh ja, legacy moven naar IaaS is meestal slecht plan.

[Reactie gewijzigd door Highlands op 24 juli 2024 08:28]

[supersnathan94]

Oh ja, legacy moven naar IaaS is meestal slecht plan.

Mwah valt mee hoor. Het alternatief is geen werkende software at all. Voor business continuity perspective helemaal slecht plan.

AAD en O365 zijn maar in een paar organisaties echt interessant. En hoewel het Leuk klinkt voor de ontwikkelaar is het voor de gebruiker niet per se fijn. Zo heb ik met AzureAD heel veel issues gehad met passwords propageren en dat is precies datgene wat het zou moeten doen.

En integratie heeft dan juist ook veel te maken met het stukje serverless. Het afnemen van diensten en integreren daarvan is juist belangrijk in de cloud.

[nst6ldr]

Maar de vraag is wat de DoD precies wilt met JEDI. Als ik links en rechts ga lezen, zie ik dat MS de kantoorautomatisering gaat ondersteunen (ongetwijfeld Office356), en voor de operationele IT meer beschikbaarheid wilt bieden, wat toch wel suggereert dat er interne applicaties op de Microsoft infrastructuur gaat draaien. Dus in het laatste opzicht had AWS daadwerkelijk meer te bieden.

Wat de media en Jeff echter even vergeten te melden is dat er bepaalde normeringen komen kijken bij militaire IT (óók de kantoorautomatisering). Dat zijn beleidsregels die niet in een paar maanden zijn toegepast, in geval van AWS zou het zomaar kunnen zijn dat ze een drastische verandering in infrastructuur moeten maken waardoor de architecten van DoD een negatief advies hebben gegeven.

[yvez]

"wat toch wel suggereert dat er interne applicaties op de Microsoft infrastructuur gaat draaien. Dus in het laatste opzicht had AWS daadwerkelijk meer te bieden."

Zou je kunnen uitleggen wat je precies bedoelt? Het MS Azure platform is namelijk heel erg volwassen. Ik ken AWS niet goed genoeg dus ik durf niet te zeggen welke beter is, vandaar mijn vraag aan jou.

Daarnaast, is het inderdaad moeilijk echt een conclusie te trekken want we weten niet met welke requirements DoD de markt is op gegaan. Tot ik echt het tegendeel hoor, krijg ik een beetje een onderbuik gevoel van "ik vind het niet eerlijk en wil die 10 miljard hebben". MS is niet een of andere speen zuigende kind in de markt...

[nst6ldr]

Zou je kunnen uitleggen wat je precies bedoelt? Het MS Azure platform is namelijk heel erg volwassen. Ik ken AWS niet goed genoeg dus ik durf niet te zeggen welke beter is, vandaar mijn vraag aan jou.

Qua flexibiliteit is AWS meer volwassen, zo heeft het betere Linux support. Die flexibiliteit is iets wat je voor domein-specifieke applicaties nodig gaat hebben. Ik vermoed dat bijvoorbeeld een Tactical Data Link veel makkelijker te integreren is op AWS dan het Microsoft/NT gebaseerde Azure. Het zal niet onmogelijk zijn - en de vraag is of DoD met dit contract ook C4I systemen wilt bedienen - maar het zal een stuk omslachtiger werken.

Nu weet ik wel dat Amazon bij het begin van deze aanbesteding al watertandend naar het contract zat te kijken, zo deden ze allerlei uitspraken over hoe het hun op de bui geschreven stond, maar toch vermoed ik dat ze op beleidsniveau en normeringen niet konden opboksen tegen Microsoft. Ik weet wat Microsoft al meermaal een contract heeft gehad met de DoD over onder andere een Airforce specifieke Windows levering en verschillende kantoor applicaties voor op kazernes. Wellicht was de stap naar Linux voor Microsoft kleiner dan de stap naar volledige DoD compliancy voor AWS.

[Mellow Jack]

wat bedoel je met betere Linux support? Als je denkt dat azure een nt gebaseerd feestje is heb je er weinig ervaring mee. Al jaren krijgen Linux ontwikkelingen voorang binnen Azure t.o.v. Windows. Zelfde gaat op voor bijv. Python en Java t.o.v. .net

[Reactie gewijzigd door Mellow Jack op 24 juli 2024 08:28]

[yvez]

Mmmmm, again, ik ken AWS niet goed genoeg, maar linux support binnen het Azure platform is echt insanely goed. We hebben een sloot aan servers virtueel over gezet naar Azure en dat loopt echt als een trein. Support van MS daarin was trouwens ook top, mag ook gezegd worden.

"Ik vermoed dat bijvoorbeeld een Tactical Data Link veel makkelijker te integreren is op AWS dan het Microsoft/NT gebaseerde Azure"

Vermoed vind ik een moeilijk woord, want dat lijkt er op dat je het dus niet weet...en dat was wel mijn vraag.

"maar toch vermoed ik dat ze op beleidsniveau en normeringen niet konden opboksen tegen Microsoft. "

Weer dat woord vermoed.....maar, hoe bedoel je dat precies?

[tweaknico]

Hm. Het gaat om de DoD... hebben die geen redundantie nodig.
Je zou verwachten dat de 3 grootste US aanbieders (Amazon, Google, Microsoft) hier gezamenlijk iets moeten opleveren...

[Reactie gewijzigd door tweaknico op 24 juli 2024 08:28]

[mrwiggs]

Waarom niet allebei 5 miljard? Lijkt me voor defensie sowieso beter qua risicospreiding. Tuurlijk zal je dan wat extra overhead hebben, maak er dan 5,5 miljard van.

Edit: dit lijkt ook het plan te zijn, maar de stap zou in 1 keer te groot zijn:

Het is enigszins opvallend dat alle clouddiensten door een enkele aanbieder verzorgd worden, maar het Pentagon is ervan overtuigd dat dit de beste eerste stap is in het kader van de algehele ict-modernisering die het nodig heeft. In de toekomst zouden clouddiensten echter wel door verschillende bedrijven geleverd moeten worden, stelt de Amerikaanse defensie.

[Reactie gewijzigd door mrwiggs op 22 juli 2024 20:49]

[supersnathan94]

Omdat je niet voor niets 10 jaar een contract hebt. Je gaat een enorme vendor lock-in aan als je cloud native gaat. Kijk naar microsofts azure Kubernetes service. Die is net uit beta en heeft geen cluster scaling. Wil je dat uitbreiden mag je het cluster verwijderen en opnieuw aanmaken. Dat is iets wat bij amazon en anderen wel kan (waarmee AKS wat mij betreft al direct af valt maargoed). Het is net een jaar uit beta.


Je gaat echer toewerken naar een cloud native systeem (als je het goed wil doen) en gaat daarmee langzaam je architectuur omzetten naar microservices, stateless operations, serverless compute. Uiteindelijk scheelt dat gewoon dikke euro’s. Maar kost je wel flexibiliteit mbt waar je spul draait qua cloudomgeving. In ieder ding is dat weer anders.

Je kunt dan echter niet twee clouds door elkaar gaan gebruiken. Op deze schaal zou je kunnen zeggen oke de ene helft van het bedrijf gaat z’n ding doen in AWS en de andere helft in Azure, maar dat op een gegeven moment ook scheef lopen.

[mrwiggs]

Kijk naar microsofts azure Kubernetes service. Die is net uit beta en heeft geen cluster scaling.

Jawel, je kunt zowel node pools schalen als extra node pools toevoegen. Ook is AKS al dik 2 jaar GA.

Je gaat echer toewerken naar een cloud native systeem (als je het goed wil doen) en gaat daarmee langzaam je architectuur omzetten naar microservices, stateless operations, serverless compute.

Cloud Native is prima maar dat kan prima zonder vendor lock-in met de (managed) Kubernetes-oplossingen op AWS, Azure en GCP.

Je kunt dan echter niet twee clouds door elkaar gaan gebruiken.

Waarom niet? Ik zit in de cloud consultancy en adviseer en implementeer multi-cloud-strategieën al tijden. Voor het Kubernetes-tijdperk wat een multi-cloud-strategie lastiger maar sinds de komst van Kubernetes is dat echt stukken makkelijker geworden. Alleen state management is een lastiger verhaal.

[supersnathan94]

Nah die twee jaar GA is niet waar. Ik heb voor een klant het in de gaten gehouden en ze zijn in Nederland echt nog niet zo lang uit beta hoor. Misschien een jaar of anderhalf. Dat is voor een product van dat caliber relatief “net”. Kennelijk kan handmatig schalen dus wel nu, maar autoscaling leek nog een issue. Is dat ondertussen ook aanwezig?

Cloud Native is prima maar dat kan prima zonder vendor lock-in met de (managed) Kubernetes-oplossingen op AWS, Azure en GCP.

Ja maar dan ben je dus niet cloud native. Je hebt hoe dan ook werk te verzetten als je van de ene provider naar de andere wil en je daar bijvoorbeeld API management afneemt.

Als je alles in K8S draait en daar 1 route naar binnen hebt dan gaat dat best, maar zodra je met serverless aan de gang gaat en dat gaat automatiseren kun je gewoon niet zomaar zeggen joe we gaan naar Google.

Je kunt de vendor lock beperken door slim gebruik te maken van agnostische tooling als terraform, maar voor implementatie kom je er gewoon niet onderuit.

Voor het Kubernetes-tijdperk wat een multi-cloud-strategie lastiger maar sinds de komst van Kubernetes is dat echt stukken makkelijker geworden.

maar cloud-native != kubernetes. Kubernetes kun je verdelen over meerder vendors inderdaad. Dat is immers een standaard.

[mobrockers]

Nah die twee jaar GA is niet waar. Ik heb voor een klant het in de gaten gehouden en ze zijn in Nederland echt nog niet zo lang uit beta hoor. Misschien een jaar of anderhalf. Dat is voor een product van dat caliber relatief “net”. Kennelijk kan handmatig schalen dus wel nu, maar autoscaling leek nog een issue. Is dat ondertussen ook aanwezig?

Kubernetes bestaat sinds 2014. AKS is sinds 2018 GA in north europe. Het heeft ze dus 4 jaar gekost om een managed AKS dienst te leveren in Europe, en doen dit dus al meer dan 2 jaar generally available en niet in beta.
AKS multiple node pools en AKS cluster autoscaler zijn sinds een jaar GA.

Dat is niet 'net', zo lang bestaat het hele product nog niet eens.
Oftewel je hebt geen flauw idee waar je het over hebt.

[mrwiggs]

North Europe is Ierland, West Europe is Nederland. Maar beide GA per 13 juni 2018 inderdaad.

[supersnathan94]

Ligt ook een beetje aan de provider. In AWS heb je west eu 1 (ireland) en west eu 2 (frankfurt) volgens mij.

General availabikity is overigens gefaseerd uitgerold in de course van een paar maanden volledige GA is dus nog geen 2 jaar. Maakt verder niet uit.

In het gelinkte artikel staat vrij duidelijk alleen eu North.

We are also adding five new regions including Australia East, UK South, West US, West US 2, and North Europe. AKS is now generally available in ten regions across three continents, and we expect to add ten more regions in the coming months!

Het kan dus kloppen dat ze in juni 2018 daadwerkelijk public zijn gegaan, maar zoals je zegt is eu west een andere regio, en daarvan kan ik niet achterhalen wanneer die daadwerkelijk live is gegaan, maar mijn gevoel zegt dat dit niet juni 2018 is geweest, maar daadwerkelijk een paar maanden later.

Ik zal de twitter feed nog even bekijken of die het er nog op heeft staan.

[Mellow Jack]

als je een klein beetje relatie hebt met Microsoft krijg je heel snel toegang tot diensten en is GA altijd wel bespreekbaar als een dienst wel in regio X maar niet in regio Y.

Maar iig, ik heb +- 2 jaar geleden ook ermee gespeeld en herken me niet in jou negatieve punten

[supersnathan94]

Maar zoals mobrockers ook aangeeft is autoscaling een jaar in GA. Daar zou iij dan in orincipe ook tegenaan gelopen zijn als je daar mee ging spelen. Was voor ons echt een enorm probleem.

Wij hadden workloads die afhankelijk waren van externe requests. Die requests onden gestuurd worden van iedere willekeurige website voor tonen van kaartmateriaal. Dat kon na een bericht van RTL (nieuwsitem) rustig oplopen naar 6 miljoen in een paar uur. Dan moet jet gewoon heel snel kunnen schalen. Als je dan niet dynamisch nodes bij kan zetten moet je dus van tevoren je cluster bouwen voor ergste scenario. Dat kost serieus geld voor dingen die je vrij zelden gebruikt.

[mrwiggs]

Nah die twee jaar GA is niet waar. Ik heb voor een klant het in de gaten gehouden en ze zijn in Nederland echt nog niet zo lang uit beta hoor.

Zeker wel, in 10 regio’s (waaronder NL) GA sinds 13 juni 2018.

[supersnathan94]

Ik heb bericht nog een paar keer gelezen. Helaas staan daar de vijf originele regio’s niet in het bericht. De 5 die bij naam worden genoemd zijn valt NL niet onder (dat is eu west). Uit dit bericht kunnen wen dus niet opmaken of NL hier daadwerkelijk onder viel.

Hoewel nederland en ierland vallen onder het regional pair zou je dus verwachten van wel, maar ik kan hier helaas geen expliciete statements over vinden.

[mrwiggs]

West Europe zat bij de eerste vijf, zie hier, een pagina uit Wayback Machine van juni 2018.

West Europe is een van Azure’s grotere en eerdere Europe regions.

[Reactie gewijzigd door mrwiggs op 24 juli 2024 08:28]

[supersnathan94]

Dat bericht is van voor 13 Juni toen was het sws nog in beta. Ms heeft geen enkele formele historie op zijn websites helaas.

Kijk als ik fout zit zit ik fout zo simpel is het, maar ik kan gewoon niet concluderen dat het zo is

We zullen er maar van uitgaan dat wel zo is. Jammer maar is niet anders .

[Razwer]

MKB is wat anders dan FEDRAMP en daar gelden toch andere standaarden voor. Het lijkt mij onwaarschijnlijk dat een Nederlandse cloud consultant doorgewinterd is in FEDRAMP dus valt je niets te verwijten over wat je zegt, maar het is allemaal niet zo simpel als dat je denkt dat het is.

[feico.de.boer]

Als Nederlander kom je daar niet eens binnen.

[Razwer]

Dat is niet geheel waar.

Regarding the citizenship question, the FedRAMP PMO has clarified that there is no overall Federal requirement about citizenship. They did warn however, that the decision to use non-US personnel to support the system may limit the market reach of the cloud service.

https://www.infusionpoint...work-system-or-access-ssp

Daarnaast is indirect werk verrichten prima mogelijk als buitenlander, zelfs al willen ze je niet binnen hebben.

[Reactie gewijzigd door Razwer op 24 juli 2024 08:28]

[familyman]

Zou toch geweldig zijn als wij op europees niveau soortgelijke regels hadden

[CAPSLOCK2000]

Dat is niet geheel waar.

Ik weet er verder niks van, maar als ik die link van jou lees dan denk ik dat het toch vooral wél waar is.
Die waarschuwing in jouw citaat staat er niet voor niets. Als ik een beetje tussen de regels doorlees zie ik "in praktijk is het niet mogelijk".
Als ik een paar regels verder lees dan staat er inderdaad dat er geen Federale eis is, maar dat er wel "agencies" zijn die die eis hebben.
Verder zie ik op die pagina alleen maar voorbeelden van situaties waarin alleen US citizens zijn toegestaan.

Voor mij is de boodschap toch dat buitenlanders niet welkom zijn.

[mrwiggs]

Ik denk niet dat het simpel is - allesbehalve. Eigelijk bevestigt jouw argument mijn punt: er gelden andere standaarden. Waar MKB sneller een vendor lock-in accepteert en managed services wil afnemen voor kostenbesparing (ja, uiteindelijk zijn managed services vaak goedkoper), ontwikkelsnelheid en gebruiksgemak, is in het geval van Defensie juist veiligheid, beschikbaarheid en het feit dat je niet afhankelijk wilt zijn van een enkele partij doorslaggevend.

[Razwer]

disclaimer: dit is niet bedoeld als tegenargument. Dit is toevoeging ter informatie
Vendor lock-in op zich is niet zo zeer een wegende factor in zulke contracten. Het contract in dit artikel gaat immers over een 10 jarig contract en is het contract zelf eigenlijk al een vorm van vendor lock-in.

Door (security) frameworks (zoals FEDRAMP) en andere requirements is deze tak van sport een compleet ander speelveld dan MKB en Enterprise. Waar filosofie een grote factor is voor MKB en Enterprise is dit bij dergelijke overheidsinstanties vooral geleid door framework beleid. Nu kan je natuurlijk argumenteren dat een framework ook een filosofie is, maar in het "bedrijfsleven" is dat veelal "vloeibaar" waarbij high security overheidsomgevingen dit flink rigide is.

Het is vermakelijk om de reacties van velen op dit artikel te lezen waar uit blijkt dat ze er van uit gaan dat FEDRAMP omgevingen "gewone" Azure of AWS omgevingen zijn en daar de reacties op baseren.

[Reactie gewijzigd door Razwer op 24 juli 2024 08:28]

[blinchik]

Alleen zijn die microservices ook inderdaad heel cloud afhankelijk. En zo bouw je weer een gigantische vendor lockin in. In het begin scheelt het euro's, maar het wordt op termijn vaak heel duur. En als je cloud provider voor die ene microservice opeens het dubbele vraagt dan voorheen, dan kan je alleen maar "ja meneer" antwoorden. Stopt de provider met het aanbieden van jouw gebruikte microservice? Pech. Wordt er iets veranderd en is er geen backwards compatibility? Pech.

Het is leuk voor programmeurs omdat het snel werkt, maar een ramp naar de toekomst qua planning vna budgetten en de mogelijkheid om over te schakelen naar een ander platform. Want iets wat in Amazon draait, zet je niet zomaar over naar Google of Microsoft of andersom. Er zijn uiteraard projectjes zoals Terraform die in principe cloud onafhankelijk zouden moeten kunnen deployen, maar daar zitten toch nog heel wat haken en ogen aan.

Ik heb al enkele projecten moeten doen waarbij de klant een heel deel in Amazon had, wat op termijn zo duur werd, dat het terug moest verplaatst worden naar een datacenter. Meestal kwam daar bijna een volledige rewrite bij kijken.

[EraYaN]

Microservices zijn gewoon eigen code hoor, jij bedoelt denk ik SaaS en PaaS oplossingen. Daar gaan je argumenten wel op, maar voor niet nader gedefinieerde "microservices", kunnen toch vrij makkelijk naar een andere basis infra gaan, helemaal als je zo op Kubernetes cluster draait. Hooguit moet je infra team wat werk verzetten (terraform specificaties aanpassen bijvoorbeeld). Ook amazon -> een eigen data center is voor veel microservices helemaal geen probleem en voor de populairste SaaS/PaaS oplossingen zijn er vaak de open source originelen om op terug te vallen zonder al te veel code wijzigingen.

[Cartman!]

Welke diensten precies zijn er dan zoveel duurder geworden in de loop der tijd? AWS staat bekend dat bij hun de prijzen juist steeds lager worden vanwege de hogere schaalgrootte die ze kunnen bereiken.

[jhnddy]

Dat is natuurlijk ook typisch gevalletje concurrentie uitschakelen en groeien. Als je eenmaal dominant bent, kun je vanzelf je prijzen laten stijgen.

[Cartman!]

Absoluut, echter volgens @blinchik laten ze juist de prijzen stijgen dus ik ben benieuwd welke prijzen er dan gestegen zijn terwijl ik t alleen steeds goedkoper zie worden.

[blinchik]

Zelf heb ik geen goed zicht op de financiele transacties, ik kreeg gewoon de opdracht en de melding dat het AWS platform te duur werd tegenover de vorige self hosted setup en ik moest gewoon de projecten technisch begeleiden om alles terug over te zetten.

Ik denk dat het vaak ook een foute inschatting betreft. Cloud is hip en de consultent overtuigt de bazen.. We hebben 2 functies nodig, dat kost slects 0,01 euro per aanroep. Maar dan wordt het vaak, eigenlijk habben we 20 services nodig. En eigenlijk hebben we toch ook wel extra firewalling nodig. En liefst een appliance in aws, want het gaat over vertrouwelijke data en we willen dus niet dat cloudfront er tussen zit omdat daar de data gedecrypteerd wordt om filtering te kunnen doen. Oh, en we hebben ook transfer nodig. Etc etc. Na een tijd werden de uitgaven ook vrij onoverzichtelijk, van wat gaat nu eigenlijk waar heen en waarom, heb ik vaak horen zeggen.

Die zaken gaan misschien ook wel op voor self-hosted dingen, maar je moet natuurlijk wel een infrastructuur kopen. Als je bv. enkele blade servers, firewalls en storage koopt, dan kan je met de inschatting van de AWS services wel denken: oh, op 5 jaar hebben we net een beetje winst, dus wordt het wat goedkoper en we moeten geen onderhoud meer doen (wat natuurlijk onzin is, want onderhoud moet je overal doen, of het nu in de cloud is of niet).

Alleen heb je met die eigen infrastructuur meestal redelijk wat overcapaciteit (je kan geen halve server kopen). En als je budgetten ongeveer in dezelfde lijn lagen, dan wordt die overcapaciteit opeens gratis (en ook testservers draaien op die overcapaciteit) en wordt het on premise verhaal goedkoper, terwijl je bij AWS toch voor alles zal moeten betalen.

Het is waarschijnlijk een ander verhaal in hele grote ondernemingen, die wel heel flexibel moeten zijn en soms opeens 100 nieuwe servers nodig hebben, of net heel kleine (dan loont het niet om eigen infrastructuur aan te kopen).

[Cartman!]

Dat heeft puur te maken met de inschatting van de afnemer, niet met dat AWS de dingen duurder maakt en dat is iets anders dan je deed voorkomen.

Over het algemeen, als je cloud native draait, zou je altijd afnemen op basis van wat je nodig hebt en is overcapaciteit niet aan de orde. Testservers draaien op dezelfde machine als productie; ik zou dat niet aanraden ook.

Maargoed, ieder z'n wensen natuurlijk

[blinchik]

Testservers draaien niet op dezelfde machine... het gaat over aparte VM's. En dat kan echt geen kwaad als die op dezelfde fysieke machine draaien, in een andere VLAN. Mogelijk draaien die in Amazon ook zelfs op dezelfde fysieke machine :-)

Ik heb het ooit ook eens uitgerekend voor ons eigen bedrijf. Als we alles zouden overzetten naar Amazon, kwamen we duurder uit (en een eigen hosted infrastructuur vind ik persoonlijk toch ook wel wat handiger qua snapshots en backups en "echte" vm's). En we hebben nu ook overcapaciteit, dus dat is mooi meegenomen.

[K-aroq]

Als je je eigen microservices bouwt heb je geen vendor lock-in. Zolang de cloud provider micro-services en containers ondersteund zit je goed. Het gaat pas fout als je specifieke zaken gaat gebruiken die de cloud provider aanbiedt. AWS biedt hele gave functionaliteit die je heel eenvoudig in je eigen applicaties kunt gebruiken, maar dan zit je wel aan AWS vast. Aan de andere kant: als je die extra functies van AWS niet gebruikt, biedt AWS ook niet echt voordelen t.o.v. anderen.

[Transportman]

In theorie zou het niet uit moeten maken waar je het draait en krijg je juist gigantisch veel flexibiliteit mbt waar je spul draait, helaas is de praktijk anders. Ieder cloud is net anders, moet net anders ingericht worden, heeft net andere functionaliteiten wel of niet.

En twee dingen door elkaar, ook dat kan, maar vraag is of je dat moet willen. Het maakt de omgeving veel complexer omdat die 2 wel met elkaar moeten praten, je moet 2 omgevingen gaan onderhouden, mogelijk 2 aanbestedingen gaan doen, terwijl de voordelen maar heel beperkt zijn.

[supersnathan94]

Ook in theorie maakt het heel veel uit hoor.

De MS API gateway doet functioneel hetzelfde, maar is een kompleet ander product als de AWS gateway.

Draai je puur Kubernetes dan ja sure. Geen enkel probleem, maar het punt van de cloud is juist dat je shit gaat uitbesteden aan partijen die het al een keer gedaan hebben en het goed hebben uitgewerkt.

Zo kun je met Kubernetes een cronjob task maken die ieder kwartier draait, maar het bijhouden van die klok kost ook resources op je master. Draai je die in EKS dan kosten die machines je $114 per maand zoiets? Terwijl je op ECS managed verder geen kosten hebt en het dan iets anders moet doen, maar dat kost dan alleen de compute tijd en niet ook nog geld voor je K8S managers.


En twee omgevingen heeft wel nut natuurlijk, maar dat is maar zo beperkt dat is gewoon niet interessant. Zeker niet voor een partij als defensie (waar in US echt heeel veel onder valt).

[Sfynx]

Draai je puur Kubernetes dan ja sure. Geen enkel probleem, maar het punt van de cloud is juist dat je shit gaat uitbesteden aan partijen die het al een keer gedaan hebben en het goed hebben uitgewerkt.

Zo kun je met Kubernetes een cronjob task maken die ieder kwartier draait, maar het bijhouden van die klok kost ook resources op je master. Draai je die in EKS dan kosten die machines je $114 per maand zoiets? Terwijl je op ECS managed verder geen kosten hebt en het dan iets anders moet doen, maar dat kost dan alleen de compute tijd en niet ook nog geld voor je K8S managers.

In beide gevallen moet je zelf die cron job aanmaken, dus qua hoeveelheid werk is dat geen verschil. Dus bij K8s betaal je een management fee, maar in ruil daarvoor kan je op elke willekeurige K8s cluster op dezelfde manier een cron job aanmaken (standaardisatie) en dus ook overal dezelfde tools als Helm i.c.m. Argo CD gebruiken om dat te doen.
Dat zijn dingen waar ik zo'n management fee wel voor over heb, dat je nog enigszins vrijheid hebt bij welke partij je iets draait nadat je het hebt opgebouwd, en je hooguit de IAM, buckets en je Terraform specs opnieuw moet inrichten als je van cloud verhuist omdat de rest in de cluster draait of automatisch door de cluster worden opgezet (bv. block store, load balancers).

Als je niet voor ieder dingetje een apart cluster opzet merk je overigens niet zoveel van zo'n fee. Op kleine schaal zal ECS zeker het voordeligste zijn.

[Reactie gewijzigd door Sfynx op 24 juli 2024 08:28]

[K-aroq]

Als je alles zelf maakt kan je het op iedere cloud draaien. Maar dan maak je slechts gebruik van een paar procent van wat de cloud provider aanbiedt. Het voordeel van cloudcomputing is dan beperkt tot het up- en downscalen. Als je alles zelf maakt kan het ook bij een gewone hosting provider worden gezet.

[stftweaker]

Omdat je dan 2 partijen heb waar wat fout kan gaan. Kijk we hebben het hier over Microsoft en Amazon bepaald geen kleine jongens. Als er wat fout gaat wil je bij 1 partij je dienst hebben draaien zonder dat je af moet vragen wie wat waar.

[mrwiggs]

Maar het voordeel dat áls er wat fout gaat bij 1 partij, je hele infrastructuur niet gelijk helemaal plat ligt.

[jqv]

Of juist wel. Want als je activiteiten die moeten samenwerken verdeeld over 2 partijen, dan werkt het alsnog niet.

Elk voordeel heb z'n nadeel en anders om.

[enveekaa]

Als je een tweede platform gaat introduceren voor redundancy moet je heel scherp zijn op afhankelijkheden, het zou inderdaad niet veel zoden aan de dijk zetten als je applicatie A afhankelijk maakt van 2 platformen. Sterker... je beschikbaarheid zal er onder lijden, je hebt immers impact als een van de twee problemen heeft.

Het is dan ook belangrijk om het dubbel uit te voeren, en de load te verplaatsen als er een van de twee platformen problemen heeft. Het fijne van cloud is dat je (meestal) kan schalen naar behoefte wat het nog enigzins binnen de perken houdt qua kosten.

[jqv]

Ik snap je punt helemaal.
Maar dan vraag je tevens aan de overheid van de VS een veelvoud aan investeringen neer te leggen met voor de 2 platformen.

Vandaar de keuze voor 1 aanbieder.
En die kan ook 2 of keer routes aanbieden om alles draaiende te houden.

[enveekaa]

Veelvoud valt nog te te bezien, maar het wordt absoluut duurder en complexer.
De vraag is hoe belangrijk is het en wat is de impact van downtime. Het antwoord daarop bepaalt grotendeels het budget.

We zijn het volgens mij wel eens Een platform als Azure bijvoorbeeld biedt al hele mooie (geo)redundante oplossingen.

[Reactie gewijzigd door enveekaa op 24 juli 2024 08:28]

[Yucon]

Dat argument als zodanig is toch niet zo'n punt? Sterker nog, men heeft dat bij wapensystemen vaak bewust gedaan om niet van 1 leverancier afhankelijk te zijn. En boeing en spacex zijn om die reden ook parallel raketten aan het ontwikkelen die grofweg hetzelfde doel dienen.

[stftweaker]

Laten we zeggen he Amazon of Microsoft hebben een grote storing/iets fout gedaan. Dan is er geen support medewerker die met je gaat troubleshooten dan is er echt iets aan de hand en neemt een dedicated medewerker het over.

Je zou er dan voor kunnen kiezen om letterlijk alles te dupliceren bij een andere partij om dit te voorkomen. Maar dan is het wel 2x een contract van 10 miljard Of misschien nog wel meer vanwege extra maatwerk oplossingen.

Even ge-edit voor de mensen die mijn verhaal niet begrepen.

[Reactie gewijzigd door stftweaker op 24 juli 2024 08:28]

[Verwijderd]

Laten we zeggen he Amazon of Microsoft fucked up. Maar echt big time. Dan is er geen support medewerker die met je gaat troubleshooten dan is er echt stront aan het plafond. Vervolgens kan je dus het hele contract dupliceren bij een andere partij maar dan word 10 in 1 keer 20. Snap je?

Nee, ik snap werkelijk niets van wat je schrijft. Probeer het nog eens met wat duidelijke taal.

[stftweaker]

Speciaal voor jou ge-edit hopelijk kom je er nu wel uit. En zo niet dan this message wil self destruct.

[Razwer]

edit: verkeerd gelezen.

[Reactie gewijzigd door Razwer op 24 juli 2024 08:28]

[K-aroq]

Maar hoe zie je dat voor je? Als de helft kapot is heb je nog niks. Plus dat het een operationele nachtmerrie is. Stel je voor dat je een applicatie hebt bij provider A, die een database bij provider B gebruikt. Als er dan iets niet werkt moet je eerst gaan uitzoeken waar de fout zit. En aangezien het allemaal mensenwerk is, is de eerste reactie dat de fout niet bij jou zit. Dan heb je dus weer een eigen team nodig die over de partijen heen gaat troubleshooten. Als je met 1 partij werkt maak je een goede SLA en ligt de verantwoordelijkheid bij 1 partij. Penalties zijn dan veel makkelijker op te leggen als de provider in gebreke blijft.

[mrwiggs]

Je zet het niet op als “applicatie bij A en database bij B”, daar heb je niet zoveel aan (zelfs averechts). Zowel de applicatie als de database draaien bij beide providers. Alles wat state bevat (database, object stores) laat je realtime synchroniseren naar de equivalent bij de andere provider. Mocht bijv. RDS falen dan laat je zone AWS uitvallen en draait Azure door.

Wat betreft de load balancing vóór je applicatie kun je gokken op een enkele provider (deze hebben vaak een hogere uptimegarantie dan de gemiddelde service) of je doet het op DNS-record level (meerdere IPs in je A-record) of zelfs op nameserver level (bij je domeinnaam configureer je zowel de nameserver(s) van Route 53 als Azure DNS).

Penalties, verantwoordelijkheden en vingertje wijzen, het zal allemaal wel maar uiteindelijk is het doel dat de applicatie blijft draaien.

[Reactie gewijzigd door mrwiggs op 24 juli 2024 08:28]

[Blokker_1999]

Door het verdelen voeg je enorm veel complexiteit toe. Ineens moet je zorgen dat je redundantie gaat werken tussen verschillende providers. Waar je bij 1 provider veel van die virtuele netwerk redundantie kunt opzetten en overlaten aan de provider moet je daar ineens zelf weer aan de slag gaan. Je moet je mensen ook gaan opleiden voor 2 verschillende systemen. Je gaat je monitoring moeten opzetten voor 2 verschilende platformen.

Er is dus enorm veel werk dat je dubbel gaat moeten doen en de kosten sterk gaan verhogen. En wat win je er mee?

[Verwijderd]

Omdat het gebruik van meerdere publieke cloudproviders over het algemeen onbegonnen werk en het tegenovergestelde van productief is. Dan zouden ze beter voor een hybride oplossing kunnen gaan als risicospreiding een probleem is. ExpressRoute + VMWare/Hyper-V naar eigen datacenters en cloudoplossingen in Azure Government. Of de AWS-variant i.c.m. VMWare.

Er is sowieso risico wanneer je die kant opgaat, ook al knip je jezelf op naar 5 providers. Zowel AWS als Azure hebben provider-specifieke oplossingen die on-prem helemaal niet bestaan of geen drop-in vervanging hebben. Wanneer je duizenden VMs als Windows/Linux IaaS gaat doen moet je je afvragen als bedrijf waarom je graag je IT-budget in de fik steekt.

[mrwiggs]

Ik lees nu dat het wel het idee is om deze richting op te gaan, maar dat de snap daarheen in 1 keer te groot zou zijn (momenteel draait alles op jaren 80-90 systemen):

Het is enigszins opvallend dat alle clouddiensten door een enkele aanbieder verzorgd worden, maar het Pentagon is ervan overtuigd dat dit de beste eerste stap is in het kader van de algehele ict-modernisering die het nodig heeft. In de toekomst zouden clouddiensten echter wel door verschillende bedrijven geleverd moeten worden, stelt de Amerikaanse defensie.

[synoniem]

Gezien de dominante positie van Microsoft in officeomgevingen en onderliggende infrastructuur is het niet vreemd als de aangeboden cloud diensten goed aansluiten bij wat DoD al heeft en wil uitbreiden.

Dat sluit uiteraard niet uit dat Trump zich inderdaad met de aanbesteding bemoeid kan hebben maar hij is wel zo slim dat dat niet te bewijzen zal zijn.

Dus behalve vertraging en imago oppoetsen zie ik Amazon er niet zoveel bij winnen bij deze rechtszaak.

[johnkeates]

> Dus behalve vertraging en imago oppoetsen zie ik Amazon er niet zoveel bij winnen bij deze rechtszaak.
Je kan met voldoende berichtgeving anders prima een antitrust zaak opwarmen. Die kunnen ze dan misschien niet zelf starten, maar dat is niet nodig als iemand anders dat voor je doet (bijv. een groepje bij de overheid).

> positie van Microsoft in officeomgevingen en onderliggende infrastructuur is het niet vreemd als de aangeboden cloud diensten goed aansluiten

Dat is het wel, want slechte spullen zijn ook in kwantiteit nog steeds slechte spullen. Dat wil niet zeggen dat Microsoft's spul slecht is, maar "goed aansluiten bij" betekent niet zo veel als het zo breed getrokken wordt als een publieke cloud of govcloud.

[Reactie gewijzigd door johnkeates op 24 juli 2024 08:28]

[familyman]

bewijs is irrelevant in de us. Dus veel moeite om het ter verbergen, heeft hij echt niet gedaan, denk ik

[Verwijderd]

Amazon acht het AWS-aanbod 'relatief sterker' en blijft 'een eerlijke, objectieve en onpartijdige beoordeling blijven nastreven'.

Lijkt me ten eerste sterk afhankelijk van wat je er allemaal gaat draaien... Tenzij iemand mij bijvoorbeeld Amazon Teams en Amazon Office 365 kan aanwijzen in de AWS portal

[Baklap-XD]

Wel mooi hoe Meneer Amazon de President van datgene beschulidigd waaraan ze zich zelf schuldig maken. Hoe ironisch.

Volgends mij staat iedereen vrij om te kiezen om wat voor reden dan ook. Amazon is niet gekozen helaas. Slechte veliezers zijn het.

[BobJung]

Ik zou als overheid voor geen goud voor een commerciële partij als Amazon kiezen. De overnames en de manier waarop ze zich op dit moment in NL manifesteren vind ik geen fijn idee, ze groeien als wereld speler veel te hard en zijn te dominant. Zowat op elk artikel online verkrijgbaar. Dat is op termijn dodelijk voor concurrentie. Laat staan hoe dat er over 10 jaar uitziet voor een overheid.

[Ayporos]

Ja en nee.

Ja je hebt gelijk.. en als je élke willekeurige persoon hierover spreekt en de horrorverhalen van Amazon aankaart zullen ze het allemaal met je eens zijn dat het een slecht bedrijf is.. en vervolgens zullen al deze mensen alsnog gewoon bij Amazon hun spullen kopen net zoals we allemaal nog steeds Chinese meuk kopen.. en Starbucks koffie.

Als we allemaal zo graag de kleine 'familizaak' liever hadden zien overleven en niet opgeslokt/kapotgeconcurreerd zien worden door deze grote jongens, dan hadden we niet met onze portemonnee massaal gestemd op deze grote jongens.. maar dat doen mensen nou eenmaal wel.

Microsoft is overigens ook geen lieverdje hoor... en eerlijk gezegd, denk ik dat er weinig/geen grote bedrijven zijn die wél 'lieverdjes' zijn.

Of Trump zijn persoonlijke mening omtrent Amazon een rol heeft laten spelen weet ik niet, en eerlijk gezegd boeit me dat ook eigenlijk niet super veel.
Als ik een nieuwe auto koop zal ik nooit een Franse auto kopen (renault, peugot, citroen), gewoonweg omdat ik Fransen niet mag.. en als ik een baas was van een bedrijf zou ik dus ook geen Franse lease-auto's willen aanbesteden... is dat het beste voor het bedrijf?.. I dunno, het is mijn bedrijf dus ik heb de authoriteit en het recht om dat te beslissen. Als blijkt dat het níet goed is voor het bedrijf dan wordt ik afgezet door het bestuur en zetten ze er maar iemand anders neer.

[K-aroq]

Als je niet gekozen bent en je hebt een vermoeden dat er bij de selectie oneigenlijke criteria zijn gebruikt is het niet zo gek om dit aan te kaarten. Het gaat om een hoop geld. Als achteraf blijkt dat het allemaal volgens de regels is gespeeld dan is het pech.

Overigens kan ik me niet zo goed voorstellen dat uitgerekend het Pentagon zich door Trump laat beïnvloeden.

[Bever!]

Tja beide bedrijven zijn onderdeel van de controlestructuur dus ze winnen allebei..

[litebyte]

Ik denk dat inderdaad velen niet kunnen bevatten hoe enorm de VS overheid is verweven in (VS) tech companies waar de rest van de wereld gebruik van maakt. Er wordt met priemende vingertjes door westerse politici naar China verwezen maar het zou zeker als EUropa goed zijn eens te kijken om de afhankelijkheid van VS bedrijven en technologie drastisch te beperken en een vergelijkbare positie innemen als tegen China.

[K-aroq]

Er zitten geen overheidsvertegenwoordigers in de Raden van Bestuur van VS techbedrijven. Dat is toch een fundamenteel verschil. En in Europa/Nederland is het niet anders he. Bedrijven lopen hier ook de ministeries plat. En dat is op zich helemaal niet verkeerd. Het bedrijfsleven moet overheden vertellen wat de (technische) mogelijkheden zijn. Die informatie is elders niet beschikbaar.

[Zoijar]

Vrije-markt-kapitalisme: een systeem waar je een klant kan aanklagen omdat hij niet voor jouw product kiest zonder een naar maatstaven van jouw bedrijf goede reden

[CEx]

Behalve dat juist dit een inperking is van de vrije markt. Het gaat hier om een aanbesteding.

[Zyphlan]

Conclusie : We moeten een goede reden verzinnen voor onze aandeelhouders om het niet als onze fout te zien......

Heb ik ook wel is meegemaakt ... Dan win je een tender op de alle technische specificaties en prijzen en heb je een concurrent die dan een kaart zoals dat gaat spelen.

Geef ze trouwens volledig gelijk ( amazon) aangezien het toch wel om een gigantisch contract gaat maar je zult toch echt met bewijzen moeten komen bij zulke claims om het nog te kunnen winnen.


Throughout our protest, we’ve been clear that we won’t allow blatant political interference, or inferior technology, to become an acceptable standard

Wel een lastig argument ...... Want definieer betere technologie? Als hetgeen Microsoft aanbied de taken kan voldoen is het gewoon geschikt.

[Reactie gewijzigd door Zyphlan op 24 juli 2024 08:28]

[dasiro]

10 miljard over 10 jaar is geen gigantisch contract, niet voor het DoD en ook niet voor Microsoft of Amazon. Wat het wel is is een prestige-contract waar ze op kunnen verder bouwen en DAT is de echte inzet.

[Zyphlan]

1 miljard per jaar is gewoon een gigantisch contract hoor.

Maar het klopt de orders die eruit vooruit kunnen vloeien zijn ook belangrijk en het is een prestige project maar 1 miljard per jaar is toch toch bijna 1% van de totale omzet van Microsoft van 1 contract en het staat 10 jaar vast dus je kunt elk jaar 1 miljard omzet bijschrijven.

[dasiro]

met een budget van meer dan 700 miljard dollar per jaar is een miljard peanuts

[K-aroq]

Maar voor Microsoft of AWS is het wel veel. Heel veel zelfs. Het team dat dit heeft binnengehaald zijn echt wel de helden in zo'n bedrijf.

[dasiro]

Microsoft haalde in Q1 een omzet van 13.4 miljard dollar met een stijging van 47% voor azure (laagste stijging ooit voor cloud computing), Amazon's AWS deed met 10.2 miljard en een stijging van 33% iets minder. Dat wil dus zeggen op jaarbasis dit kwartaal geëxtrapoleerd zonder rekening te houden met de groei een aandeel van 2% of 2.5% respectievelijk en dat voor de komende 10 jaar in een booming business (zie groeicijfers van hiervoor) is heel beperkt qua impact.
bron
helden binnen de cloud-salesafdeling misschien, maar nobele onbekenden voor al de rest

[supersnathan94]

Maar dat kan alleen als defensie goed motiveert hoe het zijn keuzes heeft gemaakt. Anders heb je er nog niks aan. Je weet namelijk dan niet waarom ze het dan doen.

[Zyphlan]

Beide een gunning doen zou ik persoonlijk ook doen puur om niet van 1 partij afhankelijk te zijn maar ik betwijfel dat Trump de tender schrijft en het lijstje komt van defensie dus gok dat er een reden is om 1 partij het te laten doen.

[jqv]

Ik zag dat eerder voorbij komen.
Beide een gunning doen.

En er later achterkomen dat de samenwerking en communicatie totaal vastloopt en je een totaal onwerkbare situatie krijgt.

[Zyphlan]

Ik gok inderdaad dat het daarom bij 1 partij blijft

[Highlands]

Interessant, je zou ook kunnen stellen dat een partij die zo dominant is in bedrijfsleven/ media (zowel WSJ en Prime) / Retail juist een risico vormt. En dat juist Bezos daar mee weg komt.

[Reactie gewijzigd door Highlands op 24 juli 2024 08:28]

[InsanelyHack]

Dat klopt maar dat geldt voor Microsoft en Google net zo goed. Het wil ook niet zeggen dat deze bedrijven dan geen eerlijke behandeling meer hoeven te krijgen bij aanbestedingen. Hun dominantie is uiteindelijk ontstaan door succes waarbij toezichtinstanties nooit hebben ingegrepen.

[litebyte]

'Geven' onder bepaalde voorwaarden dus.