Groei Amazon Web Services neemt iets af, presteert toch beter dan verwacht

Amazon Web Services boekte in het eerste kwartaal van 2023 een omzet van ruim 21 miljard dollar, wat een stijging is van 16 procent ten opzichte van het kwartaal daarvoor. Een jaar geleden steeg de omzet uit de cloudafdeling van de techgigant nog met 37 procent.

De stagnerende groei van de AWS-afdeling zorgt zelfs voor een daling van het operationele inkomen binnen deze divisie, namelijk omgerekend 4,6 miljard euro in Q1 van 2023 tegenover bijna 5,9 miljard euro in hetzelfde kwartaal vorig jaar. Na de verkoop van producten in de webshop en het faciliteren van webshopverkopen van derden zijn de Amazon Web Services-clouddiensten de belangrijkste inkomstenbron van het miljardenbedrijf; Amazon is daarin verreweg de grootste binnen deze sector.

Ondanks de mindere resultaten van deze belangrijke afdeling meldt Amazon een totale omzet van 115,5 miljard euro in Q1 van 2023, wat een stijging van 9 procent is ten opzichte van hetzelfde kwartaal in 2022. Dat goede resultaat zorgt voor een winst van net geen 2,88 miljard euro, een bedrag dat ruim 41 procent hoger uitvalt dan verwacht en een immense stijging ten opzichte van het eerste kwartaal van 2022, gezien het bedrijf toen nog een verlies van bijna 3,5 miljard euro draaide.

Hoewel de resultaten dus een stuk beter zijn dan vorig jaar, is Amazon voorzichtig; een 'onzekere economie' zorgt volgens het bedrijf voor het conservatiever uitgeven van geld, zowel bij Amazon als de consument. Dat uit zich wat die laatste categorie betreft in een gelijk gebleven uitgavepatroon in de webshop. Wat Amazon zelf betreft uitte zich dat dit jaar onder andere in 18.000 ontslagen in januari en nog eens 9.000 werknemers die in maart moesten vertrekken.

Door Yannick Spinner

Redacteur

28-04-2023 • 20:32

34

Submitter: Anonymoussaurus

Reacties (34)

34
34
16
1
0
11
Wijzig sortering
Is Microsoft Azure de reden van de daling?
Zijn er op dat gebied recente ontwikkelingen rond Azure? Zit namelijk zelf niet helemaal in die getallen en kan zo snel ook geen recente artikelen vinden. Ik vind het altijd een beetje lastig inschatten namelijk welke provider nou op grote schaal het meest in gebruik is, en wáár, en hoe groot de verschuiving is. Omdat het me wel lijkt dat de meeste bedrijven vastroesten in één bepaalde partij en niet voor de lol steeds gaan switchen als de migratie eenmaal is afgerond. In Nederland lijkt Azure de grote standaard, toch zeker bij de bedrijven die ik achter de schermen heb mogen bekijken. Maar bij internationale online diensten kom ik eigenlijk voornamelijk AWS tegen, nooit Azure. Ook op IT-opleidingen krijgt AWS aardig wat aandacht.
Microsoft is meer gericht op ontwikkelaars en ik zie dan ook dat ontwikkelaars vaak voor Azure kiezen. Ik ben zelf ook 25+ jaar ontwikkelaar en de laatste 20 jaar vooral veel .NET gedaan. Vanuit die hoedanigheid ook veel met Azure in aanraking geweest.

Ik werk ook voor andere klanten, waarbij AWS de standaard is en hoe meer ik er mee werk, des te meer ik het ga waarderen. Het ziet er allemaal wat meer basic uit, maar het is meestal bijzonder goed uitgedacht, relatief eenvoudig en vooral zeer stabiel. Ik ben dan ook geneigd eerder voor AWS te kiezen dan voor Azure. Ook merk ik dat mensen met een niet-MS achtergrond, managers en systeembeheerders vaker een voorkeur hebben voor AWS. Ik kan me daar wel wat bij voorstellen, vanwege de enorme schaal en degelijkheid. Ook heeft Amazon met zijn S3 cloud storage een API die veruit het meest gebruikt en ondersteund wordt. MS blijft met zijn Azure Blob storage erg achter en vertikt het om een S3 compatible API aan te bieden (iets dat Google wel doet).

