Cloud and infrastructure jargon decoded: servers, containers and serverless

“We will move to the cloud.” It is said as if it were a single destination. In fact, the cloud is a way of buying computing, in the way that you buy electricity: you do not own the power station, you pay for what you use. How much of the machinery you manage yourself is the choice that shapes cost, flexibility and risk.

This article decodes the words that surround the cloud, from servers to serverless, so that you can follow a technical proposal and ask sensible questions.

What is a server, really?

• Server. A computer that provides services to others, such as hosting a website or storing files.
• Data centre. A building full of servers, with power, cooling and security.
• On-premise. Servers that an organisation owns and runs in its own premises.
• Cloud. Servers owned by a provider, such as a large technology company, and rented to many customers over the internet.
• Virtual machine (VM). A software-created computer running inside a real one, so that one machine can act as many.
• Hybrid cloud. A mix of on-premise and cloud systems.
• Multi-cloud. Using more than one cloud provider.

The three service layers: IaaS, PaaS and SaaS

A useful analogy is pizza. You can make it entirely at home, buy the ingredients and bake it, order a ready-to-bake one, or just order a finished pizza to your door.

• IaaS (infrastructure as a service). You rent raw computing: servers, storage and networks, and manage the software yourself. Maximum control and responsibility.
• PaaS (platform as a service). The provider runs the servers and the operating system, and you supply the application. Less to manage.
• SaaS (software as a service). You use a finished application over the internet, such as email or a customer system. Least to manage, and least control.

Packaging and running software

• Container. A sealed package holding an application and everything it needs, so that it runs the same on any machine. Docker is the best-known tool.
• Image. The blueprint from which containers are started.
• Kubernetes. A system that starts, stops, scales and heals many containers automatically. Powerful, and complex.
• Microservices. Building an application as many small, separate services that talk to each other, instead of one large block (a monolith).
• Serverless (or functions as a service). You supply small pieces of code, and the provider runs them only when needed, and charges per use. Servers still exist. You just do not manage them.
• Managed service. A ready-made component, such as a database, that the provider operates for you.
• Infrastructure as code. Describing servers and settings in files, so that they can be recreated reliably, and reviewed like software.

Size, speed and spread

• Scaling. Handling more load. Vertical scaling means a bigger machine. Horizontal scaling means more machines.
• Autoscaling. Adding and removing capacity automatically as demand changes.
• Region and availability zone. A region is a geographic area with provider data centres. Zones are separate buildings within it, so that a failure in one does not stop everything.
• Latency. The delay in getting a response. Hosting near your users reduces it.
• CDN. Copies of content placed near users, to make delivery quicker.
• Edge computing. Running some processing close to where data is produced, such as on a device or a local server, to save time and bandwidth.
• Load balancer. Spreads requests among several servers.

Staying up: reliability

• Uptime. The share of time a service works. Each extra “nine” (99.9, 99.99) is much harder and more expensive to deliver.
• SLA. A contract promise about availability, often with refunds as the only remedy.
• Redundancy. Having spare parts, so that a failure does not stop the service.
• Failover. Automatically switching to a spare when something breaks.
• Backup. A copy of data, stored separately. Test that you can restore from it.
• Disaster recovery. The plan and tools to restore service after a major failure.
• RTO and RPO. How long you can be down (recovery time objective), and how much recent data you can afford to lose (recovery point objective).
• Monitoring and alerting. Watching systems, and warning people when something is wrong.

Money: the part that surprises people

• Pay as you go. You pay for what you use. It is flexible, and also unpredictable if usage grows.
• Reserved or committed use. A discount for promising to use a certain amount for a year or more.
• Egress fees. Charges for moving data out of a provider’s network. They can make leaving expensive.
• FinOps. The practice of tracking and managing cloud costs.
• Idle resources. Servers left running with nothing to do, a common source of waste.
• Vendor lock-in. Becoming so tied to one provider’s special services that moving is hard.

Security and responsibility

• Shared responsibility. The provider secures the underlying hardware and facilities. You are responsible for how you configure and use the service.
• Identity and access management (IAM). Controlling who can do what.
• Encryption at rest and in transit. Scrambling data when it is stored and while it moves.
• Data residency and sovereignty. Where data is physically stored, and which country’s laws apply to it.
• Compliance. Meeting required standards and regulations.

A simple example

A mapping organisation wants to publish a web map. Option one: buy a server and run it themselves, which means they handle hardware, updates and failure (on-premise). Option two: rent a virtual machine and install the software (IaaS). Option three: use a platform that hosts the application (PaaS). Option four: use a hosted mapping service (SaaS). Each step hands more work to the provider, at the cost of control and, often, a higher monthly fee. The right answer depends on skills, budget and risk, not on fashion.

Questions to ask about any cloud proposal

• Which layer of the stack will we manage, and which will the provider?
• Where is our data stored, and under whose laws?
• What does it cost at our expected usage, and at ten times that?
• What happens if the provider has an outage, or we want to leave?
• How often are backups taken, and when was a restore last tested?
• Who holds the administrator account?

Frequently asked questions

Is the cloud always cheaper?

No. It can be cheaper for variable or uncertain demand, and more expensive for steady, heavy use. It also saves effort on hardware, which has real value.

Is the cloud secure?

Major providers invest heavily in security, but your configuration is your responsibility. Most breaches come from misconfiguration, not from the provider’s hardware.

Do we need Kubernetes?

Most small projects do not. It solves problems of running many containers at scale. Simpler managed options are often better to start.

What is the difference between a container and a virtual machine?

A virtual machine contains a whole operating system. A container shares the host’s operating system, which makes it lighter and quicker to start.

The cloud is not magic and not a single thing. It is a menu of ways to rent computing, with trade-offs in control, cost and responsibility. With these words, you can read that menu and order sensibly.