Storage, compute and networking: what can you take separately?

You forwarded a request about your team’s scheduling tool not long ago: a colleague could not get in (part 2 of this series covered those two doors, who gets in and what they are then allowed to do). That scheduling tool is one resource, one application with its own name. Today, one layer deeper: what does a resource consist of, and what can you take out of it separately?

IT mentions storage, compute and networking in the same breath, and you nod, while you could not explain a single one of the three. Three kinds of blocks, and two of them you can take on their own.

What the three blocks are

Storage is the place where data stays put, with its own address, even when nothing is computing against it. Compute is the processing power that does something with that data the moment someone or something asks for it. Networking is the address space a solution is reachable through, for you and for other solutions. These are kinds of services, with plenty of products underneath, so you learn them by what they do rather than by what they are called in a portal. Which leaves one question that the rest of this article answers: can a block stand on its own?

What you can take separately

Storage and networking can. Take the scheduling tool’s monthly exports: they need to be kept for the audit, so you ask IT for a place with its own address. That place gets created, nothing computes against it, and you just drop files in and pull them out. That is the whole job, and the block exists fine without anything ever happening to it beyond storing and retrieving.

Networking works the same way. Your department is getting a second tool next quarter alongside the scheduling tool, and you can request the address space it will be reachable through right now. It sits there empty, ready for what still has to arrive. That an address space can exist before whatever runs through it does is exactly why this block can be ordered on its own.

What never comes alone

Compute cannot do this. Ask for processing power for that scheduling tool, and two things arrive that you did not order: exactly one place for the operating system, and at least one connection into an address space. Processing power cannot store itself and cannot be reachable by itself, so those other two blocks always come with it.

That holds even in the lightest form of compute there is, where you no longer point at a device. Even there, you assign a place for data when it is created, and remove that place and the whole thing stops. The three blocks are never fully separate from each other, compute just always drags the other two along.

Pointing at the block before you forward it

Which of the three blocks does the request you are about to forward actually concern? That is what I would want to know before it lands with IT. Is this about data that needs to sit somewhere, something that needs to compute, or about being reachable? Often it is two of the three, and that, to me, is the point: you rarely order one block, you order a combination.

These three words say what a solution is made of, not who gets into it, and that was part 2. What you then see inside that solution, and what it costs, are different questions again, and the bill is the subject of the next part of this series.

Running into three words that keep coming up but never get explained? I’m happy to think it through with you, see trainerbjorn.nl.