koollman
IANAL, but cloud act purpose is to allow the usa government to ask data from USA-based or USA-related services providers, for offsense/crimes.
It does not allow service providers to do anything else with that data.
They are now at risk if there is a data leak in the USA. There are higher fines for data leaks in Europe, so they aren't as well protected as before
It is cheaper to make stuff without regulations or worker rights.
But, well, that's not really the point you want to make, is it ? :)
It may help others consider what they should be doing to not let this happen to them or imagine what they could do before it happens to avoid being stuck.
But, yes, you do have to plan to run it elsewhere and consider wether various features may make it harder for you to move on. vendor lock-in is a known business risk
Sometimes the plan is "well, this business had a good run, now it is over".
Sometimes it can be as cheap as "well, here's the documentation to run all my stuff elsewhere, starting from my external backups"
Depends on how much money you lose from a failure and how likely the failure is. As an additional point, you may not plan for s3 going down, but even a price hike on egress traffic may put a business in trouble if trying to move without already having external backups. So, as often, you have to do some cost/risk analysis. But having backups not controlled by your main provider is often considered a good idea.
Technical problems, human error, cost changes, various disagreements between provider and customer, can all be made easier if you have a plan B rather than being stuck with a single provider or solution
I understand this is not helpful right now, but there are best practices and many ways to plan for this kind of stuff for good reasons. Some things can and will go wrong, and sometimes that may cost your business a lot, which means you have to anticipate (or accept) the possible costs and risks.
It is part of the job
No alternatives, no disaster recovery plan, nothing you could try for more than a week with some other provider ?
My main gripes with it are:
- (lack of) selection of which device I end up connecting to (typically previous used device, unless not, and if you don't want that and it connects anyway, it is annoying to go and disconnect it)
- shitty audio quality in most implementations if you want to use microphone at the same time as listening to audio
- lack of support for actual multi-device connectivity (not 'this headset can switch between two "connected" sources, only playing from one' but 'this device can mix those two audio sources and play the result', for example. Which shouldn't be much more expensive than the worst case of adding another entire BT circuit + mixer)
Remember to consider more annoying points that can often become hidden costs, or hidden risks: - backups (and more importantly, restores :) ) - maintenance and security (you are in charge of the lower levels too) - decent authentication, authorization, and accounting (AAA) - SLA, both 'in theory' (what does the contract with your provider say) and 'in practice' (how much would an interruption could cost you and what happens if the provider does not respect SLA at all) - how do you handle outages (ideally you want to have a plan to know what to do when the obvious things go wrong. Then for the non-obvious things) - how do you transfer knowledge to a potential new employee. Is there only one person that know how something works. (called 'bus factor')
And yes, most of those also apply if you use AWS, but typically they would cover different parts or have different risks. And usually some associated product you can pay to manage that risk