3 ms·
I do wonder why they decided to tie themselves heavily to AWS tech over using cloud-agnostic alternatives. You'd think for a government the latter has higher va
by dtech 2y ago
I do wonder why they decided to tie themselves heavily to AWS tech over using cloud-agnostic alternatives. You'd think for a government the latter has higher value than for private business, and even there it's a consideration.
- szszrk 2y agoNotice that each major cloud vendor has dedicated gov regions... So I guess the tie is larger than it seems at first sight.
- politelemon 2y agoEcs isn't exactly tying, because ultimately it's still docker containers, so moving out wouldn't be a tricky prospect. A cloud agnostic solution though would likely mean k8s and bring with it much more complexity and overhead (and is also a form of lock in).
- aquaticsunset 2y agoI half agree with you. We just went through an ECS to EKS migration, and we're still incredibly dependent on AWS. The hard part isn't the container orchestration system or even containerizing your workload - it's all the other crap you need to develop and maintain around it. Your databases, networking stack, MQ brokers, secrets managers, and everything else are still stuck to whatever cloud provider you're using. EKS really isn't much harder to build out than ECS - but it doesn't set you up to be much more cloud agnostic.
- acdha 2y agoI can’t speak for .gov.uk but in .gov one of the big factors is staffing and support costs. If I need to store some stuff, maybe I am looking at S3 and Minio. If I decide that I want a full open source stack running on my own Linux boxes, that’s a super valid reason but it immediately increases my ops staffing requirements considerably: not just to keep the service running (minio is hardly needy) but now I have to do all of the mandatory security and compliance stuff which AWS handles – failover and backup testing, hardware security (building access, shredding disks, firmware updates, etc.), infrastructure and software security setup and auditing, capacity planning, etc. I have to do some of those things with S3, but it’s multiple orders of magnitude less work and regulated environments often have policy challenges (e.g. slow change management processes, mandatory use of tools not intended for your situation) which AWS’ much larger team doesn’t even have. Again, there are reasons to consider it anyway but if your goal is to show a new capability you probably don’t want to first spend a year or two on infrastructure nobody can even see. The other thing is the ease of replacement versus the cost of abstraction. ECS is a very lightweight service (as are many things like SQS, RDS, etc.) and if you have to migrate to something else that part of it will be the least of your worries, but unless it’s highly likely that you’re going to switch cloud providers you are likely to have many years of not needing to spend time running an internal cloud. Similarly, unless you anticipate switching on a hard, near deadline it’s likely that the effort of porting later will be less than the time you’ll save in the years before the mandate comes. That’s a room full of people who can be working on the things your users actually ask for rather than treading water, especially because one big challenge for an internal PaaS is that you have to build a ton of services to even be an option: if a project needs one feature your PaaS doesn’t offer, they’re going into AWS and you get none of their business. I suspect they hit that trap of just not having enough resources to stay competitive with what their users needed.