I'm sure they're better than this than me, but ipxe & tftp are plain text, so it wouldn't be shocking if something in the bootstrap process was plaintext.
At the very least you need to tell the server what to trust.
2,306 karma · joined December 16, 2012
I'm sure they're better than this than me, but ipxe & tftp are plain text, so it wouldn't be shocking if something in the bootstrap process was plaintext.
At the very least you need to tell the server what to trust.
I've worked across 18 companies, and about 2-3 times I've been given a person to onboard me, once we had a decent central wiki, and the rest of the times I've basically been left figure it out.
I don't even think these things are overly hard to figure out, but very few people in tech straddle the lines between tech and org, and when they do, they're usually kept at bay by the non-technical tech roles ( deliver manager, etc ).
The reality is, a lot of these orgs have likely already discovered devops, pipelines, deployment strategies, observability, and compliance as code.
There's basically little in compliance that can't be automated with patterns and platforms, but in most of these organizations a delivery teams interface with the org is their non-technical delivery manager who folds like a beach chair when they're told no by the random infosec bod who's afraid of automation.
I've cracked this nut a few times though. It requires you be stubborn, talk back, and have the gravitas and understanding to be taken seriously. i.e. yelling that's dumb doesn't work, but asking them for a list of what they'd check, and presenting an automated solution to their group, where they can't just yell no, might.
- Some think I'm no longer technical enough because I've done managerial stuff, despite recent work being hands on.
- Some think I'm not managerial enough because I still do technical stuff.
- Some think I've somehow failed because the specific role was only ~20 months ( it was actually equity shenanigans )
- Some think I'm too senior and won't stick around ( despite the role being top of the market pay wise )
Mostly, I don't really know, because when going through the front door, they typically don't respond, and in actual fact the only leads I get are the ones that contact me.
But I think our specific culture focuses on reasons to say no, rather than reasons to say yes, and the current market only helps compound this, even if the outcome is worse.
Of course, I might just be shit, but they also likely don't know that by not speaking with me. :)
In the UK market folks aren't particularly receptive to that sort of thing.
I'm in the UK. Strong skills. Good CV. Ghosted constantly.
Half the jobs you're applying for ( or more ) are fake, and the recruiters are just trying to collect CVs to drum up future business.
I think comes down to a couple of things:
- Small orgs don't have the resources to run internal clouds, nor should they be doing so. This limits the pipeline of available candidates. - Large orgs promote the wrong people to management, and they make decisions based on their mental model of the world that was developed 20 years ago. They're filled with people who don't understand the difference between cloud and virtualization. - Large consultancies make more money by throwing raw numbers at the problem rather than smart automation. i.e. it's easier for IBM to bill T&M and a whole project wrapper to patch the server than automate it. - Finance & HR teams want you to bend to their ways of working rather than the opposite.
Of the rest, you get into many of them are simply in ops because they're less skilled software developers, or they're now being asked to assure security, and that scares them so they try to lock everything down.
I think a lot of orgs move to cloud simply because it's popular and gartner told them so.
But taking a step away from that, it's really about self-service. When the alternative is logging a ticket for someone to manually misconfigure a VM and then fail to send you the login credentials, then your delivery is slow.
When you're chasing revenue, going slow means you're leaving money on the table. When you're a big bureaucratic org, it means your middle managers can't claim to have delivered a whole bunch of shit. Nobody likes being held up, but that's what infrastructure teams historically do.
Folks that have really strong opinions on issues of taste, but then they output apps that send a couple of thousand requests ( with several second latency ) are extremely difficult to reason with.
What it actually lacks is versioning, and a dynamic secrets engine, though you could build that with an operator, and things like the postgres-operator do.
You also don't get the whole sealing thing, but I'd argue that's more annoying than useful.
But taking a view on markets outside of the US and SV/bigtech in particular, those 10x devs aren't usually getting the 2-3x as much, and taking a view of industry in total, profits are runaway but wages are flat and falling, especially when considering inflation.
Capital is winning. Perhaps unions are required. But I'm not a union member and likely never will be.
That said, loads of folks do microservices with a shared dB.
This will happen even in a small org if your leadership isn't essentially driven motivated, and willing to take action.
At scale, this only becomes more difficult to manage, and the reality appears to be that almost nobody in leadership can actually keep up well enough to stop perf devolving into politics.
Depends on company mission.
Have been a CTO for a SaaS company from £19m -> £75m revenue, but also still a pretty hands on tech ( SRE at the moment )
Location: Norwich, UK
Remote: yep, depends on role
Willing to relocate: yep, 100%. Would love to leave the UK.
Technologies: 15 YOE cloud, Linux, on-prem. Development experience in multiple languages, including but not limited to Golang, TypeScript, Python, PHP, Java.
Résumé/CV: https://downloads.shutthegoatup.com/AllanDegnanCV-2023-07-11.pdf
Email: allan@shutthegoatup.comFlexiscale at the time was a single region backed by a netapp. Each VM essentially had a thin-provisioned lun ( logical volume ), basically you copy on write the underlying OS image.
So when someone accidently deletes vol0, they take out a whopping 6TB of data, that takes a ~20TB to restore because you're rebuilding filesystems from safe mode ( thanks netapp support ). It's fairly monolithic in that sense.
I guess I was 23 at the time, but I'd written the v2 API, orchestrator & scheduling later. It was fairly naive, but filled the criteria of a cloud, i.e. elastic, on-demand, metered usage, despite using a SAN.
I was working for a webhosting company, and someone asked me to rush a change just before leaving. Instead of updating 1500 A records, I updated about 50k. Someone senior managed to turn off the cron though, so what I actually lost was the delta of changes between last backup and my SQL.
I was in the room for this though: https://www.theregister.com/2008/08/28/flexiscale_outage/
Sure, you could leak said CA, but it's only going to leave you in the same position as HTTP.
From an outsiders, it looks like all of FAANG has scaled to the point where delivery, perf and managing the business has become quite cumbersome. This, I suspect is why they're all used the economic climate to cut back, as they largely are unable to see the benefit of the additional hiring.
I have no doubt most of the talent is top tier, but being a strong engineer doesn't deliver profits nor cost savings on it's own.
The main thing for me as a prior exec is HR / the org will control your people cost, but they tend to be significantly more flexible over the compute / vendor costs. I'm not saying you can add an non-forecasted 20% to your headline spend, folks would get upset at that, but if you decide to consolidate all your services into 5 beefy VMs as opposed to 100 smaller ones, nobody cares.
Do that with people though, and folks tend to lose their shit pretty quickly. The problem is this has several outcomes:
- You're getting people with less experience in the "been there, done that" category, which means the work takes longer. - Since they've not yet experience the pros & cons of decisions. It's likely they'll make some decisions that won't pan out. - They'll leave once they've realised they've fucked up and they now have the "been there, done that" badge, so they can take that experience to a market that values their skills. - Result is you end up hiring 2+ folks to do 1 persons job. - Since you falling foul of Brookes law, you're unable to execute, you work with vendors. - They charge astronomical figures; but since they're not a person, the politics of envy don't apply, thus the org may begrudgingly accept it. - You then need more "cheap" resources to do / maintain the integration work.
The problem being your TCO goes through the roof because you're not hiring quality.
Now going back to your point. Besides economics of scale, the SaaS provider is actually deriving pretty stellar profit margins for a wrapper of people and compute. I would argue these economics of scale quickly dissipate when you're also funding sales, marketing, legal, founders, executives & investor concerns, and further when you're now funding your own internal procurement, legal, and SMT to sign off the contracts.
That said, couple of additional points:
- I didn't mention on-prem. My early career was developing an IaaS provider ( 2007 times ). Folks spend a lot of unnecessary money doing on-prem, but it's a fairly large undertaken for a small dev team with a lack of hardware experience. Most folks should start in cloud unless they are strong on-prem already.
- I didn't mean all saas, the focus was on observability. Though anything you need a large number of seats and has an SSO tax should be scrutinised.
:)
Pretty much anything SaaS based is ridiculous. If you can swing self-hosted ( managed but in your account with there's potential for a discussion, but with many products, it's the actual integration work that's the real work.
Don't get me wrong, there's specific "always going to be small" where it likely makes sense.
Observability is hella expensive. Orgs should consider TCO when making such decisions. Paying a few hundred thousands more for the skills to self run could literally chop tens of millions off vendor bills.
I got some decent prospects post Dec 2022, but wasn't actually on the market until Dec where it was just dead, and of the few that do pop up, they money is way down, and the competition is high.
I do recall the gossip protocol presenting problems back then, but now I believe the helm chart just works.
I haven't used it and not sure if it even has a web client, but for the 99c you can use a custom domain according to the ads.
What I would say is the argument isn't false, but the assumptions often are.
You will for example have diminishing returns on the CaC. Spending more will make the number go up usually.
This explains why you wouldn't just spend it all year 1 and refinance.
Finance is indeed more expensive, and black swan events can cause mass churn, this why pulling out costs might sound good on paper, but in reality could potentially screw yourself over.
Indeed the payback of the customer needs to be short enough to validate profit. The longer it is, the more likely one of those black swan events will distrupt lifetime.
But I suspect there's more businesses out there doing this that are discussed here.