1. It’s a problem of perspective. Large companies worry about lock-in because *their* strategy is to lock customers in and then raise prices - so, naturally, they are fearful of this happening to them. They think low prices are a sales gimmick, not a long-term strategy.
2. No one wants to get fired. BigCo tech projects are always over budget, behind schedule, and under-performant - making it worse by going multi-cloud won’t get you fired. But if the ‘lock-in’ boogeyman shows up one day and it’s your fault, you’re fired.
3. All of their peers are worried about lock-in. It’s better to be mediocre, die slowly, and have it be everyone’s fault than it is to do something different & have it be your fault. “No one ever got fired for going multi-cloud” is the new “no one ever got fired for buying IBM.”
4. Cloud computing lock-in really is different. In nearly every other industry, lock-in leads to price gouging or service degradation. But because Amazon is always trying to offer more and charge less, *all the providers* have to adopt this strategy.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
While this is accurate, the tariffs are unfortunately/unintentionally an extinction-level event for US-based Amazon sellers and a huge boost for China-based sellers. 🧵
Amazon has a program that allows Chinese manufacturers to sell on Amazon and fulfill their orders from Amazon’s US warehouses. Amazon handles the importing end to end to make it as easy as possible for them to sell on the platform.
The Chinese sellers list the cost of the goods drastically undervalue actual value to save on tariffs. They occasionally get caught and are shut down, but there’s no recourse and they just spin up a new entity overnight (US sellers risk federal prison if they play this game).
Change Healthcare – the nation's largest clearinghouse for insurance claims and payments – has been down for 13 days and counting due to a cyberattack. It's an absolute crisis – doctors, hospitals, and other providers can't get paid. What is a clearinghouse? What is going on? 🧵
Everyone knows HIPAA as a privacy act – forms to fill out at a doctor’s office. What people don’t know is the *Portability* part of ‘The Health Insurance Portability and Accountability Act’, which directed the department of HHS to establish standards for electronic transactions.
Before HIPAA, insurance companies (aka ‘payers’) and providers all used different formats for insurance claims, payments, eligibility checks, benefits enrollments, and more. It was functionally impossible for all of the parties to do business together without manual intervention.
'If "fear is the mind killer," toil is the soul-killer.'
A few of my favorite, well, excerpts from 'Excerpts from the annual letter'. stedi.com/blog/excerpts-…
I think about this in terms of preferences vs principles: many companies have a preference for operational excellence – but when push comes to shove, principles are defined by what you're willing to sacrifice for them.
A while back, @martin_casado asked me: "do you really think there are *no* circumstances under which it makes sense for a company to go on-prem / bare metal?" In all seriousness, I do think there are several cases where doing so might be necessary. (1/n)
1. You cannot afford to offer your product otherwise. I don't mean "you could do it cheaper yourself" – I mean *your unit economics would be negative* if you used public cloud infra. This is the case in certain rare circumstances. (2/n)
2. It is impossible to deliver your product / product experience using public cloud infra. I don't mean "you can make it better/faster if you build your infra from scratch" – I mean *your product has _requirements_ that preclude the possibility* of using public cloud. (3/n)
(1/n) The entire world of commerce – supply chain, logistics, retail, financial transactions, healthcare, and much, much more – is driven by an arcane technology called EDI. The world around you is powered by transactions that look like they came off a dot matrix printer in 1985:
(2/n) Trillions and trillions of dollars flow through these legacy systems, locked away beyond the reach of modern developers. @Stedi is a collection of composable, API-driven building blocks that make these systems more legible and approachable: edi.stedi.com/inspector?valu…
(3/n) Our EDI Core APIs are now Generally Available. EDI Core translates legacy files like X12 into our modern JEDI (JSON EDI) format. Used in conjunction with our Mappings product, EDI files can be ingested into (or created from) virtually any modern system.
I'm extremely excited to announce that Mappings – @Stedi's first broadly-applicable, developer-focused product – is now Generally Available. Mappings provides a powerful UI for defining JSON transformations, which can then be invoked via API for data mapping at scale. 1/n
Mappings is particularly useful for building integrations – say, transforming Stripe payloads to some custom format – but can be used for any JSON-to-JSON transformation. Just upload a source & target file, then use simple functions to transform fields as necessary. 2/n
The pricing is (of course) 100% usage-based: no minimum fees or upfront costs. Check out the docs, give it a try (with our free tier), and let us know what you think. And if you like it now, just wait til you see how fast it gets better :) 3/n stedi.com/docs/mappings