Disclaimer - I used to work for AWS
Disclaimer - I used to work for AWS
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.
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.
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.
I’ve seen it multiple times in my careeer.
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.
Like the commentator you responded to said. There are many fools in business.
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.
It's a total boogeyman and I've never heard anyone care about it except on HN, where it comes up constantly.
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.
I always wondered why big enterprise customers are not concerned about lock in. Maybe they cut multi year deals with the big cloud providers?
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.
- 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.
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.
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.
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.
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.
It's only half a million dollars to egress 10 PB from S3. You'll be fine.
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?
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.
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)
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....)
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.
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
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”.
How many man hours was spent babysitting infrastructure?
Lock in is a _very real problem_, but often you hear on HN scare mongering that making any decision at all is "lock in".
I get its heavily dependent on the team, just wondering from your perspective.
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.
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?
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.
It doesn't say what "dev" stands for though.
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.
Thanks though man you insight is invaluable.
oh god which service/team/
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.
Amazon team's culture vary widely depending on the teams budget, management style and deadlines. Overall I enjoyed my time at 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?
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 moneyI 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.
This should answer your question and hint what's to come.
iPhones cannibalized iPods
iPads put a dent on Macs
The Mac just had its best quarter - ever - before the release of the M1 Macs.
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...
This is going to be very interesting on the long run.
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.
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.
Deals already signed, thing are already integrated
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.