As a public cloud engineer, it feels like this is a mistake to cut deeply right when cloud repatriation is starting to be a thing.
Also, VMWare has A LOT of fat to trim. I've worked closely with teams and alumni of Broadcom/Avago, VMWare, CA Technologies, and Symantec, and honestly, the cuts Broadcom does are pretty reasonable.
Oh, VMware is the 2nd shortest job in my career, primarily for that reason.
I don't want to say much in a public forum, but my best lesson from working at VMware is how to sniff out an incompetent engineer early in a job interview: I just ask coding questions that a VMWare engineer would get wrong.
For example:
I have an engineer write some very basic manual SQL data mapping code. If the candidate really pushes back, or just can't figure it out, I move on.
I ask a question where the engineer should use an enum instead of a string. If the engineer uses an enum, I move on.
Also, a lot of their early management feel like one hit wonders in my experience working with them.
It reminds me of how PANW was before Arora joined and cleaned house, and Symantec/CA before Broadcom cleaned house.
And many of those one hits were ideas crafted and handed to them for implementation (still valuable and important), but left to distill ideas on their own? Not so much.
I’m confused by this. You’re saying you move on if the engineer uses an enum as you would expect?
Do people usually have the SQL language so well memorized that they can pull it out of their head on command? I swear to god I'm not the only engineer who regularly goes to the cheat sheet.
If you're hiring for a SQL developer I guess it makes sense, buit I use SQL about once every 6-12 months or so, so if you hit me with SQL queries on the spot I'll fail your interview for sure.
Honestly, I find interviews that revolve around memorizing and regurgitating some programing language syntax trivia a bit shit.
Wouldn't it be better testing for critical thinking and problem solving skills instead of shit people google anyway?
If I were interviewing for database/SQL work, I'd be personally probing around understanding of the relational data model, not specifics of SQL syntax. How would you model this table? What's a join? What's normalization? What's wrong, conceptually, with the following schema? etc
I think the key insight for you here is that there are many jobs where the only technical skill used is SQL. You probably should know this stuff like the back of your hand for such roles. Old, slow moving, large companies have many people doing this sort of work.
Contrast with a generic "developer" at some startup who uses SQL as only one part of much larger and more complex applications.
As a "developer" you have to deal with so much obscure syntax in your life (actual programming languages, shells, dockerfiles, kubernetes yaml, helm, god knows how many 3rd party APIs, ci/cd definitions, other rando DSLs...) that you won't be able to keep everything in working memory.
But I think that supports the GPs point. At big companies you are more specialized, which means if you get hired into the database dev team you better know SQL really well, cause the non-database devs won't even get access to it and instead depend on you.
I don't expect everyone to have everything memorized or get it right on the first try, but if you don't even know what questions to ask or what resources to confer with, I'm usually concerned if the candidate will be a good fit. The candidate can't be expected to instantly warp to the solution but they need to show they can begin to find the path.
- DDL: create, drop, alter, truncate
- DML: insert, update, delete, call, explain, lock
- TCL: commit, savepoint, rollback
- DQL: select
- DCL: grant, revoke
If you've used them before, you'll have a good enough intuition to understand what each does and when to bring them out of the toolbox. Some database engines have extended versions of these or other ways to achieve the same result, but the underlying concepts are the same.
From there, you should be able to create a basic SELECT statement, and understand the basic flags:
- FROM
- WHERE
- GROUP BY
- HAVING
- ORDER BY
- LIMIT
Then understand joins and how this is all just relational calculus/algebra with sets.
Honestly, I couldn't list these off the top of my head, but I know what each one does when I see them, and I'll instinctively reach for them when I'm writing SQL. But once you know all of this, you know 80% of the SQL you will ever need, and won't have to reach for an ORM. It only takes one weekend to grok SQL, but it will serve you for the rest of your career.
Can't agree on that. If I don't use a language or certain concepts I learned more than 6-12 months, I forget it. Groking something in one weekend that you won't immediately put to use then it gets immediately flushed by the garbage collector. At least for me.
It's like asking a chef to make a hamburger, and telling them how to turn on the grill and where the ingredients are. Either they can do it, or they can't; but you can learn a lot about them by watching them do it.
Abacus, slide rule, grid paper, mechanical pencil, or gtfo!
IT is data librarian work. I compute with raw materials of reality, not 1970s semantic babble. Software as an industry has a lot of fat to cut.
…The argument can work from various contexts. Not the flex you think it is.
The project I was on at VMware failed because the developers refused to learn how to use a database and just threw an ORM at it.
So I would write on the whiteboard a skeleton method that had a SQL query, explain a simple data reader API, and have them fill it in.
The good candidates got it fast, and then we'd discuss various error conditions and how to handle them.
The bad candidates would get stuck, whine that I didn't allow an ORM, or hallucinate that they could answer with an ORM: IE, the question did it's job.
Layoffs seem pretty bad at identifying the incompetent from the competent from my experience. It seems to cut on all front, you're not sure if you're left with the best or the worse ones, but you saved a lot of payroll cost either way.
Or if you try to handicap teams by understaffing them, even competent engineers will need to reduce the quality of their output. This is when fat is trimmed in a bad way, where instead of getting rid of low ROI venture/projects/services/products and focus on the important, you just tighten the budgets accross the board for example.
This is probably what's going to happen. Companies like Broadcom and PANW want pretty high margins on their product lines, so they're pretty mercenary in getting it done.
If you got an offer letter, you should probably survive if you can justify your value over the next few months (in my experience w/ M&A)
Look at Zscaler and Crowdstrike for examples - both follow this strategy.
As a business, you optimize for Net Revenue after Cost of Operation. It's always good to drop customers if it costs more to support them than the revenue you get.
Not really. Most of those companies have lax Cloud Cost Management hygiene and/or the Cloud Platform team is separate from the Infra/Servers team.
If you are F250 you can probably negotiate a nice discount if you are able to fully migrate to a single cloud, but most companies don't want to keep all their eggs in a single basket. This means larger organizations cannot avail competitive discounts on public cloud.
By bundling Private Cloud (VMWare ESXi), Network Security (VMWare NSX), APM (CA Wiley), Endpoint Protection (Symantec Enterprise), and Data Security (Symantec Enterprise) I can purchase 5 critical pieces of Enterprise Infrastructure using a single PO. This is critical at large organizations as any PO above $30k almost always requires CFO or Comptroller approval, and a single PO to Broadcom satisfies your Infra, DevOps, and Security needs (which are all cost centers if you aren't a tech company).
Btw, Broadcom themselves is almost entirely on GCP [0]. Almost all their infra and products are served using a GCP stack on the backend.
[0] - https://www.broadcom.com/blog/broadcoms-transformation-journ...
Edit: Also, I didn't realize I'm replying to an actual legend in the systems/networking space. I read some of your papers when I was an undergrad and later as an early career SWE.
Ended up doing a small on-prem solution. VMWare for 6 CPUs x 32 cores = 192 cores runs about $3K/year for the software side which is a good deal to get started. That leaves about $240K/year or so to cover other costs. Not a slam dunk necessarily, but the on-prem store with vmware is not unreasonable.
If it's greenfield I'd agree. There's a reason why most companies founded after 2008 have a heavy public cloud presence.
The issue is if you are a large brownfield deployment (like most F1000s), a "Cloud Transformation" takes forever and is costly.
It can be done - for example Capital One and Broadcom - but it requires executive buy-in to respect engineering leadership and build a solid DevOps/Platform team.
I know if I was to found my own company tomorrow, I'd be entire cloud first because of velocity and ease of scalability, but you can't expect a company like UnitedHealth Group to transition to an entirely cloud first environment within a 2-3 year timeframe as even a minor outage represents millions of dollars lost a minute and litigation.
Over the next 10-15 years we'll see a large number of non-tech first companies becoming multi-cloud, but in 2023, it's still work in progress.
I agree
> effectively unlimited hc and budget
I disagree.
A company like Google or FB can build in-house tooling simply because they have entire dedicated teams of engineers to manage their environments in house to meet niche needs. A F10 like ExxonMobil or UnitedHealth cannot justify a FB size engineering footprint when their margins are much lower.
> find a competitive alternative platform to ESX
Yep. The issue is ESX is actually pretty good at getting the job done. Your alternatives from a supportability standpoint are HyperV from Microsoft (which will probably eat up the smaller ESX customers), Citrix Hypervisor (owned and operated by ex-Broadcom leadership), and IBM RedHat's KVM (which requires you to work with IBM for Professional Services).
At the end of the day, you as a CTO or Platform team don't want to be fully OSS. Not because OSS is crap software (anything but), but because a pure OSS play doesn't provide you a dedicated support engineering team if shit hits the fan nor SLAs and monetary compensation if shit breaks.
This is why most OSS core companies max out revenue via a Professional Services play. RedHat is a notable example of this.
If you are running vpshere and move to proxmox, you are in for major differences.
Billions of have been wasted trying to get rid of the vTax. It has been rarely successful.
The open source will be eventually "good enough" like Postgres is "good enough" over Oracle, but this doesn't stop Oracle from taking in $50 billion every year.
A tech company can justify 30-50% R&D spend, which is where IT/Software falls.
As a non-tech company like ExxonMobil or UnitedHealth this is a much harder ask while being a distraction from other work your IT/SWE team needs to get done.
Time spend managing your custom OSS virtualization stack is time taken away from managing compliance, security posture, networking, data management, etc.
Why re-invent the wheel when it's cheaper to buy?
Don't forget Oracle: https://www.oracle.com/virtualization/
Tbf they target renewals more so than new accounts.
They used to be pretty good at virtualization back in the day
OpenStack is nasty to get up and running (I've ranted a bit about my experiences here on HN) and it's a PITA to get consulting, much less actual staff you can hire, for it... but once it's running, it's extremely impressive. Literal entire large research labs like CERN are no issue for it (CERN runs >300k cores AFAIK).
If you got the compute demand to justify the headcount and initial effort, absolutely go for OpenStack.
Earlier in my career I worked my way up from Linux sysadmin to Enterprise architect and designed a private vSphere/vCAC private cloud (100K+ ESXi hosts, 12PB SAN, US east/west, Canada, EU) for a F15 company and the level of incompetence I saw in tech leadership from the CTO office down was staggering.
Most CTO leadership in the F1000 has determined long ago that kingdom building and protecting headcount is their top priority, so they don't want things to be too efficient. They have to protect their 300 Windows admin HC and 100 Linux admin HC at all costs, so if you give their customers (the line of business unit managers and developers) an API that lets them provision a virtual server in minutes and might automate away the job of 80% of those Windows admins who were doing manual builds, they will slow it down to the point that it is just as slow as the old 6 month long manual provisioning process.
I watched this play out first hand. On my small team we designed a private cloud that could give you a Linux/Windows server in ~20 minutes with as much storage as you wanted, and it was so effective at stealing internal customers that the VPs who managed the server build/run teams made sure to break it apart into their separate storage, compute, and database silos so that the provisioning process got slow again. It still takes them 6 months and a project manager to provision a single server now.
These dinosaurs don't want change. They want to kingdom build and make sure they have hundreds of dead weight server admins so that when they get forced to cut due to budget reductions they won't get cut too deep. They could care less about the bottom line, and the CEO and executive leadership don't know they're being gaslit by their CTO office on down about the "dangers of public cloud."
You can repatriate VMWare VMs from someone else's datacenter to your datacenter. You might even be able to do it with little downtime. (I vaguely remember that VMWare has 0-downtime movement of a VM among physical hardware.)
Only anecdotally - though the stuff I've seen is more about undoing the mistake of letting anyone at the company run-up massive bills on cloud-only big-data-processing (CosmosDB, Data Lake, etc).
The only other "repatriation" movement I've seen are orgs who got burned by limitations and glitches in things like OneDrive/GoogleDrive - again, this doesn't really come under VMware's remit.
One legitimate challenge is that it’s actually rather difficult to measure the TCO of each option. I’ve seen companies pushed to get better at that as they experience cloud sticker shock, and as large enterprise pushes more and more work to the cloud, I’d expect to see them continue to improve in this area.