What DevOps Is and Why You Should Learn It Alongside AWS

In this series we'll learn DevOps by working directly on AWS. Before getting started, this article explains what DevOps is and why we learn it together with AWS.

If you search for "what is DevOps", you'll run into a lot of fairly abstract definitions: "a culture", "the combination of Development and Operations". They're not wrong, but they're hard to picture, so instead of defining DevOps we'll look at the problem it solves.

The problem DevOps solves

It used to be that getting an application from a developer's machine onto a server was split between two teams:

1. The Development (Dev) team wrote the code.
2. The Operations (Ops) team handled running that code on servers.

The two teams had different goals. Dev was measured by the number of features shipped, so it wanted to release often. Ops was on the hook when the system broke, so it wanted to change as little as possible. Because they worked separately, each handoff to production tended to cause trouble.

A common one was environment mismatch: the Dev machine had Node 20, the server had Node 16, so the code ran on one and broke on the other. Dev said the code worked fine; Ops only saw it failing on the server; and neither side had enough information to fix it quickly.

DevOps is an approach where these two teams work together — or merge into a single automated process that handles everything from writing code to running it reliably in production.

What work DevOps covers

Skipping the definitions, real-world DevOps work revolves around four main areas. We'll practice all four in the series:

• Packaging the application so it runs the same in every environment. We use Docker for this — packaging both the code and its environment into a container, so it runs the same on the server as it does on your machine.
• Automating how code gets onto the server, called CI/CD. Instead of copying files by hand, we set up a pipeline: push code to Git and the machine builds, tests, and deploys it automatically.
• Managing infrastructure as code (Infrastructure as Code). Instead of clicking through a UI to create a server, you describe the infrastructure in a file. Need to rebuild it identically? Run the file again.
• Monitoring. Watch how the running system is doing, and get alerted when something looks off before users complain.

Why AWS

All of the above needs somewhere to run: servers, network, a database, a place to store files. You can buy your own machines on-premise, or rent from a cloud provider.

For learning, renting from the cloud is more convenient because you don't have to invest in buying servers. You rent a server by the hour, give it back when you're done, and the cost is tiny. Set it up wrong? Delete it and start over.

Among cloud providers, we choose AWS (Amazon Web Services) for a few reasons:

• AWS is the most popular provider today, so when you hit an error and go looking for docs, almost always someone has hit and solved that problem before you.
• Job postings mention AWS more than other platforms.
• AWS has a Free Tier for new accounts. Right now (for accounts created after 2025-07-15), you get 100 USD in credit when you sign up and can earn up to 100 USD more, enough to do nearly the whole series for almost no real money. We configure cost controls in Article 1.

The concepts are fairly similar across providers. Get a solid grip on AWS's EC2 and when you move to Google's Compute Engine, you mostly just need to get used to new names and a new UI.

Cost and the cleanup habit

AWS charges by usage. For beginners, the common risk is spinning up a resource to try it, finishing the lesson, forgetting to turn it off — and it keeps running and billing. At the end of the month you get an invoice for something you used for a few minutes.

To avoid this, the series is organized around a principle: whatever resource you create, clean it up when you're done. From Article 2 onward, each article starts with a cost estimate and ends with a cleanup checklist. In Article 1 specifically, before creating anything that costs money, we set up a billing alert to get notified if costs exceed a threshold.

The series roadmap

The articles are ordered the way they should be learned:

1. Open an AWS account safely — create the account, enable MFA, stop using the root account, install the AWS CLI, configure a billing alert.
2. EC2 — create your first virtual server, SSH into it, run a web server.
3. VPC & Security Group — basic networking and firewall, to control who can reach the server.
4. S3 — store files and host a static site.
5. RDS — run an AWS-managed PostgreSQL database.
6. Docker & ECR — package the application and push the image to AWS's registry.
7. CI/CD with GitHub Actions — pushing code deploys automatically.
8. CloudWatch — view logs and set alerts when something looks off.
9. Wrap-up & account review — a final check so no resource gets left behind, plus suggestions for what to learn next.

The effective way to learn is to read and do at the same time; reading alone is hard to retain. You don't need prior AWS knowledge, but you should be comfortable with the command line (open a terminal, type commands) and know basic Git (commit, push), since Article 7 will use it.

What you'll need

• A computer (Windows, macOS, or Linux all work) with a terminal.
• A Visa/Mastercard to sign up for AWS. Even on the Free Tier, AWS still requires a card for verification; we'll set up an alert to keep costs in check.
• A GitHub account, used from Article 7.
• About 30–60 minutes per article.

By the end of this article you don't need to do anything yet. In Article 1 we'll open an AWS account the right way — an important step, because many of the security mistakes beginners make start right at sign-up.