Exercise 1: Migrating Self-Hosted MySQL to a Managed Service — Possible Solution ==================================================================== What changes: The OPERATIONAL layer changes -- who is responsible for patching the database engine, scheduling and managing backups, setting up replication, and handling failover. Per the chapter, this shifts from the organization's own team to the provider, since a managed database sits at the PaaS layer of the IaaS/PaaS/SaaS spectrum (Chapter 1). Some configuration options and specific engine versions or extensions may also become unavailable, since the provider only supports a defined set of configurations for its managed offering. What stays the same: Per the chapter, the database engine itself is UNCHANGED -- RDS/Cloud SQL/Azure SQL run the actual same MySQL engine, not a proprietary replacement. This means: - Every SQL query already written continues to work exactly as before -- SELECT statements, JOINs, subqueries, all of `mysql2`/`mysql3`'s query-writing material (aggregate functions, window functions, CTEs, stored procedures, and so on) applies completely unchanged. - Schema design knowledge (table structure, normalization, indexes) transfers directly -- none of it is specific to how the database is hosted. - Any existing application code that connects to MySQL via a connection string continues to work the same way, typically only needing the connection endpoint updated to point at the new managed instance. WHY THIS WORKS AS AN ANSWER ------------------------------ This directly applies the chapter's own core claim -- "only the operational layer changes... not the query language or schema design underneath" -- and separates it cleanly into two lists (what changes vs. what stays the same) rather than treating the migration as a single undifferentiated change. The key insight is that "migrating to a managed service" and "migrating to a different database" are completely different kinds of changes, and this migration is specifically the former.