* Physical space - The servers themselves require a certain amount of room and depending on the workloads assigned will need different dimensions. These are specified in rack "units" (U) as the height dimension. The width is fixed and depths can vary but are within a standard limit. A rack might have something like 44U of total vertical space and each server can take anywhere from 1-4U generally. Some equipment may even go up to 6U or 8U (or more).
* Power - All rack equipment will require power so there are generally looms or wiring schemes to run all cabling and outlets for all powered devices in the rack. For the most part this can be run on or in the post rails and remains hidden other than the outlet receptacles and mounted power strips. This might also include added battery and power conditioning systems which will eat into your total vertical U budget. Total rack power consumption is a vital figure.
* Cooling - Most rack equipment will require some minimum amount of airflow or temperature range to operate properly. Servers have fans but there will also be a need for airflow within the rack itself and you might have to solve unexpected issues such as temperature gradients from the floor to the ceiling of the rack. Net heat output from workloads is a vital figure.
* Networking - Since most rack equipment will be networked there are standard ways of cabling and patching in networks built into many racks. This will include things such as bays for switches, some of which may eat into the vertical U budget. These devices typically aggregate all rack traffic into a single higher-throughput network backplane that interconnects multiple racks into the broader network topology.
* Storage - Depending on the workloads involved storage may be a major consideration and can require significant space (vertical Us), power, and cooling. You will also need to take into account the bus interconnects between storage devices and servers. This may also be delegated out into a SAN topology similar to a network where you have dedicated switches to connect to external storage networks.
* Give me an option to pay for what I use. I do not want music, 99.9% of live streams, news, or tons of the other content they try to force on me for money-making purposes.
* Make the price reasonable. The videos I watch are primarily educational lectures. This really shouldn't cost much more than the price of disk storage and network egress (both of which are cheap at scale).
* Give me a recommendations and preference system that actually work. I spend more time curating my list of videos than watching anything meaningful to my interests. At one point I was watching 2 luthiery channels and "guitar necks" came up as a category. What the ever living fuck? Related yes, but not quite the topic I really want to focus on. I would remind people that this is a multi-billion dollar company with PhDs that has changed the face of AI and hyper-scale computing as we know it.
* In general, operate like a long-running business... offer good value to your paying customers. Now that the customers are not advertisers, Google will need to rethink their sales strategies. They have not yet convinced me. * Most simple things like a "Person" were multiple tables because you had to include audits and historical changes for each field
* A "Person" wasn't even all that useful because it included guests or other fairly transient entities like vendor contacts so you had an explosion of more tables as you classified roles into "Student", "Faculty", "Employee", etc... (many with histories as above).
* Addresses and other non-core demographic information were usually sharded into all sorts of categories like "primary", "parent's", "last known good", "good for mailing", etc... (more histories, etc...)
* All coded information like label types such as "STUDENT", or "MAILING" were always handled as separate validation tables with strict FK constraints and usually included extra meta information like descriptions and usage notes within parts of the system.
* Each functional sub-system (HR, Payroll, AR, AP, etc.) had its own dedicated schema.
* All external jobs, processes, and external integrations were configured separately.
* All enterprise integrations usually had a whole a dedicated schema for configuration.
* Most parts of the interactive web UI were database driven (Oracle's Apache mod PL/SQL) with many templates and other components stored in large collections of tables.
Because in addition to all the filthy pirated booty I stole, I would also show them this:
I'm never paying for entertainment again. I paid my dues and the industry has done nothing but fuck me and everyone else.
Fuck them. It's over.
Have fun paying to sing "Happy Birthday".