Maar het ligt ook wel een beetje aan de use-case. Microsoft Azure AD is erg compleet en integreert geweldig met veel andere zaken (o.a. on-premise AD). AWS heeft Cognito voor (extern) user-management en dat is weer een draak van een service. Incompleet, bug reports die jaren openstaan en ga zo maar door. Het interne identity systeem (IAM) daarentegen is juist enorm krachtig vergeleken met het systeem van Azure.

Google heeft ook nog GCP, maar dat vind ik eigenlijk de minste van de grote drie. Alleen als je vol inzet op Kubernetes, dan vind ik Google het overwegen waard. Ook slaat Google de plank behoorlijk mis door bepaalde services uit te faseren (bijv. IOT core) en geen alternatief te bieden. Stel dat je daar vol op hebt ingezet, dan ben je flink de Sjaak.

Ik kan trouwens aanbevelen om je infrastructuur met Terraform te beheren. Dan blijf je weg uit die trage consoles en is het ook veel beter reproduceerbaar (en fijner dan zo'n howto deploy document bij te houden). Ook merk ik dat je automatisch de boel veel beter dichttimmert dan handmatig geklooi in de console/cli of via onhandige proprietary tools (zoals Azure ARM / Bicep of AWS Cloudformation).
Is het ook niet vooral dat bedrijven die veel applicaties gebouwd hebben voor hun personeel die werken met de rollen structuur van de on premise active directory. Dan is het relatief makkelijk om die structuur intact te houden als je naar Azure verhuist.

Als je een bedrijf bent dat cloud native is begonnen de afgelopen jaren (zeker toen aws nog echt een voorsprong had tov azure) is de kans groter dat je voor AWS gekozen hebt.

[Reactie gewijzigd door Leejjon op 26 juli 2024 17:30]

Dat klinkt inderdaad wel als een logische verklaring. Moet ook zeggen dat (Azure) AD in de organisaties die ik heb gezien wel een grote rol had, dus wel aannemelijk dat dit vaak een van de redenen is.
Naar mijn weten inderdaad best weinig ontwikkelingen. Op de IT-opleidingen lijkt er een verschuiving te zitten. Op de IT-opleiding waar ik zat is de verschuiving juist van AWS naar Azure omdat het toch vanuit het praktijk meer gebruikt lijkt te worden.

Voor de redenen die Leejjon al aangaf lijkt het voor bedrijven die nu aan het overstappen zijn veel aantrekkelijker om naar Azure te gaan dan AWS.
Meh, het is heel lastig te vergelijken omdat MSFT haar M365 abbonnementen omzet bij de cloud omzet telt. We weten dus niet hoeveel 'pure' Azure omzet ze hebben en draaien.

Afgaan op anekdotisch bewijs (e.g. mijn eigen ervaring ;)) zou ik zeggen dat binnen NL, Azure steeds groter wordt. Ik ken geen enkel (groot) bedrijf dat naast Azure ook zijn voeten dipt in AWS, maar ik ken menig AWS klanten die stiekem her en der toch nog wat ook in Azure doen (veel meer dan alleen AzureAD services). Ik ken bijvoorbeeld zo'n typisch groot AWS huis vrij goed (een van de grootste van NL, qua AWS spent) en hun hele data architectuur gaat op Azure.

Let wel; dit is de Nederlandse markt. Als je kijkt naar de VS, daar liggen deze zaken heel anders. Komt ook omdat de marktpenetratie van Office (ja, Word, Excel maar bovenal Outlook) daar veel lager is dan in Nederland.

