New – M6g EC2 Instances, Powered by AWS Graviton2
aws.amazon.com
aws.amazon.com
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.
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?
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.
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".
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?
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
https://en.wikichip.org/wiki/arm/armv8#ARMv8_Extensions_and_...
They're still in the works! Stay tuned, and thank you for your patience.
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.
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.
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.
[1] https://www.anandtech.com/show/15578/cloud-clash-amazon-grav...