I mean Mogg is someone who comes across as having his finger on the pulse of society… the best description I’ve ever heard for him is “A haunted victorian drainpipe”. Ultimately the guys stake in Irish hedge-funds are served well by destabilising the pound. I can’t think of one member of the tories who isn’t in politics to make themselves even richer. Everything is grandstanding at the moment.
So I've been trying out Pulumi at the new company I've just started working at and I can say the experience so far has been pretty awesome. This coming from a pre-version 1 user of terraform (when pretty much the only support was the AWS provider). For me HCL was never the killer feature of Terraform, I personally think it was the resource abstraction and providers that made it the best choice at the time. Chef/Ansible runs were always dangerous because as most of us will know from hard learnt lessons, "what you see isn't necessarily what you get". Having a DAG, tracking dependencies between resources, and getting a "this is what you have, this is what you'll get" when you apply a change is the core of what makes terraform great... but this isn't the language, I'd actually argue HCL is where most of it's problems were. The hacks one had to make before HCL 2.0 to get any type of reuse were to be frank, awful. They were also non-obvious, so you had to either pass the knowledge on in your team like a "sage" which isn't scalable for smaller/midsize teams, or let people hit those walls and waste more collective time. Writing languages is hard, and it took Hashicorp years to get it "mostly" right. Though the ergonomics of HCL I would still say aren't very nice or very developer friendly.
Now to Pulumi's merits, if you dive into it's architecture you'll find it's actually users from terraform providers under the hood (very well tested code bases). So it will do things like build a DAG, track dependencies, and give you a diff before you apply anything. From what I can tell it's just changed how you interact with the terraform internals (I'm sure it's more complicated than this, but this is my simple understanding of it). Sure you can get code ordering problems, like any imperative language but it doesn't make it any more unsafe to run as you're protected by the same plan/apply type setup as Terraform. You can also rely on the same language specific quality controls you already rely on. Things like unit tests, integration tests, code coverage, IDE integration etc. Personally I think a better use of time is teaching team members about the infrastructure fundamentals who have an interest in learning them, over getting them to also split focus on a language they will only use in one situation.
I'm not even entirely sure the microservice part is the bit that's ridiculous. I remember interviewing with them a few years back and when I was told the architecture I was like "so you have all these services but you run them off the same database cluster, isn't that like super risky?"
Low and behold pretty much every major outage they've had has been because of their Cassandra cluster. To be fair they have addressed this now, but for it to take N outages and 5 years kind of tells me they could focus a little more attention on properties people value in their banks, like I don't know... uptime.
This is why they have to work pretty hard to make me switch over to it being my primary bank, and 1600 microservices communicating over the most brittle part of your stack doesn't win them any points in this space.
To put it in context I really can't remember the last time HSBC had a major outage... Sure it's boring but it works pretty much all the time.
Monzo seems more of a "60% of the time it works everytime" situation, great to send your mates money but I wouldn’t trust it to pay my rent on time. Having 1600 microservices kind of explains this.
If there’s anyone at Monzo listening, please focus on not going down as everything else you do is great.