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.

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)

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.

> 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.

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 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.

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.

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?

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.

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.

> 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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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”.

Did avoiding lock in do anything as far as making them more competitive in the marketplace?

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".

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/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.

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

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.

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.

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?

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.

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.

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.

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.

> It was like night and day - the team was over-funded and had very few operational issues.

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

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?

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

  - 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

Contrast this to my impression of Google, where it seems like every team has roughly the same perks but only a few make money

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 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 :)

> i said i was proficient in Linux and all the questions i was asked was about docker

Why is that bad? The purpose of an interview is to see if you're fit for the role, not quiz you on the skills on your resume.

Yeah, you sound credible/s

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.

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...

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 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.

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.

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.

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.

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

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.

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.