I started this week by studying databases. I expected to remember more service names. Instead, I left with a clearer picture of what cloud engineering actually asks me to learn.
A service is only one piece of the decision. The larger skill is learning to move from a real problem to a system, then from that system to evidence that it works.
The map I was missing
A relational database, a key-value store, a cache, a graph database, and a warehouse are not different answers to the same question. They fit different workloads.
The service appears after the workload is clear. It should not be the starting point.
The boundary is ownership
If I run MariaDB on EC2, I get control, but I also own the operating system, patching, backups, scaling, hardening, and recovery. RDS or Aurora moves much of that infrastructure work to AWS. I still own the data, schema, permissions, queries, cost, and application behavior.
Managed does not mean responsibility disappears. It means the boundary moves.
From services to system paths
A cloud system is not a list of products. It is a path. A user request may move through a browser, a public endpoint, a web server, application code, a database, and a response back to the user.
Migration is a sequence
DMS is not a magic copy button. Assess the source and target, convert when needed, review the result, apply the target schema, move the data, and validate the application.
A completed migration task proves something about the task lifecycle. It does not prove that the application still behaves correctly.
The smallest application made the map visible
The WordPress exercise exposed a dependency chain: browser, then EC2, then HTTPD, then PHP, then WordPress, then MariaDB. A page can fail even when HTTPD is installed.
systemctl status proves service-manager state. A local curl proves a local HTTP response. A browser request proves the public path that was actually tested. None of those checks proves persistence, scaling, backup quality, recovery, or production security.
The progress is a change in questions
I am moving from service vocabulary, to workload fit, to ownership boundaries, to system dependencies, to migration paths, and finally to verification.
The next time a database-backed application fails, I want to locate the failure first: engine, credentials, network path, web service, application behavior, or persistence.
The service choice matters. The system around the service matters more. And the evidence that connects the two is where the real learning begins.