A city must move its on-prem Kafka and Spark stack to the cloud. What contrast captures the main migration-style choice?
Select an answer to reveal the explanation.
Short Explanation
You can tow the old trailer across the bridge or rebuild on a better chassis. Lift-and-shift keeps VMs mostly as-is; refactoring adopts managed Kafka and Spark services. Both are real choices—pick with eyes open.
Full Explanation
The main migration-style contrast when moving on-prem Kafka and Spark to the cloud is lift-and-shift of largely unchanged VMs versus refactoring onto managed Kafka and Spark services. Lift-and-shift preserves familiar operations with less redesign; refactoring trades migration effort for reduced middleware toil on managed APIs. Cities should choose deliberately based on skills, timeline, risk, and how much undifferentiated heavy lifting they still want to own.
Deleting all historical topics so nothing needs to move avoids migration by destroying analytical history citizens and auditors may still need. Printing every message to paper before cutover is not a cloud migration path for streaming platforms. Replacing streaming with quarterly spreadsheet uploads abandons velocity and mislabels a capability regression as modernization.
Exam caveat: hybrid interim states are common—some topics lift first while others wait for managed refactor—and data validation cutovers matter as much as the style label on the slide. Operational check: for one pilot topic, compare a lift-and-shift consumer lag and ops ticket load against a managed-service refactor of the same topic, and record which risks and skills each path demanded.