Dus de groei van AWS in NL is beperkt, terwijl dat plukje bedrijven dat in AWS zit nu soms toch stiekem ook wel beweegt naar Azure.

Maar again, dit is anekdotisch; ik heb een redelijk beeld van de NL enterprise markt (zat jarenlang bij een MSP) maar ik zal niet beweren de waarheid in pacht te hebben.
Het is erg praktisch als je al een on-premise AD hebt of een Azure AD vanwege Teams of Microsoft 365 om dit ook te kunnen gebruiken voor je overige Azure services. Ook is Azure beter in het hosten van Windows gebaseerde services (alhoewel met .NET Core steeds meer richting Linux gaat).

Azure is de laatste jaren best volwassen geworden, maar de beginjaren waren lastig. Vooral de overschakeling van "classic" naar ARM had flinke gevolgen. Ook is MS erg van de verandering. Had je eerst Cloud services, daarna werd het Service Fabric en nu gaat het meer naar Kubernetes. Wat dat betreft is AWS een stuk stabieler en dat is erg prettig.

Bij een klant waar ik voor werk hebben we eigenlijk alles in Azure draaien. Alleen de off-site backups gaan juist naar AWS S3. Deels omdat Veeam veel beter met S3 werkt dan met Azure, maar ook zodat we dit juist helemaal los kunnen trekken van Azure AD. Er zijn slechts twee IAM users. Eentje die de backup maakt (en bestaande backups niet kan modificeren) en een root user (daar liggen de credentials in een kluis voor noodgevallen). Soms is geen integratie ook een voordeel :-)
Ja zeker, slim om het zo op te zetten.

Over s3 gesproken, het is mijn grootste wens voor Azure om blob storage een s3 compatible api te geven. S3 is gewoon veel beter ondersteund dan de tegenhangers, dat heeft AWS echt goed gedaan (voordeel van de eerste “grote” te zijn op dit gebied). Slim om je backups vendor onafhankelijk te maken!
Precies datzelfde heb ik. Ik ben toevallig deze week bezig om voor een klant een oplossing van AWS naar GCP te migreren. Het feit dat GCS wel een S3 interoperability heeft maakt het zoveel makkelijker. Helaas niet 100% compatible, maar vrijwel alle operaties zijn beschikbaar. Ook importeren vanuit S3 is een fluitje van een cent (mist je geen PB aan data hebt).

Minio is een zeer goede S3 compatible storage en die had ook een Azure gateway. Helaas wordt die niet meer ondersteund (Minio zelf gelukkig nog wel). Dat was soms nog wel een goede tussen oplossing, maar die is helaas nu ook weggevallen. Ik heb de indruk dat MS niet wil toegeven dat AWS gewoon de "standaard" heeft neergezet.
Volgens de cijfers groeide Azure wel iets meer dan aws in Q1, iets van 26% tgv de 16% van aws. Maar bij Microsoft geven ze niet expliciet de cijfers van Azure dus voor analisten is het zelf destilleren uit de cijfers wat de groei van Azure alleen is geweest.
Er is in ieder geval veel concurrentie tussen deze twee leveranciers met Google Cloud als derde maar nog relatief klein vergeleken met deze twee.

Edit;typos

[Reactie gewijzigd door david-v op 26 juli 2024 17:30]

Algemene competitie lijkt me. Azure, GCP, Oracle Cloud, Alibaba cloud, ...

Ook zijn meer en meer bedrijven wakker aan het worden en beseffen ze dat gewoon alles "in de cloud duwen" vooral heel duur is, duurder dan het in je eigen DC houden.
Dat laatste statement is erg ongenuanceerd. Het hangt echt helemaal af van het soort workload en de capaciteiten om het zelf te doen.
Klopt helemaal. Wanneer je een lift en shift doet van je on prem naar de public cloud ben je waarschijnlijk duurder uit.

