Makes sense really.
Only needs to work once for him to get a passive payoff. Sitting in your lane usually doesn't buy you that.
2,306 karma · joined December 16, 2012
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.
My app is fairly simple node process with some side car worker processes. k8s enables me to deploy it 30 times for 30 PRs, trivially, in a standard way, with standard cleanup.
Can I do that without k8s? Yes. To the same standard with the same amount of effort? Probably not. Here, I'd argue the k8s APIs and interfaces are better than trying to do this on AWS ( or your preferred cloud provider ).
Where things get complicated is k8s itself is borderline cloud provider software. So teams who were previously good using a managed service are now owning more of the stack, and these random devops heros aren't necessarily making good decisions everywhere.
So you really have three obvious use cases:
a) You're doing something interesting with the k8s APIs, that aren't easy to do on a cloud provider. Essentially, you're a power user. b) You want a cloud abstraction layer because you're multi-cloud or you want a lock-in bargaining chip. c) You want cloud semantics without being on a cloud provider.
However, if you're a single developer with a single machine, or a very small team and you're happy working through contended static environments, you can pretty much just put a process on a box and call it done. k8s is overkill here, though not as much as people claim until the devops heros start their work.