It's really hilarious to me that some new amazing technology comes out and people immediately are like "how can we not use this?"
The right approach would be to open an text file and start writing all your hardware drivers, an operating system, a database system, application services etc. so that you'll never ever be locked into anything, and you'll always be 100% in control of everything at all times.
Shit, at that point you'll also need to make sure you fabricate your own chips, lay your own pipes, invent your own transfer protocol, etc. as that's the only way to be absolutely certain you won't get locked in.
But then at that point, you've created a prison of your own demise.
That is the thing that the “lock into a vendor” people don’t understand. You build your own stuff and you can lock yourself into your own stuff and it can be incredibly hard to get out.
I’ve seen it happen time and time again. Companies write their own frameworks, build systems, hardware provisioning systems, analytics systems, you name it... all to avoid “lock in”.
All of that home brew stuff usually sucks. Almost all of it becomes abandonware that one or two people in the company know how to change. Why? Cause all that stuff has nothing to do with how the business delivers value. All of it should have been provided by third party packages.
But now the company got big and they are locked into shitty homebrew garbage that would take a massive political and engineering effort to get out of.
Moral: it is just as easy to lock yourself into your own garbage as it is to lock yourself into a third party. Leave stuff that doesn’t add value to your business to people whose business it is to build that stuff. Beware of doing everything in-house.
It's even worse when you lock yourself into your own garbage. At least locking yourself into a framework that other people use you have a chance to find someone with the same issue and there are people outside of your company that know how to use it -- as opposed to your own bespoke framework.
You know, there's a sensible middle point between the two extremes!
It's important to ask questions like that – "what happens if this service got away / becomes unaffordable / removes features we depend on". There's risks in that sense with using proprietary technology. Sometimes it'll be worth it, because the benefits of allowing you to deal more quickly with business problems will outweigh the technical risk. But I've definitely been in more than a few situations where a vendor has shut down a product or service that I depended on, resulting in a difficult or time-consuming migration.
Some of this risk is ameliorated by using open or popular standards and systems. Intel's not likely to stop producing x86 chips; GitHub is probably going to continue supporting git; Linux isn't going anywhere anytime soon. It's worth thinking about before using a service that nobody else offers!
"Some of this risk is ameliorated by using open or popular standards and systems."
This seems to be the middle ground. Making well-reasoned decisions about which vendors will have a long and well-maintained life of service at the expense of it being trendy or cool.
You're painting as if the only risk was them going away, but there are other risks with being tied to a single provider - like getting huge price increases: https://news.ycombinator.com/item?id=2533416
Meanwhile, the original post you replied to did not say to completely avoid AWS, only to use "standard EC2/S3 services" rather than provider-specific ones. It may not be the middle point you prefer, but it's hardly an extremist position worthy of ridicule.
GAE came out and people immediately built their entire businesses on them.
It's important to provide a detailed analysis weighing the pros vs cons of building an application on any brand new service like GAE etc.
For instance, one con could've been "if they ever increase their prices by X amount, then we're fucked" would've been a pretty relevant con to consider before jumping into using it.
At the risk of being repetitive, I just want to point out, this is not "amazing new technology". Point-in-time database restores are provided by maintaining database write logs and should be a normal part of any serious backup/restore process, not just because they allow for point-in-time restores, but because they're an integral part of standard database recovery situations. They're used to replay changes made between the last backup snapshot and the time of the incident that warrants recovery.
AWS may have contributed some new technologies, but for the most part, they've just wrapped things up in a GUI. I'm not denigrating that as a valid market niche to fill, but people should know that there are non-AWS solutions for virtually everything that AWS provides, and that your company's admins probably already employ a good portion of them.
RDS already has PIT restore, and yes there is a UI for it. This is different. They would not be making an announcement for PIT restore.
A good question is, how is it different. With PIT restores, they create a new instance from snapshot and play back the logs up to the relevant point. With this Aurora-only feature, they take advantage of Aurora's storage capabilities, and rewind the same database to a previous point. No new instance, no cold recovery from snapshot, no long log replay.
Yeah, I know that Aurora already had point-in-time restore. It's disingenuous to pretend like this is something different. This is, at best, an upgrade to Amazon's processes to make the restore process smoother in the ways you've mentioned.
As the previous commentor said, this isn't point in time restore or a change in our processes. It is a change to our database and storage engine to mark regions of log-structured storage as if they did not occur. That's why we can complete a Backtrack in a few seconds - we're just moving some pointers around and restarting the database.
The right approach would be to open an text file and start writing all your hardware drivers, an operating system, a database system, application services etc. so that you'll never ever be locked into anything, and you'll always be 100% in control of everything at all times.
Shit, at that point you'll also need to make sure you fabricate your own chips, lay your own pipes, invent your own transfer protocol, etc. as that's the only way to be absolutely certain you won't get locked in.
But then at that point, you've created a prison of your own demise.