Are AWS, Kubernetes, React, and Python the same kind of thing?

Are AWS, Kubernetes, React, and Python the same kind of thing?

No. They are four different kinds of thing that happen to share a line on a resume. Python is a programming language. React is a framework for building the frontend. AWS is a cloud platform where software runs. Kubernetes is a platform too, one that manages running software across many machines.

A skills list prints all four in the same font, separated by commas, as if they were flavors of one thing. They are answers to four different questions: what the code is written in, what shape the product takes, where it runs, and how its many running copies get managed. This lesson is the sorting machine. Once every name goes on a shelf, a fifteen-technology list stops being a wall and becomes a short set of choices, most of them familiar from how an app is put together.

What kinds of thing are there?

Five shelves cover nearly every name you will meet: languages, frameworks and libraries, tools, platforms, and practices.

The first two shelves came up when we covered how much code developers write themselves. A language is what the instructions are written in, and a framework or library is prewritten code in that language. What is new here is the roster. The language shelf holds Python, JavaScript, Java, C#, C++, PHP, Ruby, Go, Rust, Swift, Kotlin, and Dart. TypeScript is JavaScript with extra checks added, so a developer who knows one reads the other.

Two names sit beside the languages without being full languages. HTML describes the structure of a web page, and CSS describes how it looks. They travel with JavaScript as the standard frontend trio.

The framework shelf sorts by which side of the app it serves. React, Angular, Vue, and Svelte build frontends in JavaScript, and Next.js extends React into a fuller framework. Django builds backends in Python, and Rails does the same in Ruby. React Native and Flutter build mobile apps, in JavaScript and Dart. Node.js is a runtime that lets JavaScript run on the backend, which is why one language can appear on both sides of a resume.

The remaining three shelves, tools, platforms, and practices, are the ones nobody explains, and they are where most misreadings happen. The next three sections take them one at a time.

What is a tool, and how is it different from a framework?

A tool is software a developer works in while building. An editor like VS Code or Cursor, a program like Docker that packages an app for shipping, the version control system that stores the code. The tool stays on the developer's side. When the product reaches a customer, no part of the tool goes with it.

A framework is the opposite case. React ships inside the product. Every customer who opens the app is running React code, whether they know it or not. The test for any name is one question: does this run on the customer's side, or only on the developer's desk?

The difference matters for reading experience. Frameworks bind. A product built on React stays on React for years, so framework depth accumulates and framework choices describe the product itself. Tools swap. A developer who has worked in one editor works in another within days, and a team can change tools without touching the product. Depth in a framework tells you about the products someone has built. Breadth in tools tells you they have been building for a while.

What is a platform?

A platform is a place other software runs, together with the services that place provides. The cloud providers are the clearest case: AWS, Azure, and Google Cloud each offer machines, storage, and hundreds of ready-made services, and a team builds its product on top of them.

The word "on" is what defines the shelf. A developer writes in a language, builds with a framework, works in a tool, and builds on a platform. Platform experience is knowledge of a place: which services exist, what each one costs, how they connect, and what breaks when the number of users grows. That knowledge is broad rather than deep in any single language, which is why platform names cluster in infrastructure roles and why a strong AWS resume can show several languages without deep years in any one.

Platforms carry another signature: they are the shelf most likely to appear as certifications. Languages and frameworks rarely certify. AWS, Azure, and Google Cloud all run formal certification programs, so lines like "AWS Certified Solutions Architect" are platform-shelf lines.

What is a practice, and why do people list one as a skill?

A practice is a way of working rather than a product. CI/CD is the common example on resumes: the practice of merging code continuously and shipping it through an automated pipeline. Code review, automated testing, and agile are practices too. There is no CI/CD company and nothing to install called CI/CD. Teams carry the practice out with products, such as GitHub Actions or Jenkins, and different teams pick different ones.

People list practices because they describe the kind of team the person has worked on. A developer who lists CI/CD has worked somewhere that ships continuously through a pipeline, which says something about pace and discipline that no product name captures. Practices also transfer completely. The product carrying the pipeline changes from company to company, and the practice arrives intact on day one.

Where does Kubernetes go?

Kubernetes goes on the platform shelf. It is a system that runs and manages many copies of an application across many machines: starting them, watching them, replacing any copy that fails, and adding copies when traffic grows. Teams write software and hand it to Kubernetes to run, which is the defining move of a platform.

It earns its own section because it resists casual sorting. It sounds like a tool, it usually runs on a cloud platform rather than being one of the big three, and its name gives nothing away. The name is Greek for "helmsman," the person steering a ship, and it is often written K8s, the K and the s with the eight middle letters counted out. On resumes it marks infrastructure work: Kubernetes depth means someone has operated the layer that keeps a product running at scale, which is DevOps and infrastructure territory. It is a large system in its own right, and real depth in it takes years the way language depth does.

How do you sort a real list?

Take a line a resume could actually carry: Python, Django, React, TypeScript, PostgreSQL, AWS, Docker, Kubernetes, CI/CD. Nine names, one pass through the machine.

Python and TypeScript go on the language shelf. Django and React go on the framework shelf, one backend and one frontend, and each pairs with one of those languages. PostgreSQL is a database, which is a layer of its own. AWS and Kubernetes are platforms. Docker is a tool. CI/CD is a practice. Nine names collapse into a readable sentence: this person builds full web products in two languages, stores data in PostgreSQL, and runs the result on AWS with modern shipping habits.

Sorting also sets the rule for comparison. Two names can be weighed against each other only when they share a shelf and a layer. React against Vue is a real comparison, two frontend frameworks doing the same job. React against AWS is a category error, like comparing a candidate's writing to their commute. Most confusion in front of a skills list traces back to comparing across shelves.

One pick per shelf at each layer of the app has a name of its own, a tech stack, and reading stack sentences is the next lesson. The full sorted map of the names, and which skills carry between them, is in the module guide.