5 ms·
I would disagree with that characterization and would instead say that DynamoDB's lack of portability between vendors made it a non-optimal solution. The servic
by giaour 7y ago
I would disagree with that characterization and would instead say that DynamoDB's lack of portability between vendors made it a non-optimal solution. The services I work on need to survive specific vendors going out of business.
- scarface74 7y agoWhat’s more likely to happen your company going out of business or AWS? Is your company better capitalized than Amazon? Would you also refuse to use Windows just in case Microsoft went out of business?
- stephenr 7y agoAmazon going out of business isn’t the only reason you shouldn’t be happy to be tied to them. If you want decent “high availability” and failover when shit hits the fan, that means multi vendor. Who else offers dynamodb? If amazon were to increase the price of dynamo db 10x would you still just keep using it, because you’re already using it, and eat the 10x cost increase? The amount of comments that essentially boil down to “amazon is not going anywhere, you’re stupid for worrying about lock in” is both staggering and depressing.
- scarface74 7y agoYou mean if multiple availability zones go down? In AWS’s entire existence, have they been known to raise prices? How much time, energy, and development effort are you willing to spend on “avoiding vendor lock in” in the off chance that you will move your entire infrastructure as opposed to spending those same resources creating either revenue generating features or cost saving features? If you’re using a cloud provider as a glorified overpriced colo, you have the worse of all worlds. You’re spending more on resources and just as much babysitting infrastructure. It’s just like the bushy tailed “architects” who create layers of “factories” and “repositories” just in case their CTO wakes up one day and decides to move their companies six figure Oracle installation to Postgres. All the while creating suboptimal queries to avoid using Oracle specific functionality.
- AtlasBarfed 7y agoHow long have you been an employed programmer? On the scale of decades things can change dramatically. In theory (based on the cost of an instance vs the cost to get your own) AWS is grossly overpriced, and SOMEONE will eventually beat them by a very large margin for commodity services. AWS knows this, and probably is behind all its custom features. AWS is the new IBM.
- scarface74 7y agoWell, if the 74 in my username doesn’t give it away, quite awhile. But just to give you a hint, my first professional contract in college was writing a Gopher site. My first hobby projects involved writing 65C02 assembly in the mid 80s. As far as IBM, if someone had chosen to get “locked-in” to IBM in the 70s, they could still buy new hardware that could run their old software unmodified. Isn’t that an argument for using AWS? In the scale of decades, most of the time you will be performing heavy rewrites anyway, are you really trying to optimize now just in case in 20 years you might want to move to something else? Are you using the same language and frameworks you were using 20 years ago? When I first started developing I was writing C programs on DEC VAX, Stratus VOS mainframes. If you are just using AWS to host a bunch of EC2 instances and as an overpriced colo, sure you could find much cheaper options now. No matter what you do, more than likely you will have to migrate. Just changing infrastructure if all you’re doing is moving to VMs on another provider, reconfiguring your network if you are using a hybrid, etc is going to be a heavy lift no matter how much you try to avoid lock in and you’re spending money now for an amorphous future where you may want to change vendors instead of using your vendor of choices features that can save you money and/or time. I would make the same argument if we were talking about Azure or God forbid Oracle.
- stephenr 7y agoSo far most major AWS instances I’ve paid attention to have been ultimately caused by their own Rube Goldberg inspired infra. Nothing at AWS just is something, it practically all relies on something else at AWS, and when there are outages at the apparently lowest level, the issues are wide spread. With such convoluted systems, fat finger syndrome seems to be a not insignificant factor in their downtime, and the interdependence just makes it blow up. But sure. If you want to trust everything to aws you go right ahead and do that. As for rising prices - I have no idea - no company has done anything until they do it the first time. AWS doesn’t really need to increase prices to be a more expensive solution for the vast majority of companies using it. If you don’t rely on proprietary aws “solutions” in the first place, there’s no extra “time and cost” involved. It’s just running your setup process - whatever that may be - with another location, another vendor, whatever. Like I said if you want real HA you’re going to be running in multiple vendors all the time - it’s not something you’re going to say “well shit aws is down again let’s go sign up for azure”. You’re going to sit back and eat crumpets because your site is running fine in spite of aws or azure or whoever’s latest brown pants event. And to be clear I’m not suggesting using aws is a smart move over bare metal or even just regular rented virtual machines at a normal facility - the concept of HA across vendors applies the same.
- AtlasBarfed 7y agoAWS is like crack to developers, especially ones that used to be tied down to enterprise data centers and their six month procurement schedules. So you get a lot of "addict reasononing".
- giaour 7y agoI'm a civil servant, so I look at these questions with a different mindset. I consider adopting a proprietary service to be a decision that entails a fair amount of risk, as I would have no easy recourse should the service become completely unavailable for reasons beyond my organization's control. This could happen for a number of reasons, including the vendor going out of business or raising prices beyond my authority to pay. I might find that risk acceptable in some cases (e.g., most people who work at my agency use Windows on their workstations, some critical services are still running on z/OS, we use tools like Splunk and New Relic for monitoring), but it might not be worth it in other cases. This would get weighed against other forms of risk (such as the risk that a hand-rolled Cassandra cluster would have less availability than DynamoDB or the risk that you might spend more money than necessary using RDS instead of on-demand DynamoDB).
- scarface74 7y agoLet’s see how much the US government spends on some “proprietary services”.... Oracle: $3 billion. https://federalnewsnetwork.com/reporters-notebook-jason-miller/2016/09/oracle-leave-gsa-schedule-signal-broader-change/ https://federalnewsnetwork.com/reporters-notebook-jason-mill... Microsoft $7.6 Billion https://www.marketwatch.com/story/microsoft-vendors-win-76-billion-government-deal-2019-08-29 https://www.marketwatch.com/story/microsoft-vendors-win-76-b... Both AWS and Azure have separate gov regions. Civil servants have never been adverse to spending money on proprietary solutions.
- giaour 7y agoYes, as mentioned above, we do use proprietary solutions where appropriate. However, all else being equal, I would prefer a managed but replicable service (e.g., MCS or Aurora MySQL) over a purely proprietary one, because deploying a replacement Cassandra or Vitess cluster is usually less costly than rewriting an application to use a different data store.