In migration to cloud, you're always starting with data and processing in a data center. So, obviously that's the source of truth, and the cloud version is just a copy. But as you go through the migration plan, what happens to the truth? Eventually, you want the cloud version to be either equal and related to the data center version or more likely to replace it and allow the data center resources to be repurposed. Where is the source of truth? And when does that change? Often and ambiguous technical situation like which data storage service to select or which compute platform to choose is easily resolved if you think about it in practical terms and go beyond theory. Look for practical clues in the case question not just technical clues. We often talk about implementing complete solutions in the cloud. That certainly simplifies the design, but realistically there often elements that cannot be migrated from the data center. What resources will remain on-prem? What processes are necessary to integrate with existing systems in the cloud in GCP or in other clouds and in the data center? How do you prove to yourself that the solution will work and isn't just a good theory? Do you need to run a proof of concept? If you're moving something from a design for efficiency, for cost reduction, consider the consequences at all the layers. For example, if you reduce capacity of a solution because there are fewer users, would also reduce or remove the availability or disaster recovery features. After a solution is designed and implemented, it goes through a period of stabilization prior to the completion of delivery and hand-off. What do you need to include in the design to stabilize the solutions? What could change or what might need to be measured and adjusted? In some cases. There may be multiple stakeholders. The best solution will solve for all interests or for the common interest. For example, a CEO wants to improve data analytics, the CTO wants lower cost. At first the two interests might seem in conflict, however, moving to a different more efficient solution may solve both requirements. There's an old saying in IT, "Every 10 X in growth, something breaks." This is because the assumptions that went into the original design are no longer true. Quite often scaling up changes the nature of the problem and requires revisiting assumptions. So, in exam questions if you notice rapid growth or other indicators of large-scale change, start thinking about what might have broken or what might be ready to break. What processes will you need to define, to keep the solution operating? Monitoring, logging, metrics, to manage too. Often the design isn't done at hand-off. In practice, most cloud architects are required to stay on a project for a period after delivery to ensure that the solution continues to work and is maintainable.
