2,308 karma · joined December 16, 2012
It's entirly possible that the experiment fails because of politics, but it's also possible that the amount of politics is simply lower because people are simply more reasonable.
The last part will come down to vested interest and ideologues.
Only needs to work once for him to get a passive payoff. Sitting in your lane usually doesn't buy you that.
I guess my question there is, is DHH ignorant to who Tommy really is, or is it a full endorsement.
It's a fact in British politics we refuse to publish crime stats per ethnicity, but the Danes do, and it's fairly obvious that certain types of immigration aren't good for your society.
Of course, these are cultural problems usually linked to specific regions and socioeconomic backgrounds rather than actually race related, but we've been in a weird space for many years where it's racist to discuss the problems, and ergo when you do find people willing to discuss them, they do tend to be actually racist.
Which makes it hard to jump to defend DHH here, because you're unsure what you're missing. The sad thing is, the denial drives actual racism, because it's the only outlet to actually discuss the problems.
For those not aware, British population growth is about 10m in 20 years, largely immigration ( Births are below replacement rate ) and largely pushed to depress wages and expand the tax base to fund pensioners. There's also a lack of investment in services, we can no longer easily find a GP, Dentist, School spots, and house prices have become unreachable. It's more class warfare than race related.
However, it doesn't need to be exclusively negative. The data will both show where you can price gouge but also simply where demand is.
Put your coffee shop near a metro stop and sell sourdough bread and people will buy that because they want it isn't exactly negative.
Way back when, you'd see a lot of people stuff their jenkins in their dev account. There's no way that the system that builds, publishes and deploys your application should be treated as anything but as sensitive as the production system itself.
( To be fair there are mitigations such as reproducible builds, but you're now doing a bunch of engineering to tie in your deploy system. )
You can decide whether that was better or worse.
Internal hosting teams ( cloud or on-prem ) should work more like public hosting environments and should focus on:
- Segregating workloads. If amazon can host a hacked service on their hosting stack without every tenant immediately being compromised, you can too.
- Self-Service. Teams should be able to just get accounts and do stuff without asking anyone.
- Building assurance. Now you've made it easy for teams to do small things, you're more likely to get more users and have less shadow-IT. You can now try and build organizational assurance without making teams suffer.
A team just needs petty cash and a cost code for a small amount of space in dev land.
What everyone does instead if ask for the planning to be done and completed upfront, which isn't realistic for a team you just stood up trying to do UR and a POC.
With a cloud provider, you can get an account by filling out a sign-up page and handing over a credit card. Internal teams will often hide behind Bureaucracy and a ticket system, with processes that make hosting a simple web app take multiple quarters.
Now there are layered reasons for that, some of them with legitimate basis, but at the end of the day they're usually low skilled teams click-ops-ing some VMWware, delivering a terrible service.
Most places I land there's deference to the status quo and those that came before. People assume that efforts of that past were well considered and that good work was done.
But ultimately when pressed, there's generally no evidence of the above, and when there is evidence, one can generally demonstrate the flaws in the approach, so I press on anyway and it hasn't really bitten me yet.
Of course, in many of these projects there's now deference to decisions I've made. Some of those decisions were well made, with evidence and supporting work, to make them challengeable should the understanding changes. Some of them are gut checks because they didn't matter to me at the time.
Either way the take away is good, but often practices exist simply to frustrate.
I think there's 3 big themes with this, thought not
1. LLM tools have added considerable load.
2. LLM used by developers to increase velocity seem to be leading more outages. This calls into question the increased velocity.
3. Roadmaps focused on pushing features that aren't reliability problems. i.e. github moving to azure, or adding AI features.
All these same problems happen to orgs with other fads that aren't AI. Following fads is not good engineering.
I thought it was a simple 2 dims are probably better than 4, but unsure how you'd ever land on 48?
You were talking about a team of 5 cranking this out in about 2-3 months with some longer term part time involvement, with an annual cost of less than 1m and those people mostly all dellivering several product lines ( so actual cost is half or a quater ).
Our old jenkins hosts were largely forever instances with forever credentials that were just waiting to take down the org.
Modern pipelines are orchestrates that run ephemeral execution environments with ephemeral credentials that can significantly decrease the impact and timescales of getting pwned.
They're not perfect, but you can get pretty good posture by applying expertise to the subject. The problem, like always, is this expertise is neither valued nor rewarded.
Indeed, this could mitigate an attacker replacing the binary with something that's not produced from the code, but it does not mitigate the tool chain or code itself containing the exploit, creating a malicious binary.
But the point was it was in a comparble situations without the microservices / k8s / whatever pet tech you want to hate on.
It really confuses me how someone can argue for cloud providers over a decent open solution without realising their argument is simply they don't want to be managing the thing.
And that's fine, most teams shouldn't be neck deep in managing a platform. But that doesn't make the solution bad.
Point being, it's not the tools the causes the probem.
The deployment files / structure were mostly equivalent with the main differences being I can't shell into ECS and I lose kubectl in favour of looking at the AWS GUI ( which for me is a loss, for others maybe not ).
The main difference is k8s has a lot of optionality, and folks get analysis paralysis with all the potential there. You quickly hit this in k8s when you have to actually need the addon to get cloudwatch logs.
This is also where k8s has sharp edges. Since amazon takes care of the rest of the infrastructure for you in ECS, you don't really need to worry about contention and starving node resources resulting in killing your logging daemon, which you could technically do in k8s.
However, you'll note that this is a vendor choice. EKS Auto Mode does away with most of the addons you need to run yourself, simplifying k8s, moving it significantly closer to a vendor supported solution.