De cloud geeft veel meer flexibiliteit maar je moet wel de workloads aanpassen om efficiënt om te kunnen gaan met de mogelijkheden in de public cloud.
Mijn ervaring met meerdere bedrijven is dat ze nogal snel denken dat alles goedkoper is. En dus ook gaan lift-n-shiften.

Met alle gevolgen van dien.

Je moet idd de juiste workload op de juiste manier naar de cloud brengen. Autoscaling, serverless waar het nuttig is, ... cloud vraagt een goed financieel beheer.
Ik ben benieuwd naar bronnen van die laatste opmerking.
Klopt wel als je IaaS bv op IaaS houdt. Naar de cloud gaan geeft je alle tools om van IaaS naar PaaS te gaan en van PaaS naar SaaS. Dus je moet een stip op de horizon zetten en niet stil blijven zitten want dan is het inderdaad meestal duurder. Vergeet niet dat compliancy / industriestandaarden al in grote mate geborgd zijn in de cloud en moet je dat on-prem zelf nastreven wat ook erg veel geld kost. In alle trainingen die ik heb gevolgd (GCP / AWS en Azure iedere hyperscaler gaat hier diep op in. Als je op zoek bent naar bronnen zoek dan naar best cloud strategies / compliancy and industry standards in the cloud etc..)
Op de Paas en Saas producten zit nog meer marge.
Hoe meer je van een product gebruikt hoe ongunstiger het wordt om het uit te besteden.
bv het managed search product is ballpark 2x zo duur als zelf een instance met elasticsearch draaien.
Dat is prima als je rekening voor search 500 euro per maand is, voor 250 euro kan je geen engineer inhuren die je elastic cluster gaat opzetten, managen etc.
Als je echter 500k per maand aan search uit geeft wordt het een heel ander verhaal. Dan betaal je op jaar basis 3 miljoen extra voor het managed aspect, voor dat geld kan je een eigen search team opzetten EN flink geld overhouden.

Dus zoals altijd: het hangt er maar net vanaf en je kan financieel ook goed leeglopen op saas/paas producten als je er heel veel gebruik van maakt.
Als je 500k per maand uitgeeft aan elasticsearch heb je een hele deftige onprem infra nodig omdat ook te kunnen draaien, je hebt dure mensen nodig in dat team met risico’s op fouten, uitval, kennisverloop en als je besluit juist dit onprem te doen remt het andere transities. Het is een algemeen cloud principe dat PaaS wordt geprevaleerd boven IaaS en SaaS boven PaaS. Uitzondering daargelaten.
Ik heb het niet eens over het prijs verschil met on-prem.
Dit is een vergelijk tussen kosten van iaas op amazon vs het “search as a service” product van Amazon.

Al deze as a service producten wordt zwaar gepushed door de vendors omdat ze daar de grootste marge op hebben. Als je echter echt grote volumes doet is het vaak een extreem prijzige oplossing.
Ik kan er niet precies achter komen waar jij nu precies op doelt. Zover ik kan nagaan is AWS elasticsearch al fully managed en kan ik BallPark helemaal niet vinden als een AWS fully managed - fully managed ElasticSearch platform. Als je gaat inzoomen op de AWS usecase ElasticSearch is dat helemaal een beerput eigenlijk.
Ik bedoel managed elastic vs iaas instances en zelf elasticsearch daarop installeren (mensen noemen dit soms ook wel self managed elastic search)
Elastic Search is een mooi pakket, maar als je het echt op schaal gaat draaien dan is dat een hele uitdaging. Overigens geldt dat ook voor Elastic als je het in de cloud draait, maar dan heb je vaak wel wat meer flexibiliteit. Ik vind het vooral altijd bijzonder dat Elastic ook veel wordt ingezet voor log-analysis. Daar zijn zoveel betere tools voor, maar toch grijpen veel mensen toch altijd weer naar Elastic.
Klopt wel als je IaaS bv op IaaS houdt
Ik geef je deels gelijk. We vergelijken hier een lease auto (de cloud) met een tweedehandsauto (met alle respect voor deze laatste ;) ). Een IAAS bij een traditionele DC heeft niet dezelfde certificeringen die een grote cloud partij kan leveren puur door de schaalgrootte die ze hebben. Bij IAAS die continu aanstaat en kosten maakt zal een eigen DC goedkoper zijn. Maar in veel gevallen kan IAAS uitgezet worden of terug geschaald worden en daar is de cloud extreem goed in. Dat vergt wel dat je in control bent over het gebruik van je infrastructuur, maar het levert dan ook wat op, zeker als je het over tientallen of honderden IAAS workloads hebt.

