About this article
Thank you for visiting the site. This article is part 2 of the “IT Fundamentals” primers in the Architecture Crash Course for the Generative-AI Era series, and it covers servers and the cloud.
Last time I described a web service as “a division of labour between the customer ordering and the shop answering”. This time I go a level deeper into “the shop side”, that is, the server. Where servers are, who looks after them, and why “renting” became the norm. Once that clicks, the words cloud and AWS that pepper the main series suddenly feel familiar.
If you have not read the previous article, starting there will make this one flow better.
The point of this article
- A server is "a high-performance computer for a business that trades 24 hours a day"
- These days you rent servers from the cloud rather than buying them
- Renting comes in tiers, sorted by how much you still manage yourself
What a server actually is
Roughly, a server is “a computer that receives requests and answers them”.
The important thing here is that a server is not some magic box: inside, it is the same kind of computer as the one you are using. It has a CPU, memory, somewhere to store data. What differs is the job. A personal PC is “a computer that works for you”; a server is “a computer that works for a crowd”.
Technically you could in fact turn your home PC into a server. So why do companies bother with dedicated ones?
Why your own PC will not do
The reasons are easiest to see as a trading business.
First, a shop has to stay open every hour of every day. Web services get traffic at three in the morning and from other continents, so “the service stops when I shut my laptop” is not a business. Power cuts and connection failures need covering too.
Second, you need the capacity to serve a crowd at once. A home PC is specified for one person; a popular service gets thousands or tens of thousands of simultaneous visitors. A domestic dining table with four chairs cannot take a coach party of a hundred.
Third, the damage when it breaks is on a different scale. If your PC dies, you are inconvenienced. If a server dies, every user of the service is. So components are duplicated, and hardware is made swappable in minutes — a level of preparation domestic equipment never has.
Data centres
To meet those demands, servers live in purpose-built facilities called data centres.
A data centre is a building for keeping large numbers of servers running safely. Computers are packed into racks, with heavy-duty power, backup generators for outages, powerful cooling to carry the heat away, and strict access control. The physical reality of every web service in the world is a computer somewhere inside a building like that.
You never think about it, but while you are watching a video or shopping you are talking to a computer in a data centre somewhere. I find that slightly delightful.
Own it or rent it: on-premises and cloud
Now the main question. There are broadly two ways for a company to get a server.
One is “buy it and put it in your own building”, which is called on-premises (on-prem). In restaurant terms, buying land and putting up your own building. You get to do everything exactly as you like, but it takes time and money to build, and you maintain all of it.
The other is “rent”, and that is the cloud. The reality behind the cloud is that companies running data centres at enormous scale — Amazon, Google, Microsoft — rent out as much of the computing inside them as you need. Taking a unit and trading from it.
What is good about renting? It is overwhelmingly faster to start: putting up a building takes years, whereas a cloud server is usable minutes after you sign up. It also scales up and down freely — move to a bigger unit as customers arrive, shrink and cut the rent when they leave. And building maintenance is the landlord’s job, so you can concentrate on trading.
For those reasons, new services are now almost always built on the cloud. AWS (Amazon Web Services), which the main series mentions constantly, is the largest provider. Google’s GCP and Microsoft’s Azure are the other two, and between them the three cover most of the world.
Renting comes in tiers: IaaS, PaaS, SaaS
There are tiers to how much you rent. It is a recurring idea in the main series, so let me pin it down with the property analogy.
IaaS is renting the empty unit. The room (the computer) is provided, but the fit-out — configuring the OS, installing software — is all yours. Maximum freedom, maximum effort.
PaaS is renting a unit with the kitchen already in. You bring only your recipes (your program), so developers can concentrate on writing it.
SaaS is being a customer of a shop that already exists. Gmail, Slack: you build nothing and just use the service.
Read the main series and you will keep meeting the phrase “lean on managed services”. That is simply “pick a tier where you do less (further toward PaaS) and spend the freed-up time on the business itself”. With that instinct in place, the infrastructure discussions get far easier to follow.
Common misconceptions about servers and the cloud
A few misunderstandings beginners tend to carry. I hear all of these regularly.
First, “cloud means the data is somewhere up in the sky”. The name does not help, but as you have now read, the reality is physical computers sitting in a data centre on the ground. A service aimed at Japan is usually running in Tokyo or Osaka. Not so much a cloud as a nearby industrial estate.
Second, “the cloud is always cheaper”. It is certainly cheap to start, but cloud billing is fundamentally metered by usage, so misuse sends the invoice through the roof. Leaving a server running that nobody uses is the equivalent of going out with all the lights on, and it happens all the time. That is why the main series has an entire article on cost management.
Third, “use a big provider and it will never go down”. Unfortunately even AWS has outages. So the series keeps returning to “being able to keep trading when things break” (redundancy) rather than assuming nothing will. Two branches, so one power cut does not close the business.
One more. “One server means one physical computer” is not necessarily true. Virtualisation makes it routine to divide one powerful computer so that it behaves like several, the way a large building is partitioned between tenants. The “one server” you rent from a cloud is usually one such partition.
Mapping to the terms used in the main series
Here is the property analogy against the vocabulary the main series actually uses. Come back and substitute when something stops making sense.
| This article’s analogy | Term in the main series | Meaning |
|---|---|---|
| The building or unit | Server, EC2, virtual machine | The computer your service runs on |
| Buying land and building | On-premises | Owning your own servers |
| Taking a unit | Cloud (AWS / GCP / Azure) | Renting only what you need |
| Which town to rent in | Region | Which group of data centres you use |
| Move to a bigger unit | Scale up / scale out | Adding performance or machines |
| A managed building | Managed service | Letting the provider handle the upkeep |
| Having two branches | Redundancy, multi-AZ | Staying open when one side breaks |
Incidentally “region”, which appears in every cloud article, really just means “which town do we rent in”. Rent near your customers — Tokyo for a Japanese audience — and the round trip between order and reply gets shorter.
How this connects to the main series
Servers and the cloud are handled mainly in the “System Architecture” category. Which cloud, which tier, how to control the bill — all of it is an extension of this article’s “choosing a property”.
Related articles
Summary
This article covered servers and the cloud through the analogy of renting commercial property.
A server is the business’s computer for trading around the clock, and the modern default is renting data-centre capacity as cloud. Renting comes in tiers, from the empty unit (IaaS) through the fitted-out one (PaaS) to a finished shop (SaaS). With those three points, the infrastructure parts of the main series are followable.
The next primer covers the store room: “database basics”.
Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book
I hope you’ll read the next article as well.
Also popular with readers
📚 Series: Architecture Crash Course for the Generative-AI Era (5/95)