Next up: lots of proprietary extensions to drive vendor lock-in to AWS at the binary code level, then much lower pricing for instances that use these features to herd customers into them.
It's built right into the name of the product: graviton.
Prediction: today everyone will dismiss this as paranoid nonsense, impossible, or irrelevant. In 2-3 years everyone will be whining about how hard it is to migrate off AWS due to binary lock-in and the need to re-deploy packages. In 5-7 years people locked into AWS will be whining about how they pay 2-4X as much for cloud services but are unable to move due to deeply entrenched deployments and applications specifically written to take advantage of AWS CPU extensions.
This is the same sequence that has occurred for most other "paranoid" predictions about lock-in or privacy violation over the previous 10+ years. They're always initially dismissed as absurd or paranoid and then what ends up happening is usually considerably worse than what was predicted. Example: mobile and web surveillance today makes the predictions of meth-addled 1990s conspiracy freaks sound overly conservative.
Disclosure: I work for Amazon as a VP and Distinguished Engineer building our cloud infrastructure.
My professional opinion is that is a very poor strategy. Customers want to have freedom, not lock-in. When designing infrastructure services, it's good to carefully consider what abstractions are going to preserve freedom and flexibility. For example, adopting the Arm architecture, and further using the Arm developed Neoverse N1 core, provides the broadest capabilities and compatibility thanks to the investment in a common ecosystem.
The optimizations we are able to put in our silicon design, and the design of the Nitro system, let us deliver better price/performance without resorting to such customer unfriendly tactics of "lock-in".
I hope I'm just being cynical, but I base my attitude on the general trend in the industry at least in any realm related to either cloud or mobile. Everything is about herding people into some kind of closed silo and then locking the door, or on the consumer front about invading peoples' privacy in new and creative ways.
I do agree in principle that it's harder to pull off this kind of lock-in with knowledgeable customers of the sort that deploy things on AWS.
I hope you are too. As technologists and professionals I think we need to be ever-vigilant to build in responsible ways that support the public good. That includes being mindful of safety, security, and privacy concerns. And also creating or extending inequities.
All the big products- SQS, DynamoDB, Aurora, S3, Beanstalk. Those are all AWS services you can't use outside AWS (sure, there are API compatible alternatives out there). If you design for those services, you're locked into using AWS.
There is a reason bandwidth in is free while out costs money- it needs to be easy for people to move onto AWS without being east to move out. Customers are clearly choosing vendor lock-in over freedom. And AWS encourages this. If you want to migrate to AWS, Amazon will send an army of developers to help you adopt their technology. Will they do the same if a big customer wants to migrate away down the road?
As you point out, others implement compatible open source software versions of S3 and DynamoDB. Aurora already adopts (via adapting the open source software) the protocols and semantics of MySQL and PostgreSQL. Elastic Beanstalk helps you orchestrate the deployment of your application via a selection of supported "platforms" that are nearly all open source (except for .NET on Windows Server + IIS). In all of these, you could argue that SQS stands alone as something that doesn't have a "drop in" replacement. Developers that have a concern about that might want to adopt an open source alternative instead. There is nothing that prevents a developer from doing so.
In my experience, developers are adopting open source more than ever, and they also show an adept ability to know (as a crowd) what they should worry about, versus what is modular / abstract enough such that it could be replaced.
You're right. There are open source replacements for most AWS services, but that's like saying Wine under Linux is the same as Windows. For the most part, it works well enough to run most application but there are some that just don't work. PostgreSQL vs CockroachDB. Both speak PostgreSQL, but once you start using any advanced functionality you're going to run into issues.
If you're building on AWS S3 heavily, you're going to encounter features that might not be there in the "open source" version, things that behave differently, or just don't work as well. So while it's a nice thought to have, it's the same logic behind internet competition in the US for some areas. You can pick Comcast cable or DSL/WISP. They're the same, right?
Nothing prevents a developer from not adopting a technology, but we both know there are usually business decisions driving it. If you're already using S3 or DynamoDB heavily, you're already trapped. It's a cult. You're free to leave any time, but why not stay here with all your friends? If you leave you would have to spend millions in bandwidth moving your terabytes of data, hundreds of developer hours to update code, and knowledge building around new products.
You can always replace something with something else. But sometimes it's just not practical.
You're absolutely right with an API/ABI with the size and complexity of Win32 there is a risk to have compatibility challenges. Just like WSL v1 and gVisor, as re-implementations of Linux syscalls and subsystems.
To me, well designed web services are more intrinsically decoupled compared to general purpose operating system runtimes or SQL implementations.
As for when and why a group of people decide to exit various relationships, I've personally observed that sometimes cost and practicality is not evaluated completely by decision makers [1], despite various clear economic benefits of remaining.
> There are open source replacements for most AWS services, but that's like saying Wine under Linux is the same as Windows.
That kinda feels like moving the goalposts. If the alternatives aren't good enough, perhaps a company that cares about avoiding lock-in should fund them and help them get better. AWS isn't obligated to help competing products work better, or even to open-source the stack that is a big part of their competitive advantage.
If you don't want to get locked into SQS or DynamoDB or whatever, then don't use it. You can build a queue out of kafka or redis or whatever, and a DDB-workalike out of cassandra or something similar.
I'm just not really sure what it is you're objecting to. If someone adopts an AWS hosted service and then later complains that they can't move off of it, that's on them for not thinking it through at adoption time.
The only alternative here that sounds like it would make people happy is if AWS didn't build anything interesting at all, and instead only gave us EC2 on commodity hardware running Xen. If they did that, they'd fail as a business to other companies that actually build things customers want.
> "Those are all AWS services you can't use outside AWS"
What does that mean?
You can absolutely run an application hosted on Azure or GCP that uses DynamoDB or SQS as it's backing database, or queueing system?
These are just APIs on the public internet...
> If you design for those services, you're locked into using AWS.
Is that not the case with any software - including open source?
If you design for Active MQ, you're "locked in" to MQ interfaces. If you design for Kafka, you're "locked in" to Kafka interfaces.
Now, your argument about imbalanced data transfer rates MAY have aspects of lock-in - AWS does make it easier to onboard than offboard. But, that's also the case with any service provider, and I don't even mean software. Stock brokerages charge a fee for transfering portfolios out of their management, and the stock brokererage you transfer your stocks TO will usually cover those fees.
Data transfer isn't free, it makes sense that AWS would charge for it, and it would make sense that it would charge more for one direction.
Unless your expectation is that every software or SaaS company's API is open-source and interoperable with every other provider, I just don't see how you can avoid the kind of "lock-in" you describe.
I could run my load balance on GCP, send traffic to applications hosted in Azure, which use AWS services to talk to each other. Sure, that's something I _could_ do. but that's drastically more expensive then if I run everything inside of AWS.
They're not just APIs on the public internet. You also need to worry about latency and cost. Talking to/from an AWS service from outside AWS is more expensive from talking inside AWS.
> If you design for Active MQ, you're "locked in" to MQ interfaces.
Being locked into a paid product, vs a free product are two completely different things. I can take the Kafka code base and do whatever I want to it. It's an open system. I can't do the same with DynamoDB or SQS. You can't cut ties with AWS and still have your DyanmoDB dependent systems function, while I could cut all ties with Apache and still have a functional kafka cluster.
> But, that's also the case with any service provider
Yes. That doesn't make it a good thing. Having to pay to move stocks from one broker to another isn't a good thing.
> Unless your expectation is that every software or SaaS company's API is open-source and interoperable with every other provider, I just don't see how you can avoid the kind of "lock-in" you describe.
I'm not presenting a way to avoid it. I'm stating that AWS offers a bunch of vendor lock-in type products. They're like Oracle. Oracle DB is an amazing piece of software, but they know this and charge an arm, a leg, and your soul for it. The only difference between AWS and Oracle is that AWS havn't asked for your soul yet.
If your threat model includes having to address a concern of historically unpredictable or unreliable vendor behavior or performance (which makes sense, in a robust professional engineering practice), it can make sense to take matters in your own hands. Open Source is a great way to do that.
While past performance does not guarantee future results, there is some empirical evidence that you can use when evaluating which vendors you trust, and can rely on to be customer obsessed, including always looking for sustainable ways to save you money. You are, of course, entitled to an opinion about what "sustainable" means to you, and how you measure your choice of vendor. To me, it means specific things in how I professionally practice as an engineer.
[edit: small clarification, saving customers money is only one way to deliver value for their money. But, in my experience ]
Software that works with S3 tends to work with competing APIs as well; just change a config option. Even if you’re interfacing with the API directly (you probably shouldn’t do that—use some sort of abstraction layer instead), there are open source alternatives that support the exact same API.
SQS can be useful for getting data out of AWS without worrying about whether your callbacks are down. For example, if you’re using SES, you might want to know when emails bounce; you can have all those events sent to SQS, then pull them out whenever and store them in something more generic. I don’t think it’s particularly common to use SQS beyond that.
DynamoDB—is that even still a thing? Isn’t Cassandra basically DynamoDB 2, but open source?
Aurora is expensive and makes exporting data a pain. I have no intention of using it until it’s easy to set up external replication so I can fail over to other providers (or leave). No external replication, no business, especially at that price point. Aurora was quite a disappointment.
Beanstalk is another one of those things that nobody actually uses. That being said, it doesn’t really lock you into anything; it’s just a way to automate some basic AWS tasks, really. But it’s generally more trouble than it’s worth.
> Isn’t Cassandra basically DynamoDB 2, but open source?
Yet you need to deploy it somewhere and maintain it. DynamoDB just works and that’s why people will happily pay extra because they can put effort on something more meaningful that maintaining a database.
"Aurora is expensive and makes exporting data a pain. I have no intention of using it until it’s easy to set up external replication so I can fail over to other providers (or leave). No external replication, no business, especially at that price point. Aurora was quite a disappointment."
Aurora MySQL supports raw access to the binlogs. Aurora Postres supports Activity Streams and Logical Replication. Both are well support by DMS, which can even support replicating and converting between different types of databases - it's designed to support moving into AWS, but nothing's stopping you to use it to replicate in the other direction.
RDS is worth every penny, in my opinion. Of all the technology I've used in my career, it's one of the most impressive.
I have a different view. The key here is that this is a ARM based server processor, this is very different than any other proprietary CPU offers like those running mainframes.
By adding new ARMs to their fleet this will foster competition chip wise.
Overall at least for our stack (Java, NodeJS, Python, MongoDB, PostgreSQl) I think we can migrate from Intel to Arm with 1click. And thats what we're going to do.., I'm definitely trying this new chip.
Even if you were just being absurd and paranoid (not saying you are), I do wish more people were quick to think about the implications of jumping into proprietary hardware/software. One of the greatest things about being a developer these days is that you have amazing options that are fully open source.
I think that open source enables broader choice and freedom for everyone who's building. I remember the "bad days" of proprietary UNIX well, where every vendor also had their ISA. Today, the vast majority of applications that are built on open source are very portable between ISAs.
Not sure whether this processor will create a vendor lock-in or not, but today there are many companies already locked-in into aws. My current company is heavy user of SQS, Lambda, Dynamodb, cloud formation etc and practically it is very hard to move out of AWS. Theoretically it is possible to move out to other cloud vendors but practically it is not worth doing because of amount of testing (and coding) required. We keep on creating more and more coupling with AWS stacks. And in the future it will be almost impossible to move out to other cloud vendors.
I don't really see this as a likely risk, call me back once they have their own unique compiler targets that can't be targeted with LLVM. But even if they did evolve their own unique CPU architecture, that seems like a remarkably low-risk problem compared to the inertia you inevitably acquire using any platform API whatsoever. If you rely on anything beyond bare VM provisioning from any cloud provider you will experience huge pain to move anywhere else. If you are concerned about it, deploy on m6g instances, and put the money you save in a piggybank to pay a consultant to move you when AWS crosses your line.
We have infrastructure at a number of cloud and bare metal providers, and I have my own personal applications running on several others for evaluation.
In the decade or so since I started moving applications to the cloud, I’ve found AWS one of the easiest to migrate away from—and that’s what keeps us there. We’re constantly streaming our data to other providers who won’t let us export easily (or make it even more expensive than AWS). If we need to fail over, we can—while we do use AWS APIs, it’s not that hard to switch our code over to use a different API; we’ve done it plenty of times before.
If what you’re describing were to actually happen, or if we suspected that it was about to happen, we’d be moving away from AWS with the flick of a switch. While I doubt most of their customers would be able to do that with so little difficulty, I’m sure a lot of people would think twice about throwing more money at an expensive cloud. We’re paying for the versatility without the need to manage bare metal ourselves; it’s worth the money only so long as that versatility and interoperability remains intact.
These are gamechanging. Anapurna labs is the team that Amazon acquired to design the custom silicon. They have a track record of amazing innovation, including powering EC2's 25gbps network stack, and the Nitro accelerator cards that offload critical security functionality from the CPU. Since Anapurna designed these from scratch, they've built higher levels of security into the architecture, including fully encrypted DRAM.
Is there a public cloud VM using it that we could compare for price? My understanding of typical benchmarks is that there are a lot of snitty details that need to be matched up in order to do a cost-performance comparison.
I'm curious about your thoughts on the threat model when a cloud provider is building and operating the silicon too, and they aren't exclusively procuring silicon from suppliers that are the likes of Intel and AMD.
Is it a particular certification that would help you trust it? A third party audit? How does it compare to how you establish trust in AMD or Intel on their design, implementation, policy, and practices?
I still dont understand how AMD could have a chip announced 18 months ago, shipped nearly 12 months ago, Announced by AWS 6 months ago and is still not available.
Azure went GA with Rome in Feb and Google in April, so AWS is not that late. I wonder if supply is low. One disadvantage of AWS is that they're so large they can't GA anything in low quantities because it would run out immediately.
Disclosure: I work at Amazon on building cloud infrastructure.
That is an insightful general observation, though my saying so should not be interpreted as any specific statement on this launch. :-)
The bar on quality and scale is high. I don't see this as a disadvantage, though some customers may not recognize the value of experiences that we strive to make "invisible." You might not appreciate it until you have a bad experience somewhere else.
Personally I think about it like ordering things on Amazon.com. I got really used to an experience where I almost always get something I ordered within a delivery date shown on the website. Since COVID-19, I've started ordering some things from other sites, and a couple advertised "ships tomorrow, 2 day shipping!" But really, ordering the item just turned into a third party drop ship, and the item came a week later than "advertised". No general complaints, given the global situation today, just a general observation about customer experiences, and how unconscious expectations grow over time.
Reading my comment again, I feel that I should add: not delivering on time makes us very anxious, because we don't want to deliver a bad customer experience that comes with being late. That's why when uncertainty is introduced in the system, delivery estimates sometimes get pushed out significantly, or an estimated date isn't provided at all. When we announced that C5a was in the works, without a date, it does leave you (the customer) wondering when it's going to arrive. Quite a lot has transpired since the announcement, and we are still working hard to deliver this as quickly and safely as we can.
Also, they don't GA anything without a good reason. Introducing a new socket is not trivial - all their FCLGA3647 boxes introduced in 2017 can be updated to second generation ones introduced this year - or they can just build these machines without having to redesign the motherboards.
Introducing EPYC Rome boxes would require, besides a volume price agreement (that AMD could be reluctant to enter, as they can sell the whole capacity with better margins, at least for now) new supply chains for motherboards and PCIe 4 peripherals that can't be used with their Intel stuff yet. That's a lot of disruption.
Yes I fully understand that. I am not blaming Amazon at all. I am blaming AMD for not capturing more and doing better. Never in the history of Intel have they been in the technically disadvantage they are in, and yet AMD hasn't prove they are able to make anything meaningful out of it.
I hope AMD has learned something working with Hyperscalers and their Zen 3 will be a much better roll out.
Just to put some number in perspective, even if AMD earned "zero" revenue from console makers, their EPYC line dont even get 5% market share in the past quarter. And that is with Intel selling at full capacity.
Keep in mind the AMD instances are using chips AMD put out almost 3 years ago. They still aren't using the new generation of Rome chips that came out a year ago, which almost doubled performance.
C5a instances are coming, and I think that you'll still be pleased with the price/performance of M6g instances for a wide variety of applications. But if your app works better on AMD, or on Intel, we want to give you a broad selection so you can achieve the best result given your specific needs. Cloud makes it easy to switch.
We’ve been quite pleased with AWS’ t3a offering and have saved quite a bit of money by switching. We did encounter some odd kernel panics early on, but they seem to have stopped.
We’re excited to start evaluating AWS’ ARM offerings, but until now, they would’ve been more expensive for our workload. We’ll have to see if that’s changed with Graviton2, but I suspect AMD is the sweet spot for our application; it just doesn’t seem to like ARM as much.
In terms of raw CPU performance, these look pretty good. For stuff like SPEC CPU, they're within spitting distance of the EPYC 7571 for single-core performance[1]. Multi-core is not as good though. Hopefully we can see them matched against the Rome EPYC instances soon.
They are, indeed, impressive. Keep in mind, though, that a Graviton "vCPU" is an actual core. They are making direct comparisons to an Intel "vCPU", which is basically 1/2 a core (hyperthreading). I suppose what actually matters is performance per dollar, but it still feels a bit misleading.
Can you please elaborate? I'm trying to find documentation. Having a real `core` as opposed to a vCPU can be really a game changer provided that the Linux Kernel can benefit from this arrangement.
Disclosure: I work at Amazon building cloud infrastructure
Indeed price/performance is how customers I've talked to evaluate what they're able to get out of a platform. The "t-shirt" sizes are what matters in that comparison, and yes the microarchitecture of Graviton2 can be an advantage for many workloads. The best thing to do is to give all your options a try, and use a cost estimator to help decide.
Not too sure it is misleading. ( Or you could argue the term vCPU has been misleading from day 1 ) It is simply G2 dont offer SMT, so their 1 thread would just happen to be 1 CPU Core.
I believe We are not too far away from getting SMT4 on mainstream Server. So I think what we should learn is vCPU = CPU Thread.
It is more problematic when other vendors like Linode stop using the term vCPU and simply refers to CPU. When it is actually still 1 thread and not 1 Core. And I have seen other vendor doing the same. Comparatively speaking, Amazon has been very consistent in vCPU naming.
61 comments
[ 3.4 ms ] story [ 131 ms ] threadIt's built right into the name of the product: graviton.
Prediction: today everyone will dismiss this as paranoid nonsense, impossible, or irrelevant. In 2-3 years everyone will be whining about how hard it is to migrate off AWS due to binary lock-in and the need to re-deploy packages. In 5-7 years people locked into AWS will be whining about how they pay 2-4X as much for cloud services but are unable to move due to deeply entrenched deployments and applications specifically written to take advantage of AWS CPU extensions.
This is the same sequence that has occurred for most other "paranoid" predictions about lock-in or privacy violation over the previous 10+ years. They're always initially dismissed as absurd or paranoid and then what ends up happening is usually considerably worse than what was predicted. Example: mobile and web surveillance today makes the predictions of meth-addled 1990s conspiracy freaks sound overly conservative.
https://en.wikichip.org/wiki/arm/armv8#ARMv8_Extensions_and_...
My professional opinion is that is a very poor strategy. Customers want to have freedom, not lock-in. When designing infrastructure services, it's good to carefully consider what abstractions are going to preserve freedom and flexibility. For example, adopting the Arm architecture, and further using the Arm developed Neoverse N1 core, provides the broadest capabilities and compatibility thanks to the investment in a common ecosystem.
The optimizations we are able to put in our silicon design, and the design of the Nitro system, let us deliver better price/performance without resorting to such customer unfriendly tactics of "lock-in".
I do agree in principle that it's harder to pull off this kind of lock-in with knowledgeable customers of the sort that deploy things on AWS.
All the big products- SQS, DynamoDB, Aurora, S3, Beanstalk. Those are all AWS services you can't use outside AWS (sure, there are API compatible alternatives out there). If you design for those services, you're locked into using AWS.
There is a reason bandwidth in is free while out costs money- it needs to be easy for people to move onto AWS without being east to move out. Customers are clearly choosing vendor lock-in over freedom. And AWS encourages this. If you want to migrate to AWS, Amazon will send an army of developers to help you adopt their technology. Will they do the same if a big customer wants to migrate away down the road?
https://e.lvme.me/kmw2hs1.jpg
In my experience, developers are adopting open source more than ever, and they also show an adept ability to know (as a crowd) what they should worry about, versus what is modular / abstract enough such that it could be replaced.
If you're building on AWS S3 heavily, you're going to encounter features that might not be there in the "open source" version, things that behave differently, or just don't work as well. So while it's a nice thought to have, it's the same logic behind internet competition in the US for some areas. You can pick Comcast cable or DSL/WISP. They're the same, right?
Nothing prevents a developer from not adopting a technology, but we both know there are usually business decisions driving it. If you're already using S3 or DynamoDB heavily, you're already trapped. It's a cult. You're free to leave any time, but why not stay here with all your friends? If you leave you would have to spend millions in bandwidth moving your terabytes of data, hundreds of developer hours to update code, and knowledge building around new products.
You can always replace something with something else. But sometimes it's just not practical.
To me, well designed web services are more intrinsically decoupled compared to general purpose operating system runtimes or SQL implementations.
As for when and why a group of people decide to exit various relationships, I've personally observed that sometimes cost and practicality is not evaluated completely by decision makers [1], despite various clear economic benefits of remaining.
[1] https://en.wikipedia.org/wiki/Brexit
That kinda feels like moving the goalposts. If the alternatives aren't good enough, perhaps a company that cares about avoiding lock-in should fund them and help them get better. AWS isn't obligated to help competing products work better, or even to open-source the stack that is a big part of their competitive advantage.
If you don't want to get locked into SQS or DynamoDB or whatever, then don't use it. You can build a queue out of kafka or redis or whatever, and a DDB-workalike out of cassandra or something similar.
I'm just not really sure what it is you're objecting to. If someone adopts an AWS hosted service and then later complains that they can't move off of it, that's on them for not thinking it through at adoption time.
The only alternative here that sounds like it would make people happy is if AWS didn't build anything interesting at all, and instead only gave us EC2 on commodity hardware running Xen. If they did that, they'd fail as a business to other companies that actually build things customers want.
What does that mean?
You can absolutely run an application hosted on Azure or GCP that uses DynamoDB or SQS as it's backing database, or queueing system?
These are just APIs on the public internet...
> If you design for those services, you're locked into using AWS.
Is that not the case with any software - including open source?
If you design for Active MQ, you're "locked in" to MQ interfaces. If you design for Kafka, you're "locked in" to Kafka interfaces.
Now, your argument about imbalanced data transfer rates MAY have aspects of lock-in - AWS does make it easier to onboard than offboard. But, that's also the case with any service provider, and I don't even mean software. Stock brokerages charge a fee for transfering portfolios out of their management, and the stock brokererage you transfer your stocks TO will usually cover those fees.
Data transfer isn't free, it makes sense that AWS would charge for it, and it would make sense that it would charge more for one direction.
Unless your expectation is that every software or SaaS company's API is open-source and interoperable with every other provider, I just don't see how you can avoid the kind of "lock-in" you describe.
I could run my load balance on GCP, send traffic to applications hosted in Azure, which use AWS services to talk to each other. Sure, that's something I _could_ do. but that's drastically more expensive then if I run everything inside of AWS.
They're not just APIs on the public internet. You also need to worry about latency and cost. Talking to/from an AWS service from outside AWS is more expensive from talking inside AWS.
> If you design for Active MQ, you're "locked in" to MQ interfaces.
Being locked into a paid product, vs a free product are two completely different things. I can take the Kafka code base and do whatever I want to it. It's an open system. I can't do the same with DynamoDB or SQS. You can't cut ties with AWS and still have your DyanmoDB dependent systems function, while I could cut all ties with Apache and still have a functional kafka cluster.
> But, that's also the case with any service provider
Yes. That doesn't make it a good thing. Having to pay to move stocks from one broker to another isn't a good thing.
> Unless your expectation is that every software or SaaS company's API is open-source and interoperable with every other provider, I just don't see how you can avoid the kind of "lock-in" you describe.
I'm not presenting a way to avoid it. I'm stating that AWS offers a bunch of vendor lock-in type products. They're like Oracle. Oracle DB is an amazing piece of software, but they know this and charge an arm, a leg, and your soul for it. The only difference between AWS and Oracle is that AWS havn't asked for your soul yet.
While past performance does not guarantee future results, there is some empirical evidence that you can use when evaluating which vendors you trust, and can rely on to be customer obsessed, including always looking for sustainable ways to save you money. You are, of course, entitled to an opinion about what "sustainable" means to you, and how you measure your choice of vendor. To me, it means specific things in how I professionally practice as an engineer.
[edit: small clarification, saving customers money is only one way to deliver value for their money. But, in my experience ]
oh no! engineering tradeoffs!
Software that works with S3 tends to work with competing APIs as well; just change a config option. Even if you’re interfacing with the API directly (you probably shouldn’t do that—use some sort of abstraction layer instead), there are open source alternatives that support the exact same API.
SQS can be useful for getting data out of AWS without worrying about whether your callbacks are down. For example, if you’re using SES, you might want to know when emails bounce; you can have all those events sent to SQS, then pull them out whenever and store them in something more generic. I don’t think it’s particularly common to use SQS beyond that.
DynamoDB—is that even still a thing? Isn’t Cassandra basically DynamoDB 2, but open source?
Aurora is expensive and makes exporting data a pain. I have no intention of using it until it’s easy to set up external replication so I can fail over to other providers (or leave). No external replication, no business, especially at that price point. Aurora was quite a disappointment.
Beanstalk is another one of those things that nobody actually uses. That being said, it doesn’t really lock you into anything; it’s just a way to automate some basic AWS tasks, really. But it’s generally more trouble than it’s worth.
Yet you need to deploy it somewhere and maintain it. DynamoDB just works and that’s why people will happily pay extra because they can put effort on something more meaningful that maintaining a database.
Aurora MySQL supports raw access to the binlogs. Aurora Postres supports Activity Streams and Logical Replication. Both are well support by DMS, which can even support replicating and converting between different types of databases - it's designed to support moving into AWS, but nothing's stopping you to use it to replicate in the other direction.
RDS is worth every penny, in my opinion. Of all the technology I've used in my career, it's one of the most impressive.
Edit: Looks like it is now possible to enable external replication.
By adding new ARMs to their fleet this will foster competition chip wise.
Overall at least for our stack (Java, NodeJS, Python, MongoDB, PostgreSQl) I think we can migrate from Intel to Arm with 1click. And thats what we're going to do.., I'm definitely trying this new chip.
I think that open source enables broader choice and freedom for everyone who's building. I remember the "bad days" of proprietary UNIX well, where every vendor also had their ISA. Today, the vast majority of applications that are built on open source are very portable between ISAs.
In the decade or so since I started moving applications to the cloud, I’ve found AWS one of the easiest to migrate away from—and that’s what keeps us there. We’re constantly streaming our data to other providers who won’t let us export easily (or make it even more expensive than AWS). If we need to fail over, we can—while we do use AWS APIs, it’s not that hard to switch our code over to use a different API; we’ve done it plenty of times before.
If what you’re describing were to actually happen, or if we suspected that it was about to happen, we’d be moving away from AWS with the flick of a switch. While I doubt most of their customers would be able to do that with so little difficulty, I’m sure a lot of people would think twice about throwing more money at an expensive cloud. We’re paying for the versatility without the need to manage bare metal ourselves; it’s worth the money only so long as that versatility and interoperability remains intact.
https://azure.microsoft.com/en-us/updates/hbv2series-vms-are...
https://aws.amazon.com/blogs/aws/in-the-works-new-amd-powere... (no pricing)
Is it a particular certification that would help you trust it? A third party audit? How does it compare to how you establish trust in AMD or Intel on their design, implementation, policy, and practices?
That is an insightful general observation, though my saying so should not be interpreted as any specific statement on this launch. :-)
The bar on quality and scale is high. I don't see this as a disadvantage, though some customers may not recognize the value of experiences that we strive to make "invisible." You might not appreciate it until you have a bad experience somewhere else.
Personally I think about it like ordering things on Amazon.com. I got really used to an experience where I almost always get something I ordered within a delivery date shown on the website. Since COVID-19, I've started ordering some things from other sites, and a couple advertised "ships tomorrow, 2 day shipping!" But really, ordering the item just turned into a third party drop ship, and the item came a week later than "advertised". No general complaints, given the global situation today, just a general observation about customer experiences, and how unconscious expectations grow over time.
Introducing EPYC Rome boxes would require, besides a volume price agreement (that AMD could be reluctant to enter, as they can sell the whole capacity with better margins, at least for now) new supply chains for motherboards and PCIe 4 peripherals that can't be used with their Intel stuff yet. That's a lot of disruption.
[1] https://aws.amazon.com/blogs/aws/in-the-works-new-amd-powere...
I hope AMD has learned something working with Hyperscalers and their Zen 3 will be a much better roll out.
Just to put some number in perspective, even if AMD earned "zero" revenue from console makers, their EPYC line dont even get 5% market share in the past quarter. And that is with Intel selling at full capacity.
We’re excited to start evaluating AWS’ ARM offerings, but until now, they would’ve been more expensive for our workload. We’ll have to see if that’s changed with Graviton2, but I suspect AMD is the sweet spot for our application; it just doesn’t seem to like ARM as much.
They're still in the works! Stay tuned, and thank you for your patience.
[1] https://www.anandtech.com/show/15578/cloud-clash-amazon-grav...
Indeed price/performance is how customers I've talked to evaluate what they're able to get out of a platform. The "t-shirt" sizes are what matters in that comparison, and yes the microarchitecture of Graviton2 can be an advantage for many workloads. The best thing to do is to give all your options a try, and use a cost estimator to help decide.
I believe We are not too far away from getting SMT4 on mainstream Server. So I think what we should learn is vCPU = CPU Thread.
It is more problematic when other vendors like Linode stop using the term vCPU and simply refers to CPU. When it is actually still 1 thread and not 1 Core. And I have seen other vendor doing the same. Comparatively speaking, Amazon has been very consistent in vCPU naming.
Or, in short..."4 Graviton cores are 40% faster than 2 Intel cores, and we are pricing them the same" is what's really happening.