IT Literacy for Non-Developers #3: Servers, the Cloud, and Deployment

IT Knowledge
6 min read

In the last two posts, we looked at the backend and the API, the parts a user never sees. But one question remains. Where on earth do the backend and API actually run? Even when a developer’s laptop is switched off, we can open the app at three in the morning and place an order. That means the program must be running somewhere else, all the time.

That place is the server. And the act of putting a developer’s code onto that server to make it available to users is called deployment. Phrases like “the server is down,” “we’re deploying right now,” or “it’s live in production” are all about this. In this post, we’ll unpack three words in turn: server, cloud, and deployment.

This series, IT Literacy for Non-Developers, consists of five parts.

  • #1 What Is a Website Made Of? — Frontend, Backend, and Database
  • #2 What Is an API? — The Promise That Lets Services Talk to Each Other
  • #3 Servers, the Cloud, and Deployment ← this post
  • #4 Bugs, Hotfixes, and Rollbacks — How Developers Respond to Incidents
  • #5 Git and Version Control — How Many People Edit One Codebase

A Server Is a Computer That’s Always On #

The word “server” sounds grand, but at its core it’s a computer. It’s the same kind of computer as the laptop or desktop we use, just with a different role. A server is a computer dedicated to receiving and handling requests from other computers. The name “server” itself means “the side that serves.”

The backend program we saw in the last post runs on exactly this server. When a user’s app sends a request through an API, the backend running on the server receives that request, handles it, and responds. For users to send requests no matter where in the world they are, whether it’s the dead of night or the middle of the day, the server has to stay awake and keep running.

This is where the difference from a laptop becomes clear. My laptop shuts off when I close it, and only one person - me - uses it at a time. A server, on the other hand, has to stay on 24 hours a day and take in requests from thousands or tens of thousands of people at once. So a computer set up to stay on and withstand heavy traffic is what we call a server.

The Cloud Is Renting That Server Instead of Buying It #

So who provides this server? In the past, companies bought server computers themselves, kept them in a server room, and managed them. But these days most teams use the cloud. The cloud is a way of renting computers in a massive data center as needed, and paying only for what you use.

If you buy a server yourself, you have to invest in expensive equipment up front and take on the burden of failures and maintenance too. With the cloud, you can spin up a server in minutes, add more when users surge, and scale down when things are quiet. That’s why the backend of many services today runs on servers rented from the cloud.

If you want to understand what the cloud is in more detail, I recommend reading The Cloud Is Just Renting Someone Else’s Computer first. In this post, we’ll keep it at the level of “the backend runs on a server rented from the cloud.”

Deployment Is Putting Your Code on a Server to Make It Public #

Now let’s talk about deployment. Developers usually write and test code on their own computers. But if that code stays only on a developer’s computer, users can’t use it. You have to put the code you’ve made onto the server that users connect to, so that it actually runs. This process is called deployment.

When you build a new feature or fix a bug, the change reaches users only once the developer deploys it. “I’ve finished building this feature” and “this feature is deployed” are two different statements. If it’s only been built and not deployed, nothing has changed yet on the user’s screen.

That’s why, in development, teams keep their environments separate. There’s a development environment where developers test freely, and a separate production environment that real users work in. The production environment is also called production. New code is usually checked thoroughly in the development environment first, then deployed to the production environment. The phrase “it’s live in production” means the change has reached real users.

How Real-World Conversations Make Sense Now #

A few familiar phrases should sound different now.

  • “The server is down” means something went wrong with the server the backend was running on, and it can’t process requests. When this happens, the screen freezes too or throws an error.
  • “We’re deploying right now” means the work of putting new code onto the server is in progress. The service can be unstable for the brief moment of deployment, so these days teams often use methods that deploy seamlessly, without users noticing.
  • “It works in development but not in production” is a problem that comes from the difference between the development environment and the production environment. It happens often because the two environments aren’t identical.

Why Knowing This Makes a Non-Developer’s Job Easier #

Once you understand servers and deployment, you gain an eye for reading schedules and situations.

  • You can estimate the answer to “when will it go live?” Even after a feature is fully built, the step of deployment remains, and getting it safely into production takes time to verify. You come to understand the gap between “it’s built” and “it’s gone out to users.”
  • You can read incidents calmly. Once you can tell whether it’s a “server problem” or “because of the deployment just now,” you can better gauge the situation and how long it might take.
  • You develop a sense of cost. A server racks up cloud charges for as long as it stays on. As users grow, you have to add more servers, so the cost grows along with them.

Wrap-Up #

In this post, we looked at where the backend actually runs.

  • A server is a computer that stays on at all times to receive and handle user requests.
  • The cloud is a way of renting that server instead of buying it yourself.
  • Deployment is putting a developer’s code onto a server to make it public to real users.

But what happens if the code you deployed has a problem? The moment a bad change goes out to the production environment and affects users, the development team has to respond quickly. In the next post, we’ll look at what bugs, hotfixes, and rollbacks are, and how developers respond to incidents.

X