Dus ook voor IAAS in de cloud "kan" dat goedkoper zijn dan in je eigen DC.
Ook zijn meer en meer bedrijven wakker aan het worden en beseffen ze dat gewoon alles "in de cloud duwen" vooral heel duur is, duurder dan het in je eigen DC houden.
Lijkt me een nogal ongenuanceerde mening. De cijfers van deze cloud diensten laten een totaal ander beeld zien. Mijn eigen ervaring ook. Vanaf het moment dat je een DevOps team hebt die ook direct voor de kosten van de infra verantwoordelijk zijn heb je al een besparing te pakken. Ik weet precies tot de laatste cent nauwkeurig wat mijn workload kost. Dat heb ik nog nooit eerder gehad en voor mij is het zo laag mogelijk houden van de kosten een pijler in het maken van beslissingen, zonder in te moeten boeten op performance, robuustheid en veiligheid.
Ik vraag me altijd af.

Azure is natuurlijk je on-premise wat je altijd beheert hebt maar dan in de cloud.

Hoe is dit anders AWS? Die hebben gewoon centrale database zoals een AD-DS of wat dan ook. Waar Azure alles soepel integreert.


Misschien moet ik me bestaande baan opzeggen. En iets zoeken die alles ik Azure hebben staan. Lijkt me een goede leerproces. Wij hebben hier alles on-prem of bij een 3de partij gehost.

[Reactie gewijzigd door theduke1989 op 26 juli 2024 17:30]

Ik heb het drie keer gelezen en snap niet wat je nu wil zeggen. Je begint over Azure maar hebt niet echt een idee wat het is blijkbaar en ook AWS is je onbekend.
Je haalt me de woorden uit de mond...
Azure is natuurlijk je on-premise wat je altijd beheert hebt maar dan in de cloud.
Heee, nee, dat is lift & shift. Ik heb hele workloads draaien in azure waar geen enkele VM in voorkomt. Allemaal services, en waar het op draait is allemaal in beheer bij de cloud. Enorm verschil.
ook hier heb je gewoon VMs onder je services natuurlijk, jij beheert ze niet.
belangrijk is natuurlijk om te weten of je niet op een shared omgeving draait waardoor je potentieel een (klein) risico loopt dat jouw services niet genoeg capaciteit krijgen omdat die van een andere klant hogere prio hebben
Azure is natuurlijk je on-premise wat je altijd beheert hebt maar dan in de cloud.
Nee, dat is het helemaal niet. Mensen bekijken nieuwe ontwikkelingen altijd vanuit hetgeen ze kennen, maar Azure van Microsoft is echt totaal andere koek dan de software die ze hiervoor maakten, supporten en verkochten. Dit statement slaat echt kant nog wal.
Hoe is dit anders AWS? Die hebben gewoon centrale database zoals een AD-DS of wat dan ook. Waar Azure alles soepel integreert.
Hoe IAM werkt op beide platformen is behoorlijk verschillend. Het heeft echter echt totaal niks met AD-DS te maken.
Misschien moet ik me bestaande baan opzeggen. En iets zoeken die alles ik Azure hebben staan. Lijkt me een goede leerproces. Wij hebben hier alles on-prem of bij een 3de partij gehost.
Microsoft heeft hele goede self-learning modules. Gewoon online, met sandbox omgevingen en al. Ik vroeg me altijd af voor wie die echte 'Public Cloud 101' cursus was, maar ik zou hem jou van harte aanbevelen :) (niet gemeen bedoeld, maar het klinkt alsof er voor jou nog een hele wereld open kan gaan)
Uiteindelijk is het wat je vroeger on-prem had, nu in de cloud.
  • Je beheer van gebruikers (AD-DS), CA bijvoorbeeld, DNS, DHCP, NPS,
  • Je exchange servers (DAG)
  • Je fileservers
  • Je linux machines voor de devs etc,
  • je servers voor alle verkeer misschien etc.
  • Je storage racks met genoeg schijven etc.
