6 ms·
>Vendor lock-in is something that engineers care about because they like playing with tech. Bad engineers care about vendor lock-in, because they want to pad t
by gambler 8y ago
>Vendor lock-in is something that engineers care about because they like playing with tech.
Bad engineers care about vendor lock-in, because they want to pad their resumes with abstraction tools.
Good engineers care about vendor lock-in, because all cloud providers have limits you do not control. Your architecture can become insanely expensive or simply stop working if something you do grows beyond one of those limits. In those cases you can either re-architect the whole thing or simply switch vendors.
This is one of the hidden costs of "cloud" platforms everyone suffers from but no one talks about.
- scarface74 8y agoIf we grow so large that we hit the limits of whst AWS can handle, I think we will have enough investor money flowing in to be able to afford rearchitecting.
- regularfry 8y agoYou might not be able to afford the time.
- scarface74 8y agoSo what are the chances that your business is going to grow large enough that AWS or Azure can handle the requirements? Is your business likely to grow large enough to need more from AWS than Netflix or even Apple?
- gambler 8y ago>So what are the chances that your business is going to grow large enough that AWS or Azure can handle the requirements? You naively assume that hosting something at AWS or Azure means all of their resources are at your disposal and subject to reasonable pricing. That is not the case. Cloud services are not designed for you. They are designed to make money for whomever actually owns them. They have their own architecture, assumptions and target use cases. In reality, the chances that a large company will eventually hit some limitation of AWS or Azure are nearly 100%. The only question is whether it will be something that can be worked around. One problem with "the cloud" is that a lot of the limits are no-obvious, and if your use case significantly deviates from whatever the provider had in mind, there might not be an incremental solution. Another problem is that linear resource pricing is not always sustainable if you're experiencing exponential growth.
- scarface74 8y agoYou naively assume that hosting something at AWS or Azure means all of their resources are at your disposal and subject to reasonable pricing So if I’m “naively” assuming that you should be able to cite a real world case where a company needed more resources than AWS or Azure is willing to provide. “Reasonable pricing” for any supplier that a company uses is a price where the company can pay their suppliers, do something to add value, and make a profit. Cloud services are not designed for you. They are designed to make money for whomever actually owns them. They have their own architecture, assumptions and use cases. Guess what? All of the suppliers you use for your business are in business to make money. And if your use case doesn’t fit within their managed services offerings, your escape hatch is to bring up a VM and install whatever you need on it. In reality, the chances that a large company will eventually hit some limitation of AWS or Azure are nearly 100% Where are the case studies? The problem with "the cloud" is that a lot of the limits are no-obvious, and if your use case significantly deviates from whatever the provider had in mind, there might not be an incremental solution. Every time I log on to AWS, and go to the support page, I see our account based limits. The non account specific limits are publicized. Which specific limits are you referring to? As far as working around unknown limits of off the shelf managed services - that’s why companies hire programmers. Another problem is that linear resource pricing is not always sustainable if you're experiencing exponential growth. And if your marginal revenue is not exceeding your marginal costs, that says more about your business model than anything else.
- gambler 8y ago>So if I’m “naively” assuming that you should be able to cite a real world case where a company needed more resources than AWS or Azure is willing to provide. https://firstround.com/review/the-three-infrastructure-mistakes-your-company-must-not-make/ https://firstround.com/review/the-three-infrastructure-mista...
- scarface74 8y agoWell. I can tell you that the article is demonstrably wrong. It makes it easy to do things like user identity. Authentication. Queueing. Email. Notifications. Seamless databases. These are all lightweight services that can save you a lot of time, but only if you’re using AWS. The magic (for Amazon) is that they deter people from migrating despite mounting costs for storage and bandwidth. All of those lightweight services have publicly accessible endpoints that can be used in conjunction with self managed infrastructure either over the public internet, a VPN or a direct connect. But, your contention that you quoted was that AWS/Azure “wasn’t willing to provide it”. Yet you posted an article where the cost of providing it wasn’t conducive to their business model. Then I could always post about a little streaming service you might have heard of called Netflix that has all of its infrastructure besides its caching servers (that are colocated at ISPs) on AWS and the reason they decided to move to AWS. https://www.se-radio.net/2014/12/episode-216-adrian-cockcroft-on-the-modern-cloud-based-platform/ https://www.se-radio.net/2014/12/episode-216-adrian-cockcrof... But really what does it say about a company that is growing fast unprofitably? Were they profitable when they were spending $20K a month?
- regularfry 8y agoMy business? Close to zero. But: > If we grow so large that we hit the limits of whst AWS can handle, I think we will have enough investor money flowing in to be able to afford rearchitecting. Apparently you think you're in danger of that happening, so what makes you think you can buy time with money?
- scarface74 8y agoI don’t think I will. I’m not the one posting about the hypothetical boogeymen that a business I work for is going to grow so large that a cloud provider can’t handle it. As if some how that same business could build out a data center that could scale better than AWS or Azure.
- regularfry 8y ago> I’m not the one posting about the hypothetical boogeymen that a business I work for is going to grow so large that a cloud provider can’t handle it That's literally what you said in the post I quoted. > As if some how that same business could build out a data center that could scale better than AWS or Azure. You're the only one straw-manning this with on-prem. The whole context of the discussion is around being able to move between cloud providers. Why are you bringing a point into the discussion nobody else thinks relevant?
- scarface74 8y agoThis is the original post I was responding to: You can easily grow so large that you hit a limit of what a given cloud provider will allow (e.g. API calls or IOPS) at a price that fits into your budget for a task, even if you're not actually especially large. My response was that what are the chances that a company will grow large enough that it will outgrow the resources of a cloud provider? And there are really only three cloud providers worth discussing - AWS, Azure and Google. Besides Google (and if you based your business around then you get what you deserve) what cloud provider has raised prices on a whim? Which provider’s cost are so out of line with the other that it is worth the switching costs? Besides, if you’re that large, you’re paying negotiated prices not published prices. In fact one post was specifically about building out specialized infrastructure at a colo. https://news.ycombinator.com/item?id=19731913 https://news.ycombinator.com/item?id=19731913 If you’re so large and you are going through the costs and risks to move off of a cloud provider, why put yourself in the same position again by migrating to another provider?
- kensey 8y agoYou can easily grow so large that you hit a limit of what a given cloud provider will allow (e.g. API calls or IOPS) at a price that fits into your budget for a task, even if you're not actually especially large. (AWS will give you all the IOPS you can ever use... as long as you have the money to pay.) In that case, being able to pivot to another cloud provider quickly can save your burn rate. (Flashback to my ITIL instructor in 2008 talking about Service Catalogs and how they are meant to include even discontinued products. "Will Microsoft support Windows 3.1 for you today? YES! Bring money.")
- scarface74 8y agoAnd you think you can host on prem and support your use cases without any budgetary constraints?
- regularfry 8y agoIs "on prem" the same as "another cloud provider"? Or is it irrelevant to the discussion?
- scarface74 8y agoIf you need resources, either you’re going to have to pay a cloud provider or run them in your own data center or at a colo.