AWS just went multi-cloud(acloudguru.com)
acloudguru.com
AWS just went multi-cloud
https://acloudguru.com/blog/business/aws-just-went-multi-cloud-and-its-only-the-beginning
144 comments
I've worked as a consultant in this area for years with large F500 companies and not once have I heard anyone actually be concerned with the "lock in" boogeyman. There used to be a lot of concern around general trust of the cloud, which drove people to stick to on-prem servers. But "lock in", IME, is only something people fret about on HN.
What I think is happening is that companies are starting to gain more experience in the cloud and are less intimidated by it. In the past, using just one cloud was scary enough, let alone trying to use 2+ at the same time. But now, with more experience under their belt, companies are realizing that each cloud has its own advantages and disadvantages. AWS is rock solid when it comes to EC2, S3, RDS, Lambda, and some others. But if you have some teams in your company that want to use a PaaS, GCP App Engine is preferable to AWS Elastic Beanstalk. Similarly, your data science or AI/ML teams might prefer to use GCP services over AWS. Or maybe your risk management team is going the full stretch for disaster recovery and says not only do you have to be multi-region within one cloud, but you are required to be multi-cloud as well.
With companies moving this way, I think this is AWS realizing that multi-cloud is inevitable, so they might as well support it, if not embrace it.
What I think is happening is that companies are starting to gain more experience in the cloud and are less intimidated by it. In the past, using just one cloud was scary enough, let alone trying to use 2+ at the same time. But now, with more experience under their belt, companies are realizing that each cloud has its own advantages and disadvantages. AWS is rock solid when it comes to EC2, S3, RDS, Lambda, and some others. But if you have some teams in your company that want to use a PaaS, GCP App Engine is preferable to AWS Elastic Beanstalk. Similarly, your data science or AI/ML teams might prefer to use GCP services over AWS. Or maybe your risk management team is going the full stretch for disaster recovery and says not only do you have to be multi-region within one cloud, but you are required to be multi-cloud as well.
With companies moving this way, I think this is AWS realizing that multi-cloud is inevitable, so they might as well support it, if not embrace it.
It depends on the industry. A lot of retail companies are moving away from Amazon to avoid having competitive data flow through AWS infrastructure. Some companies may have different business units across different cloud providers but push for strategic consolidation on a major cloud provider for new implementations.
The heavier the use of cloud native solutions and managed services, the greater the effort to migrate away from those solutions. Not all workloads run on containers, and even then those applications will need some code refactoring if they depend on cloud infrastructure services (cloud specific storage, queue services, monitoring, etc)
The heavier the use of cloud native solutions and managed services, the greater the effort to migrate away from those solutions. Not all workloads run on containers, and even then those applications will need some code refactoring if they depend on cloud infrastructure services (cloud specific storage, queue services, monitoring, etc)
Retail companies like Walmart are driving more movement than you'd expect since they aren't only moving their own compute from AWS, they're requiring their own tech partners and vendors to provide them non-AWS-based alternatives as well. I've been on several migration/training projects for companies with large retail customers since they hadn't had time to build the sort of GCP or Azure expertise yet that they had around AWS.
That (first paragraph) sounds like a different issue than lock-in.
Anyone who is not concerned about lock in is a fool. There are many fools in business.
Any of the companies I've worked with (and I've worked with many) are large enough and have been around long enough to understand that re-architecting apps, doing lift-and-shifts, re-training employees, or anything like that is an inevitable cost of doing business that is going to happen every couple of years no matter what, so any time fretting about "lock in" would ultimately be a waste of time.
And perhaps more importantly to these companies, lock-in is more than worth it if it means benefiting from some real revenue or cost optimizations. Paying $3 to "unlock" from a platform is more than worth it if said platform gave me $5 of benefit.
And perhaps more importantly to these companies, lock-in is more than worth it if it means benefiting from some real revenue or cost optimizations. Paying $3 to "unlock" from a platform is more than worth it if said platform gave me $5 of benefit.
> companies I've worked with (and I've worked with many) are large enough and have been around long enough to understand that re-architecting apps...is going to happen every couple of years no matter what
Like the commentator you responded to said. There are many fools in business.
Like the commentator you responded to said. There are many fools in business.
On the contrary, I'd say if you're not re-architecting your apps every couple of years then you're at risk of falling behind.
I'm not talking about rebuilding everything from scratch, but making an active effort to do self introspection and ask yourself "we built this app 3 years ago with certain requirements in mind and chose stack X to host it, but a lot has changed in the past 3 years, both in our requirements and in the technology landscape. Should we still be using stack X or does something else fit our needs better?" is unequivocally a good practice.
I'm not talking about rebuilding everything from scratch, but making an active effort to do self introspection and ask yourself "we built this app 3 years ago with certain requirements in mind and chose stack X to host it, but a lot has changed in the past 3 years, both in our requirements and in the technology landscape. Should we still be using stack X or does something else fit our needs better?" is unequivocally a good practice.
I would note that F500 companies are going to have the resources to move out of lock in if it came down to it, and AWS sales management knows it and would have to negotiate costs with that in mind. Smaller scale companies than the F500 that don't have that kind of leverage have to concern themselves more w/ lock-in.
Didn’t AWS just move some of their infrastructure off of oracle because it basically took them a decade to figure out how?
Yup, the interesting data point would be what did Amazon pay for their oracle usage vs smaller companies? I would guess that as long as Oracle gave them a reasonable price Amazon would be happy to stay on - except for a question of long term independence and vertical integration.
Amazon is probably in a unique position in that providing data and database services is a core competency, and so vertical integration off of Oracle makes a lot of sense even separate from the cost leverage question.
Amazon is probably in a unique position in that providing data and database services is a core competency, and so vertical integration off of Oracle makes a lot of sense even separate from the cost leverage question.
Yes and AWS also built multiple database types to meet their needs. Is your company going to do the same?
What? No, but that's my point. Even a company like Amazon was locked-in to a vendor. I'm not saying people should build their own databases but that this is a move in the right direction.
"Oops, your outgoing bandwidth is now 1000x more expensive"
I wouldn't worry about it. This doesn't happen. More likely to fail trying to be independent of all vendors than to be locked into a vendor.
It's only half a million dollars to egress 10 PB from S3. You'll be fine.
It's only half a million dollars to egress 10 PB from S3. You'll be fine.
I wouldn't worry about global pandemics. They don't happen.
It's also worth keeping in mind that Amazon themselves are a poster child of this kind of thing, with their Oracle migration. If it took them a decade, what hope do you have?
It's also worth keeping in mind that Amazon themselves are a poster child of this kind of thing, with their Oracle migration. If it took them a decade, what hope do you have?
Oh yeah, definitely. Definitely do not plan for that eventuality. Right now, we're in one so you have to be aware but when not in one, don't plan for it or mitigate that risk in any appreciable form.
It is easily 10x harder to migrate from on-prem to a cloud, than it is to migrate between clouds. The big cloud providers are all functionally REALLY similar, if you're mostly using the big components:
- Object storage is basically identical, often even down to common API wrappers
- VMs are VMs
- Kubernetes is Kubernetes. Containers are containers.
- EMR is Dataproc is whatever Azure has
- BigQuery is Redshift is whatever Azure provides. It's big SQL. Whatever.
Like, I'm not saying there isn't a cost, or it's pain-free... but you're not re-engineering everything when you migrate. You're finding fiddly difference between platforms, and if you're an enterprise, your new cloud provider would LOVE to help you with that migration.
- Object storage is basically identical, often even down to common API wrappers
- VMs are VMs
- Kubernetes is Kubernetes. Containers are containers.
- EMR is Dataproc is whatever Azure has
- BigQuery is Redshift is whatever Azure provides. It's big SQL. Whatever.
Like, I'm not saying there isn't a cost, or it's pain-free... but you're not re-engineering everything when you migrate. You're finding fiddly difference between platforms, and if you're an enterprise, your new cloud provider would LOVE to help you with that migration.
Just tell that to your PMO and have them give you an estimate about how long it will take to migrate. Then talk to your developers and infrastructure folks and let them do a (bad) estimation about how long it will take to remove all of the hidden dependencies.
That’s not even including the training involved. At the same time, your competitors are actually trying to create products that meet their customers needs while your resources are tied up in migrations.
That’s not even including the training involved. At the same time, your competitors are actually trying to create products that meet their customers needs while your resources are tied up in migrations.
> Just tell that to your PMO and have them give you an estimate about how long it will take to migrate.
Ask the same in your own infrastructure. They'll give even worse estimate.
The thing with the cloud, is that it's public, they all follow the same stuff and their goal is for you to migrate to them. They got an hundred similar situation as yours.
> At the same time, your competitors are actually trying to create products that meet their customers needs while your resources are tied up in migrations.
How is that different from your own infrastructure? If you have to migrate, you have to migrate... whatever is the source and whatever is the destination, migration is migration.
Ask the same in your own infrastructure. They'll give even worse estimate.
The thing with the cloud, is that it's public, they all follow the same stuff and their goal is for you to migrate to them. They got an hundred similar situation as yours.
> At the same time, your competitors are actually trying to create products that meet their customers needs while your resources are tied up in migrations.
How is that different from your own infrastructure? If you have to migrate, you have to migrate... whatever is the source and whatever is the destination, migration is migration.
That’s true and this isn’t an AWS vs Azure vs GCP argument.
Once you decide to move from on prem to either of the cloud providers you get the benefits of being able to take advantage of scale efficiencies, letting another company do the “undifferentiated heavy”, elasticity (not having to provision for peak capacity), a global infrastructure, quick provisioning of resources etc.
Yes depending on your use case, you can gain benefits from moving off prem/colo to any cloud provider. The benefit once you move to any of the providers to switch providers is negligible.
Once you decide to move from on prem to either of the cloud providers you get the benefits of being able to take advantage of scale efficiencies, letting another company do the “undifferentiated heavy”, elasticity (not having to provision for peak capacity), a global infrastructure, quick provisioning of resources etc.
Yes depending on your use case, you can gain benefits from moving off prem/colo to any cloud provider. The benefit once you move to any of the providers to switch providers is negligible.
Everything in life is about risk vs reward.
Platform lock in is a risk. The reward is faster time to market, thus making more money earlier, thus having more means to ameliorate your risks.
Platform lock in is a risk. The reward is faster time to market, thus making more money earlier, thus having more means to ameliorate your risks.
Imagined faster time to market. In reality, you just end up spending more time trying to debug black boxes.
I think you must have a limited mindset of how long it can take wheels to turn in large companies. Without cloud, it's not uncommon for the F500s I've worked at to take literal months (90+ days) just to provision and stand up a new server for an application team to even begin developing on. Even if you spend time "debugging black boxes" (which is highly debatable), most of the time you're still moving a lot faster with cloud than before.
Some companies are better than others. One place I worked had a decent OpenStack implementation in their own data centers, and it greased the wheels a little bit (though it was not without its own issues). And of course smaller companies are likely more agile and able to move faster. But for the most part, these big companies see some very real benefits in speed by embracing public clouds.
Some companies are better than others. One place I worked had a decent OpenStack implementation in their own data centers, and it greased the wheels a little bit (though it was not without its own issues). And of course smaller companies are likely more agile and able to move faster. But for the most part, these big companies see some very real benefits in speed by embracing public clouds.
Why don't they give the application team a few extra servers to do whatever on without asking for permission?
Because without good organizational controls, the developers will put those servers into production with no HA, backups, and insecure configuration.
I’ve seen it multiple times in my careeer.
I’ve seen it multiple times in my careeer.
That makes a lot of sense. I can see how using cloud solves for HA and backups. But how does insecure configuration come in?
While this makes sense what the parent comment said is also true.
I always wondered why big enterprise customers are not concerned about lock in. Maybe they cut multi year deals with the big cloud providers?
I always wondered why big enterprise customers are not concerned about lock in. Maybe they cut multi year deals with the big cloud providers?
Have you ever been part of a large scale migration? Even if you try your best to avoid “lock in”. It’s still a multi year, expensive proposition and at the scale of a F500, it adds little business value.
Do you know how many third party services and offerings that the typical F500 depend on? More than 80% have a huge “lock in” to Microsoft.
Do you know how many third party services and offerings that the typical F500 depend on? More than 80% have a huge “lock in” to Microsoft.
You’re always locked into your infrastructure when you are at any type of scale. The cost and the risk of regressions hardly ever make it economically viable to migrate to another cloud provider.
How does avoiding “lock in” add business value either by reducing cost or increasing revenue.
Out of all the business risks that a company has, avoiding lock-in is the least of them.
How does avoiding “lock in” add business value either by reducing cost or increasing revenue.
Out of all the business risks that a company has, avoiding lock-in is the least of them.
Any big enough business have no trouble moving out from theses lock in though.
Lock-In is dead simple to avoid with AWS. Even with Lambda, which people tend to point to and say "lock-in!". Even now we've got lambdas running Docker containers.
It's a total boogeyman and I've never heard anyone care about it except on HN, where it comes up constantly.
It's a total boogeyman and I've never heard anyone care about it except on HN, where it comes up constantly.
You seem to be agreeing with parent comment, from where I stand. Lock-in may be simple to avoid, but not many people make any effort to avoid it ("There are many fools in business"). I mean, take a look at the number of companies/services that got knocked offline last week because AWS's us-east-1 was fucky: if they are "locked-in" to one AWS region, do you think they'd bother with decoupling from AWS tech in general?
So there's a reason for this that is unfortunate but true. AWS outages make the news and customers treat them like natural disasters. We host a few services on AWS but the bulk of our stuff is on-prem. When AWS has issues none of our customers cared -- they were annoyed that they couldn't do their work but were otherwise totally understanding and none of the blowback fell on us.
When one of our upstream ISPs had an outage and prevented some of customers from being able to reach us people were mad at us even after the explanation. AWS is enough of a household name that you can say sorry "AWS is down right now" and people will sympathize.
When one of our upstream ISPs had an outage and prevented some of customers from being able to reach us people were mad at us even after the explanation. AWS is enough of a household name that you can say sorry "AWS is down right now" and people will sympathize.
first , it is real.
second, it is very much a concern.
we're buying game studios, and, if their projects are using Amazon-specific technologies( gamelift, f.e) we know it's an uphill battle to profitability ; games are low margin enough to take hosting and bandwidth costs into account
That must be why nobody buys Oralce, or SAP, or mainframes.
I've not been at a place while they got sold on Oracle, but I've been at one that was desperately working to get away from it. Over 15 years the relationship went from amicable to "Oracle reps are in town this week, give management a wide berth" announcements.
Anyone who is concerned about lock in is a fool. There are many fools in business.
It's not about lock in or getting access to the side-show features available in other clouds. For a large company there is significant business risk in having all your infrastructure in one place. A billing error or some other misunderstanding could have catastrophic consequences. I've heard of absurdly close calls here. I know that one public company dependent on AWS maintains multiple accounts to lower the risk of this happening. Multi-cloud is another way to mitigate that risk.
TripAdvisor had a very strong “no lock in” policy that impacted the technical stacks we could keep/choose when we got bought by them.
We could use an nginx installed and maintained on EC2 by ourselves but not the AWS flavor on it, or I guess we’d have needed to fight to get an exception.
That’s just an anecdote, but I am sure more companies put real money behind getting “locked in”.
We could use an nginx installed and maintained on EC2 by ourselves but not the AWS flavor on it, or I guess we’d have needed to fight to get an exception.
That’s just an anecdote, but I am sure more companies put real money behind getting “locked in”.
Did avoiding lock in do anything as far as making them more competitive in the marketplace?
How many man hours was spent babysitting infrastructure?
How many man hours was spent babysitting infrastructure?
> But "lock in", IME, is only something people fret about on HN.
Lock in is a _very real problem_, but often you hear on HN scare mongering that making any decision at all is "lock in".
Lock in is a _very real problem_, but often you hear on HN scare mongering that making any decision at all is "lock in".
[deleted]
This is my experience as well. It is definitely one of the things that HN worries a lot more about than any CTO I know from tiny startups to billion dollar businesses.
Where I work, lock-in is actually embraced. Homogeneity is valuable. It is a boogeyman in HN but the concern does have merit, for sure.
I used to be very careful / strict with the lock-in. But not anymore. You have to compare the cost of an hypothetical migration to something else to the cost of not using the capability of the platform to its full capacity. I read somewhere here that accepting vendor lockin is being a fool. I would say that paying aws prices without benefiting from any of their great stuff is also not very clever.
Fortune 500 sure. But mid and small business have 0 negotiation power, it's extremely expensive to migrate data, and they can't afford a legal battle(as threat).
IME (my experience) -- Lock-in was really about APPs in the 90s and 2000s... JDE Edwards, IBM AS 400, etc...
AWS is a substrate platform, thus is does not look like lock-in in any other respect other that price.
if you marry with Oracle, JDE, AS-400 etc you are mapped to an APP and not a platform on which you can build WTF you want... so only noobs think of AWS as a lock-in because they are only looking a price/cost as opposed to the entire ripple effect of what it means to move/migrate core ops (typically finOps) between platforms...
Look at the underlying phys infra thats required to do at scale shit...
Thats the cost benefit analysis thats really overlooked. That hourly cost per comput/service/resource is mortgaging a SHIT TON of physical infrastructure that would cost a single company MILLIONS - yet - Amzn is literally investing everything that one company should in physical and digital security and executing it well...
And for that, I respect them and support them.
Anecdotal: I once had a dev (I was DEVOPS director) check in creds to github after it was the 251st repo (where our account only paid for 250) and by default at the time, Git made any repos above your account limit public, and bots scanned ALL of these - they got our creds in this devs post, and launched - from Germany - THOUSANDS of G-class instances for bitcoin mining.....
Anyway, an all-nighter - but Amazon refunded / canceled the tens of thousands of dollars in compute time without hesitation....
Cloudability proved to also be an invaluable resource - and While I am concerned over the bezos-new-world, Amazon never fails to make me appreciate their customer service... (they sent me the wrong SSD and sent me a new one, refunded my money and sent me a second one as well....)
AWS is a substrate platform, thus is does not look like lock-in in any other respect other that price.
if you marry with Oracle, JDE, AS-400 etc you are mapped to an APP and not a platform on which you can build WTF you want... so only noobs think of AWS as a lock-in because they are only looking a price/cost as opposed to the entire ripple effect of what it means to move/migrate core ops (typically finOps) between platforms...
Look at the underlying phys infra thats required to do at scale shit...
Thats the cost benefit analysis thats really overlooked. That hourly cost per comput/service/resource is mortgaging a SHIT TON of physical infrastructure that would cost a single company MILLIONS - yet - Amzn is literally investing everything that one company should in physical and digital security and executing it well...
And for that, I respect them and support them.
Anecdotal: I once had a dev (I was DEVOPS director) check in creds to github after it was the 251st repo (where our account only paid for 250) and by default at the time, Git made any repos above your account limit public, and bots scanned ALL of these - they got our creds in this devs post, and launched - from Germany - THOUSANDS of G-class instances for bitcoin mining.....
Anyway, an all-nighter - but Amazon refunded / canceled the tens of thousands of dollars in compute time without hesitation....
Cloudability proved to also be an invaluable resource - and While I am concerned over the bezos-new-world, Amazon never fails to make me appreciate their customer service... (they sent me the wrong SSD and sent me a new one, refunded my money and sent me a second one as well....)
AWS/Azure lock in is more about data than platform.
Fortune 500 have lot of data and while its free to move data to a particular cloud provider they pay a bomb to take it out.
Fortune 500 have lot of data and while its free to move data to a particular cloud provider they pay a bomb to take it out.
Good point, but begs the question; how fix?
maybe there is a market for JUST data migration/storage/translation service?
Such that you can be a data miration/router first hop - and then pipe to AWS/GCP/MS at will - then an overlay which launches the overlay infra on demand depending on which rout you want to take...? Layer 9
maybe there is a market for JUST data migration/storage/translation service?
Such that you can be a data miration/router first hop - and then pipe to AWS/GCP/MS at will - then an overlay which launches the overlay infra on demand depending on which rout you want to take...? Layer 9
Is working at AWS hellish? Or once you get in it's just a normal job?
I get its heavily dependent on the team, just wondering from your perspective.
I get its heavily dependent on the team, just wondering from your perspective.
AWS is huge, so YMMV across teams.
Some teams have operational and funding issues, so your experience there may be hellish. You could think of it another way and realize that you have your work cut out for you. I previously worked on an AWS team like this and left because I got tired of the grind.
On the other hand, a lot of teams are great places to work. Before I left AWS, I worked on a really good team with intelligent co-workers and interesting engineering challenges. It was like night and day - the team was over-funded and had very few operational issues.
Some teams have operational and funding issues, so your experience there may be hellish. You could think of it another way and realize that you have your work cut out for you. I previously worked on an AWS team like this and left because I got tired of the grind.
On the other hand, a lot of teams are great places to work. Before I left AWS, I worked on a really good team with intelligent co-workers and interesting engineering challenges. It was like night and day - the team was over-funded and had very few operational issues.
That's great to hear.
Often online all you hear are the extremes at both ends. I hear that you're basically put on PIP as soon as you join, any truth to this?
Often online all you hear are the extremes at both ends. I hear that you're basically put on PIP as soon as you join, any truth to this?
I was never a manager so I don't know the official policies around dev lists and PIPs.
Generally, new hires are given a few months to ramp up and become contributing team members. People are usually placed on the dev list if they don't meet expectations, and placed on a PIP if their performance does not improve. I'm guessing it reflects poorly on managers if they devlist someone shortly after hiring them.
During my time at Amazon, I know only one person who was placed on a PIP and he was kind of a bad engineer. But I have heard stories of managers abusing the dev list to meet org-level dev list quotas.
Generally, new hires are given a few months to ramp up and become contributing team members. People are usually placed on the dev list if they don't meet expectations, and placed on a PIP if their performance does not improve. I'm guessing it reflects poorly on managers if they devlist someone shortly after hiring them.
During my time at Amazon, I know only one person who was placed on a PIP and he was kind of a bad engineer. But I have heard stories of managers abusing the dev list to meet org-level dev list quotas.
What is the "dev list"
Seems to be an Amazon thing https://www.teamblind.com/post/What-is-Dev-list-at-Amazon-xp...
It doesn't say what "dev" stands for though.
It doesn't say what "dev" stands for though.
No there isnt. I have only known of one person to get a PIP during my 3 years there, and it took way longer then it should've
Ah that was my fear, not because I feel like I'm a terrible software engineer and I'd be asking for PIP by joining Amazon. More just because mortgages etc, I'm very anxious money wise.
You'll be fine. Amazon didn't become the company it is today by burning out hardworking and talented engineers for no reason. In the scenario I am referring to, the engineer did a very poor job of communication and receiving feedback. When your company is as big as Amazon, you're going to have some people who didn't quite fit. The people who succeeded there don't spend their time talking to journalists or complaining on HN
Overall, I spent my time there working with ambitious and smart people. And money-wise, I feel like you can't work at a safer place in the tech industry then at a FAANG company, particularly Amazon.
Overall, I spent my time there working with ambitious and smart people. And money-wise, I feel like you can't work at a safer place in the tech industry then at a FAANG company, particularly Amazon.
Great I had aimed for applying for Stripe in August, again my anxiety is consistent I've quite a encompassing study guide I've made for myself.
Thanks though man you insight is invaluable.
Thanks though man you insight is invaluable.
> It was like night and day - the team was over-funded and had very few operational issues.
oh god which service/team/
oh god which service/team/
Crazy to think that such a profitable unit like AWS could have teams that are hurting for funding. I guess it’s run like that though.
I think AWS teams are not generally hurting for funding. You see that more in retail parts of amazon
Every company struggles with 'properly' managing funding and resources.
I enjoyed my team and the work hours were reasonable. AWS wasn't the type of product work I wanted to keep pursing, but I learned a lot in my time there.
Amazon team's culture vary widely depending on the teams budget, management style and deadlines. Overall I enjoyed my time at Amazon
Amazon team's culture vary widely depending on the teams budget, management style and deadlines. Overall I enjoyed my time at Amazon
Several posts here mention the importance of budget/funding for creating a good team to work in (which is 100% reasonable - that's true everywhere).
I'm curious about how individual teams within Amazon have funding problems.
Amazon overall seems to have plenty of money and they seem like the sort of place that wouldn't have a problem dissolving a team that isn't meeting their goals (I'm assuming they'd dissolve the team and then move people they want to keep to other teams, etc - they seem like they'd be very data driven about what teams to keep, not malicious).
Can anyone shed light on how a team might develop funding / budget issues at a place like Amazon?
I'm curious about how individual teams within Amazon have funding problems.
Amazon overall seems to have plenty of money and they seem like the sort of place that wouldn't have a problem dissolving a team that isn't meeting their goals (I'm assuming they'd dissolve the team and then move people they want to keep to other teams, etc - they seem like they'd be very data driven about what teams to keep, not malicious).
Can anyone shed light on how a team might develop funding / budget issues at a place like Amazon?
From my time at Amazon, I wasn't really a part of these decisions so the following is just my anecdotal perception those businesses and how often teams had things like lunches, team events and hired staff
In general, if the underlying business is profitable or if the product is experimental Amazon will allocate a larger budget to the team
In general, if the underlying business is profitable or if the product is experimental Amazon will allocate a larger budget to the team
- Retail has narrow profits and is fairly well established -> Lower budgets
- AWS is very profitable -> High budget
- Alexa (while I was there) was growing very fast and was trying crazy initiatives -> High budget
[deleted]
Not OP and YMMV but I really like my team and the engineering/research challenges we face are interesting.
I read the infamous "stay the fk away from Amazon" (https://www.reddit.com/r/Seattle/comments/3ce0s8/dear_amazon...) before I was hired and the author's experience is completely misaligned with mine.
I read the infamous "stay the fk away from Amazon" (https://www.reddit.com/r/Seattle/comments/3ce0s8/dear_amazon...) before I was hired and the author's experience is completely misaligned with mine.
I was recently interviewed for AWS, and its a JOKE :), i said i was proficient in Linux and all the questions i was asked was about docker.. and this is just one example out of 100 :)
See Jeff Bezos' famous comment: "It is better to cannibalize yourself; than let others cannibalize you"
This should answer your question and hint what's to come.
This should answer your question and hint what's to come.
The classic case I often heard is Kodak:
https://en.wikipedia.org/wiki/Kodak#Shift_to_digital
It was a pioneer in digital transition but moved too slowly in fear of cannibalizing their film business. Ironically, today it seems printing and their legacy film are their strengths (and the consumer digital camera market is dead, shifted to smartphones) -- which seems to complicate drawing lessons. However, it could easily have invested in e.g. sensor manufacturing if it recognized early the potential of the transition and still be well today[1].
I think a good strategy is to fearlessly cannibalize [1] yourself yes, but don't abandon your strengths and expertise, instead use them to propel your new ventures.
[1]: I think a good definition of self-cannibalization is due. In this case, it refers to abandoning unstable businesses. For example, trying to hold a market by forcing out "better", newer devices (digital vs film) is unstable -- you're betting on blocking the adoption of a better alternative.
[2]: Sony appears to have done well, today the leading camera sensor manufacturer https://www.businesswire.com/news/home/20201007005124/en/Str...
https://en.wikipedia.org/wiki/Kodak#Shift_to_digital
It was a pioneer in digital transition but moved too slowly in fear of cannibalizing their film business. Ironically, today it seems printing and their legacy film are their strengths (and the consumer digital camera market is dead, shifted to smartphones) -- which seems to complicate drawing lessons. However, it could easily have invested in e.g. sensor manufacturing if it recognized early the potential of the transition and still be well today[1].
I think a good strategy is to fearlessly cannibalize [1] yourself yes, but don't abandon your strengths and expertise, instead use them to propel your new ventures.
[1]: I think a good definition of self-cannibalization is due. In this case, it refers to abandoning unstable businesses. For example, trying to hold a market by forcing out "better", newer devices (digital vs film) is unstable -- you're betting on blocking the adoption of a better alternative.
[2]: Sony appears to have done well, today the leading camera sensor manufacturer https://www.businesswire.com/news/home/20201007005124/en/Str...
I think it was Steve Jobs https://www.crowdspring.com/blog/if-you-dont-cannibalize-you...
and that is what they did
iPhones cannibalized iPods
iPads put a dent on Macs
iPhones cannibalized iPods
iPads put a dent on Macs
iPhones cannibalizing iPods is true in theory but misses it in spirit. It’s not a hard argument to make to sell a product that is more profitable and a larger addressable market.
The Mac just had its best quarter - ever - before the release of the M1 Macs.
The Mac just had its best quarter - ever - before the release of the M1 Macs.
This the AWS extension of the Marketplace part of Amazon retail. Thanks to this, they will know how companies are running their systems on other clouds, the same way the know what independent vendors are selling and how well.
This is going to be very interesting on the long run.
This is going to be very interesting on the long run.
With anthos and arc, the iaas market is going to be commodity with near zero margin. The writing is on the wall that services will be the more profitable market in the long run. AWS recognizes this and the multi cloud push is the way to maximize on that.
This looks like Amazon FUD. The revenue from alternate clouds will be tiny compared to running in AWS, so there's not much motivation internally to follow through. Also, to make money on other clouds you have to go deep on the products and offer value adds on top. That's not the Amazon model and anyway would be difficult to implement outside of a small number of products. Ergo, this is not something they are really going to do in a meaningful way.
MS SQL Server is a historical analogy. Microsoft could have run the table in the database market by porting to Linux but took years to overcome internal inertia required to run outside Windows.
MS SQL Server is a historical analogy. Microsoft could have run the table in the database market by porting to Linux but took years to overcome internal inertia required to run outside Windows.
My experience in the three majors approximates market share.
There are a lot of differences but AWS is just better (obvs opinion). When organizations are less locked in they have flexibility to choose according to evolving preference and this makes multi-cloud a systemic customer acquisition strategy. Consider multi-cloud an on ramp and I think you look at the basis for the strategy.
Consider further that fuzzier cloud boundaries re-enable the innovation pipelines that start ups deliver to the incumbents but that were being complicated by cloud boundaries.
There are a lot of differences but AWS is just better (obvs opinion). When organizations are less locked in they have flexibility to choose according to evolving preference and this makes multi-cloud a systemic customer acquisition strategy. Consider multi-cloud an on ramp and I think you look at the basis for the strategy.
Consider further that fuzzier cloud boundaries re-enable the innovation pipelines that start ups deliver to the incumbents but that were being complicated by cloud boundaries.
That's a possibility. Another one would be more out of regulatory requirement within financial services. By default, most top tier banks would need multi-cloud to even begin thinking about a cloud journey so this offering just puts AWS in the right space with their competitors. It's possible that most of the operational workloads will run on AWS with other cloud vendors being in place as backup/secondary workloads. Might also be some good discounts given by AWS to secure the deal.
Not true. I used to work at a very large us bank and while multi-region was a thing the regulators cared about, multi-cloud was not.
Yeah, once those customers have a set up they can just price them into only using AWS Cloud
Deals already signed, thing are already integrated
Deals already signed, thing are already integrated
with the ever expanding number of services/industries Amazon is operating at(or planning to get into) , the vendor lock in is becoming the real deal. Ex walmart wont go to aws, just because and it probably never will!
So the loss of AWS is gain for Azure(w.r.t Walmart) and frankly apart from the 365 offerings people are taking azure seriously because Azure or Microsoft doesn't compete with other industries on a broader scale!
On the flip side, Netflix uses AWS even though amazon competes it with Prime (not sure for how long), as amazon knocking the doors of new industries such as Big pharma, either they need to move AWS as a separate company or ease them with these kind of multi cloud measures.
So the loss of AWS is gain for Azure(w.r.t Walmart) and frankly apart from the 365 offerings people are taking azure seriously because Azure or Microsoft doesn't compete with other industries on a broader scale!
On the flip side, Netflix uses AWS even though amazon competes it with Prime (not sure for how long), as amazon knocking the doors of new industries such as Big pharma, either they need to move AWS as a separate company or ease them with these kind of multi cloud measures.
Some times new decision makers join the company and they want to use other cloud providers. That's a valid concern that most people should have as they're building out things specific to one vendor.
Bezos wants you controlling everything from AWS, be that your own servers with GreenGrass or GCP/Azure through managed Kubernetes.
Don’t read too much into this — they are just catching up with GCP and Azure here. AWS has a history of introducing half-assed products with great fanfare when the lack of such a product could be a disadvantage for customer acquisition (think Beanstalk, Cognito or Amplify).
Don’t forget their ElasticSearch version. Now that is a shit show.
Man I remember, whenever we needed to update a cloudformation template that triggered an ElasticSearch modification it was horrible. And of course, after waiting 1.5h, some dns change failed and it had to be rolled back and you just wasted half a day.
Fun times.
Fun times.
That reminds me of that time I had to do a snapshot on an EBS volume that had Jenkins on it. Took five days to do a 2TB volume.
Local VMware about ten minutes.
Edit: I notice a flurry of downvotes arriving since US woke up. Must be Amazon team coming on line :)
Local VMware about ten minutes.
Edit: I notice a flurry of downvotes arriving since US woke up. Must be Amazon team coming on line :)
AWS mislabeled something that is a "backup" (delta copy to s3) as a "snapshot". That's not what is called snapshot in the storage world. Granted ESX snapshots aren't exactly that either.
Why is it a shit show?
This article neatly outlines some of it. Unfortunately I didn’t go digging and got enticed by the marketing in the end.
https://spun.io/2019/10/10/aws-elasticsearch-a-fundamentally...
https://spun.io/2019/10/10/aws-elasticsearch-a-fundamentally...
what do you mean? they have customers using it in prod
AWS could release a literal turd and someone somewhere would use it in production. Which doesn't mean you should too.
So did MongoDB from day minus one.
Well mongodb is a much better product than it was a few years ago. not saying its a good one but...
and aws elastic is just a fork of a stable elastic release. it makes sense if the cost is competitive
and aws elastic is just a fork of a stable elastic release. it makes sense if the cost is competitive
There are... quite a number of reasons you should give pause to the idea of running AWS hosted elastic.
If you’re really up against the wall and don’t want to manage elasticsearch I would highly recommend getting the managed services from Elastic themselves. Support is decent and they’re cost competitive.
If you’re really up against the wall and don’t want to manage elasticsearch I would highly recommend getting the managed services from Elastic themselves. Support is decent and they’re cost competitive.
> There are... quite a number of reasons you should give pause to the idea of running AWS hosted elastic.
Care to share some of these reasons?
Care to share some of these reasons?
I can't go into details, but let me say that someone who would be in the know at AWS, very much off the record, told us not to use their hosted elastic because of how terrible it is.
Some issues: scaling it is manual (a "managed service" that requires direct management to scale is not a managed service lol), the elastic versions supported are usually woefully out of date, limited customer adoption means that the product doesn't get a lot of engineering attention and is just limping along, etc.
Some issues: scaling it is manual (a "managed service" that requires direct management to scale is not a managed service lol), the elastic versions supported are usually woefully out of date, limited customer adoption means that the product doesn't get a lot of engineering attention and is just limping along, etc.
I totally agree but if your requirement is just to have elastic for a standard search use case and don't need any new features it might make sense... out of date doesnt mean its garbage.
I am not against manual scaling anyway at some level you always need to do manual scaling on AWS whatever the product...
I am not against manual scaling anyway at some level you always need to do manual scaling on AWS whatever the product...
That’s what we were told as well. Plus also various things like cross region replication being unavailable. Also things like management ports are not possible to get to.
Edit: also plan to lose everything in it.
Edit: also plan to lose everything in it.
Their sales team are awful. They don’t even understand the product they are selling.
I can't think of a better description of their EKS launch than "half-assed product introduced with great fanfare when the lack of an alternative to GKE was a disadvantage for customer acquisition." EKS had much improved when I last played with it around a year ago, though.
Posts like these always seem buried in deep marketing lingo. Can anyone "in the know" ELI5 how this is different than Google Anthos? [1]
If they are in fact similar, I can't help but be left wondering why ACG didn't devote at least a sentence or two to comparisons that already exist in the industry.
[1] https://cloud.google.com/anthos
If they are in fact similar, I can't help but be left wondering why ACG didn't devote at least a sentence or two to comparisons that already exist in the industry.
[1] https://cloud.google.com/anthos
The post does mention Azure's Arc and Sentinel, but definitely should have called out Anthos specifically.
The interesting part of this to me isn't so much that other solutions already exist -- Azure and GCP, due to their catch-up position, have always been far more conciliatory toward the reality of other cloud workloads than AWS. It's that AWS is signaling, however grudgingly, that they will have to play ball with other clouds in order to stay ahead. That's a big shift.
The interesting part of this to me isn't so much that other solutions already exist -- Azure and GCP, due to their catch-up position, have always been far more conciliatory toward the reality of other cloud workloads than AWS. It's that AWS is signaling, however grudgingly, that they will have to play ball with other clouds in order to stay ahead. That's a big shift.
Hi Forrest, hopefully constructive feedback - your choice of font color (rgb(74, 93, 133) I think) for text overtop #fff background is extremely washed out for me, not quite unreadable but heading in that direction. I might suggest a darker choice of font color for better readability, I just gave up trying to finish reading the article due to eye strain.
Edit, screenshot: https://postimg.cc/kRmGmSJh
Edit, screenshot: https://postimg.cc/kRmGmSJh
Thanks for this feedback - will share with the ACG design team.
Thanks for pointing that out. Unfortunately, still no mention [in the post] of how Azure's Arc/Sentinel is different than what AWS has seemingly built here. And agreed, it's an interesting signal.
The difference is (just based on what AWS say about ACG) is that anthos comes into its own when managing multiple clusters. The drawback is that all the most common infrastructure requires you to be all-in on GKE and the google stack. If you want to use Cassandra or Postgres, for example, you either manage it yourself or use the google options. The problem with this is that you basically give up all the benefit of having a multi-cloud approach by following this approach. However! If you have a bunch of legacy systems sitting on an on-prem set of self-hosted hardware finally you can mix and match between the on-prem stuff and the GCP managed cluster.
ACG sounds like it can be used to manage hosts and containers; so it's more like enhanced k8s / EKS than a meta layer above kubernetes. This is just my take on this product based on how the marketing lingo talks about it. I'm much more familiar with AnthOS
ACG sounds like it can be used to manage hosts and containers; so it's more like enhanced k8s / EKS than a meta layer above kubernetes. This is just my take on this product based on how the marketing lingo talks about it. I'm much more familiar with AnthOS
How long before someone releases a multi-multi-cloud solution so that we don't have to lock ourselves into a particular vendor's multi-cloud solution?
Isn't this the same thing Google is doing with Anthos and Azure is doing with Arc? As I understand it, those solutions are both wider in scope than this. I'm not entirely up to date on those, but this seems more like AWS half-heartedly following the pack than something new.
It's very much new for AWS. Their messaging has always been incredibly exclusionary of other clouds. to the point where they've even prohibited their partners from using words like "multi-cloud, anycloud", etc.
Finally. I made a very similar suggestion to the ECS product manager about 5 years ago. We were moving from Mesos to ECS and I was losing the ability to manage Docker containers on our on-premises servers so I suggested allowing us to run the ECS Agent on our on-premises servers. This would allow us to centrally manage those servers and would get AWS into our on-prem infrastructure...
Unrelated but is ACG a good learning platform?
I'm never sure with these types of platforms because I am not interested in any certifications and such, so it is hard to tell whether they just teach the stuff needed for these certifications and nothing more...
I'm never sure with these types of platforms because I am not interested in any certifications and such, so it is hard to tell whether they just teach the stuff needed for these certifications and nothing more...
ACG employee here so grain of salt, etc - but I paid for an ACG subscription long before I worked there.
My favorite piece of ACG actually isn't even the courses, but "Cloud Playground", which came over in the recent Linux Academy acquisition. [0] One-click AWS, Azure, or GCP sandbox environments. They're live for 4 hours on ACG's credit card and people sometimes assume they're just for doing course labs, but, like, you can use them for whatever. It's an end run around sandbox account procurement in a business context, or a safeguard against leaving an expensive resource running for personal experimentation.
[0] https://help.acloud.guru/hc/en-us/articles/360001477955-Clou...
My favorite piece of ACG actually isn't even the courses, but "Cloud Playground", which came over in the recent Linux Academy acquisition. [0] One-click AWS, Azure, or GCP sandbox environments. They're live for 4 hours on ACG's credit card and people sometimes assume they're just for doing course labs, but, like, you can use them for whatever. It's an end run around sandbox account procurement in a business context, or a safeguard against leaving an expensive resource running for personal experimentation.
[0] https://help.acloud.guru/hc/en-us/articles/360001477955-Clou...
Yep, I love that feature and they provide a grandfather / lock in policy for accounts.
It isn't a perfect platform but the breadth and centralization has been great and the communication following the acquisition has been good. It is well worth the cost of entry.
The demos are valuable as well since they start you with certain infrastructure and you can focus on the drill/demo.
I would love to see some of the Terraform/Cloudformation templates that go into these products...
It isn't a perfect platform but the breadth and centralization has been great and the communication following the acquisition has been good. It is well worth the cost of entry.
The demos are valuable as well since they start you with certain infrastructure and you can focus on the drill/demo.
I would love to see some of the Terraform/Cloudformation templates that go into these products...
Licensing and selling the 'don't cost us a million bucks in 4 hours' code monitoring (I hope!) that stuff on the backside would be welcomed by maaaaany large organizations :)
>I am not interested in any certifications and such
ACG is very focused specifically on helping you pass the certification exams. It can still be helpful even if you don't want a cert because naturally there is some overlap between passing a cert and knowing how to use AWS/GCP/Azure, and one great thing about ACG is access to the AWS playground environments where you can get hands-on experience. However, if your goal is to ignore the cert and really learn the material, you might look elsewhere.
That said, the ACG courses for the basic level AWS certs really don't take more than a couple weekends to go through, and at only $25/mo, it's not a bad investment to just pay for 1 month, get the foundational level knowledge, then move on to other ways of learning.
ACG is very focused specifically on helping you pass the certification exams. It can still be helpful even if you don't want a cert because naturally there is some overlap between passing a cert and knowing how to use AWS/GCP/Azure, and one great thing about ACG is access to the AWS playground environments where you can get hands-on experience. However, if your goal is to ignore the cert and really learn the material, you might look elsewhere.
That said, the ACG courses for the basic level AWS certs really don't take more than a couple weekends to go through, and at only $25/mo, it's not a bad investment to just pay for 1 month, get the foundational level knowledge, then move on to other ways of learning.
I used their course as part of training for one of the AWS Certs and found the videos/quizzes pretty informative and useful. Not too long-winded, and an easy enough to use interface.
I only did the one course, but from that, I'd recommend it.
I only did the one course, but from that, I'd recommend it.
[deleted]
Their content is absolutely average.
ACG as a company nearly killed Jupiter Broadcasting. JB were able to escape but are facing many years financial hardship due to an overly burdensome litigious culture from ACG after the acquisition of Linux Academy from separating the two businesses.
This split came on the heels of a questionable HR policy implementation around the firing of Joe Ressington. Reverse sexism is apparently OK but casual swearing during a work trip to the pub, is not.
From an ethics perspective, avoid ACG. There's a lot more I could say on all this but I won't - it's hackernews not reddit.
ACG as a company nearly killed Jupiter Broadcasting. JB were able to escape but are facing many years financial hardship due to an overly burdensome litigious culture from ACG after the acquisition of Linux Academy from separating the two businesses.
This split came on the heels of a questionable HR policy implementation around the firing of Joe Ressington. Reverse sexism is apparently OK but casual swearing during a work trip to the pub, is not.
From an ethics perspective, avoid ACG. There's a lot more I could say on all this but I won't - it's hackernews not reddit.
Thank you but would you mind providing even more context/data here? Listening to different Jupiter Broadcast shows, their advertisements seem to have seamlessly transitioned from Linux Academy to ACG. So I can't say I have encountered that drama...
Isn't EKS just Kubernetes with custom integrations for various AWS services? If so, how do you meaningfully bring EKS to another cloud without bringing those services? Does EKS call over the public Internet into those other AWS services (and thus lower latency, paying for network usage, etc)? If so, what's the advantage of running EKS anywhere other than on Amazon?
Presumably with EKS you can already run your worker nodes on prem or on GCP or wherever, so is this just moving the masters over as well? If you're willing to run your other AWS services on AWS, what's the big advantage of running EKS outside of Amazon as well?
Presumably with EKS you can already run your worker nodes on prem or on GCP or wherever, so is this just moving the masters over as well? If you're willing to run your other AWS services on AWS, what's the big advantage of running EKS outside of Amazon as well?
The EKS Distro blog post answers some of the questions.
https://aws.amazon.com/blogs/opensource/introducing-amazon-e...
https://aws.amazon.com/blogs/opensource/introducing-amazon-e...
Good questions. I'd guess you'd have to make interface pods for those services if possible maybe?
Then before switching providers write new interface pods?
Sounds easier said than done but I guess that's one option.
Then before switching providers write new interface pods?
Sounds easier said than done but I guess that's one option.
EKS Anywhere sounds promising, but I fear the data transfer charges between the two.
Yes is there an optimistic take on this problem? Any indication that something like AWS EKS multi-cloud will sidestep it? Every time I read one of these announcements I just shudder to think about how the costs will scale.
Are most multi-cloud setups just very careful about intra-cloud data transfers?
Are most multi-cloud setups just very careful about intra-cloud data transfers?
We are single cloud (effectively) and have been bitten by data transfer costs multiple times, so we're always looking out for it.
Can someone comment on what does this mean for VMware? On one hand this supports their new vSphere offering, but on the other it provides a competition for managed Kubernetes clusters. In the FAQ they write "Adding bare-metal support will address customer desire to eliminate the license cost and operational overhead of managing VMware." But is this really going to happen with enterprises running on bare metal serves? Seems rather unrealistic.
There has been a player in "AWS compatible workloads" for quite some time, the french company Outscale:
https://us.outscale.com/products/compute/aws-compatible-clou...
They have PoPs in several "exotic" locations, but I'm not entirely sure the list is public. They also run AWS-compatibles clouds for state actors.
https://us.outscale.com/products/compute/aws-compatible-clou...
They have PoPs in several "exotic" locations, but I'm not entirely sure the list is public. They also run AWS-compatibles clouds for state actors.
All these multi-cloud things by the big clouds are more like ways of putting each big cloud in control of other clouds. They're more a way for them to fight over their center of gravity.
A true multi-cloud solution would be cloud agnostic and independent.
A true multi-cloud solution would be cloud agnostic and independent.
It feels like a commoditize the competition strategy. Essentially the single deployment structure makes your competitors impossible to differentiate other than on price, while still being the access point to the cloud.
For whatever else this move does for Amazon, it probably also helps the optics around current “anti-trust” issues.
How do they charge egress for this?
This is Anthos for AWS, right? Makes sense. The kube primitives are pretty good.
Is there any information about any changes to egress that I missed?
Is this similar to or a response to Google‘a Anthos?
wtf multi-cloud
Don't be fooled, this isn't AWS collaborating, this is AWS working its way into its competitors business. Its a trojan horse.
You mean other companies don’t do things that will ultimately benefit them?
Who does not do that :-)
Disclaimer - I used to work for AWS