Dit alles berekent op groffe verbruik natuurlijk.

Dat heb je nu dus allemaal bij 1 partij gezet. En ohjee laten ze opeens de prijzen omhoog gooien.
Zit je dan lekker, moet je grof geld gaan betalen om het bij een ander neer te zetten of zelfs weer terug naar on-premise. Ohjee die pakken je dan zo hard van A.....

Waarbij je bij eigen beheer, niet hoeft op te letten op bijvoorbeeld storage, want je hebt genoeg ingekocht, en kan dus zo makkelijk spelen. Nu moet je elke keer kijken welke server je neemt, of machine met welke opslag etc.

[Reactie gewijzigd door theduke1989 op 26 juli 2024 17:30]

Even een fictief voorbeeld. Stel je bent Randstad uitzendbureau en je moet op de 25-ste van de maand er duizenden loonstrookjes doorheen jagen. Om dat allemaal op 1 dag te doen heb je 20 servers nodig. Die staan de rest van de maand duimen te draaien, maar de afschrijving gaat wel door.

In de cloud kan je die dag even 20 servers opspinnen (of desnoods een halve dag 40) en je loonstrookjes erdoor te draaien. Daarna zet je ze weer uit en betaal je ze ook niet. Wellicht zijn ze per uur 2x zo duur, maar je bent in de praktijk wel 15x goedkoper uit.

Overigens is Amazon zo met AWS gestart. Die hadden een enorm serverpark nodig om rond black friday de load aan te kunnen. De rest van de tijd stonden die servers niks te doen, dus hebben ze besloten ze maar te "verhuren". Dat was dus EC2 en daarmee was AWS geboren. Later een "paar" services bijgekomen ;-)

Dit is even een heel triviaal voorbeeld, maar zo zijn er vele use-cases waarbij de cloud zelfs bij lift-and-shift voordeliger kan zijn. Als je de architectuur ook nog eens opzet door gebruikt te maken van cloud services (populair gezegd "cloud native architectuur"), dan kan je een hele mooie schaalbare oplossing maken tegen geringe kosten.
Vooral blijven leren :)

Maar Azure en AWS (en GCP etc) zijn hetzelfde, alle zijn hyperscalers met een wereldwijde dekking en een mooi portaal en api.

Het grote verschil met de lokale hoster is dat jij volledig controle hebt over welk type server of andere dienst je af wil nemen en hoe deze geconfigureerd is. Je maakt gebruik van hun portaal of api om het zelf te doen, zij zorgen dat alles naar specificaties op gebracht word en blijft draaien. dit binnen de tijd dat het jou kost om een kop koffie te pakken.

Bij een lokale hoster kom je met een formulier aanzetten en wordt er na enkele weken een nieuwe server in een rack gezet welke daarna nog afgeconfigureerd moet worden, vaak met veel fouten en als je geluk hebt volgens specificaties. Ik heb het te vaak meegemaakt dat er een server met spec ABC besteld werd maar dat leverancier doodleuk de specs aanpast naar XYZ omdat dit zogenaamd beter was voor ons, waarna onze configuratie niet toereikend was.

Op dit item kan niet meer gereageerd worden.