Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Before migrating to the cloud, architects must choose a workload disposition strategy that decides whether to build, buy, modify, or deprecate each application. The modernization process begins when teams assess the environment to create a detailed inventory of all current datasets and data pipelines. This assessment catalogs hardware properties and software dependencies to map how different parts of the system interact with each other. By understanding these relationships, organizations can accurately calculate their total cost of ownership and prioritize which workloads to migrate first.
A key design choice in modern cloud architectures is the separation of storage and computation layers to increase operational flexibility. By keeping these systems separate, organizations can modify their data processing tools without needing to migrate or transform the underlying data. In this architecture, raw data typically lands in Cloud Storage for scalable file management. From there, processing engines like Dataflow can clean and load the data, while analytical engines like BigQuery perform high-performance queries directly against the stored records.
To minimize operational overhead, organizations often re-platform existing databases and applications onto Google Cloud managed services. Migrating legacy databases to Cloud SQL or Spanner shifts the burden of maintenance, patching, and backups to Google Cloud, which improves system scalability. Architects must evaluate the technical feasibility of this transition by testing network latency and configuring high availability zones to prevent service outages. Ongoing success depends on regular failover testing and optimizing operational costs using committed use discounts.
Deciding to deprecate an application is a critical workload disposition strategy used when a system no longer provides enough value to justify its operating costs. Architects identify these legacy systems by analyzing technical debt, which is the long-term cost of maintaining outdated or poorly structured code. They also evaluate security risks, such as software that no longer receives updates and could expose the organization to data breaches. When the cost to maintain a system exceeds the business value or profit it generates, the system becomes a prime candidate for retirement.
Retiring a workload requires careful planning to protect legacy information and ensure a seamless transition for any dependent services. The process begins with building an inventory of all active data and pipelines to map which external services still rely on the system. Architects must establish secure data archival procedures to store historical records safely while verifying network latency and security permissions for the new target environment. This structured approach prevents sudden service outages and protects the organization's operational stability during the shutdown.
External triggers, such as the end of support for operating systems like CentOS 7, often force organizations to deprecate workloads. When a vendor stops providing critical security patches, the system becomes an immediate security risk that must be migrated or retired. Similarly, cloud providers regularly deprecate specific features, such as older GKE security dashboards, to transition users to more advanced alternatives. Organizations must actively monitor official release notes to stay ahead of these updates and prevent unexpected disruptions to their live environments.
Various strategic forces influence deprecation decisions, such as the business goal to reduce capital expenditures or integrate systems after a corporate merger. Technical drivers might include the desire to adopt modern serverless services or advanced artificial intelligence capabilities that older systems cannot support. During these major shifts, organizations often adopt a hybrid or multicloud architecture as a temporary state. This allows teams to safely phase out legacy systems over time while keeping business operations running smoothly.
Organizations choose to build custom software when they need a distinct competitive advantage that commercial products cannot deliver. Developing a custom application allows teams to create unique proprietary features, such as specialized analytics or custom artificial intelligence systems. However, this strategy requires a higher upfront financial investment and a team with specialized technical skills to manage development. The long-term success of a custom-built solution depends on the organization's ability to maintain the codebase over its entire lifecycle.
Choosing commercial off-the-shelf software or using fully managed cloud services is an effective strategy for accelerating an organization's speed to market. By purchasing existing products, teams avoid the time-consuming process of writing code and building infrastructure from scratch. This approach significantly reduces ongoing maintenance tasks because the vendor or cloud provider manages backend updates, patching, and scaling. Organizations frequently select this strategy to support short-term projects or to quickly provision standard business utilities.
Comparing build and buy decisions requires a comprehensive analysis of the total cost of ownership. This financial evaluation must calculate software licensing fees, including options for bringing your own license, alongside the cost of specialized technical personnel. Additionally, architects must factor in recurring infrastructure costs for compute, storage, and networking resources. Understanding these ongoing operational expenses, as well as the potential costs of data movement, helps organizations select the most financially viable path.
As digital transformations progress, organizations may choose to modify existing systems or adopt a temporary hybrid cloud architecture. To guide these complex architectural decisions, many enterprises establish a Cloud Center of Excellence to standardize practices and align technology investments with business goals. This governing body helps ensure that systems are continuously monitored for performance and utility. When legacy systems no longer deliver sufficient business value, this framework ensures they are modified or systematically deprecated.
Prepare and test your skills
Prepare and test your skills
Deciding to deprecate an application is a critical workload disposition strategy used when a system no longer provides enough value to justify its operating costs. When the cost to maintain a system exceeds the business value or profit it generates, the system becomes a prime candidate for retirement. Architects also identify legacy systems by analyzing technical debt and evaluating security risks from software that no longer receives updates.
Separating storage and computation layers increases operational flexibility by keeping these systems independent. Organizations can modify their data processing tools without needing to migrate or transform the underlying data. Raw data typically lands in Cloud Storage for scalable file management, while processing engines like Dataflow clean and load the data and analytical engines like BigQuery perform high-performance queries directly against stored records.
Organizations choose to build custom software when they need a distinct competitive advantage that commercial products cannot deliver, such as specialized analytics or custom artificial intelligence systems. Buying commercial off-the-shelf software or using fully managed cloud services accelerates speed to market by avoiding the time-consuming process of building infrastructure from scratch, while the vendor manages backend updates, patching, and scaling.
External triggers such as the end of support for operating systems like CentOS 7 often force organizations to deprecate workloads. When a vendor stops providing critical security patches, the system becomes an immediate security risk that must be migrated or retired. Cloud providers also regularly deprecate specific features, such as older GKE security dashboards, to transition users to more advanced alternatives.
Containerize the data processing workloads and manage them manually on self-managed Apache Spark pods inside Google Kubernetes Engine (GKE)
Refactor the data pipelines using the Apache Beam SDK and execute them as serverless jobs on Cloud Dataflow
Offload batch records into Cloud Storage and trigger event-driven Cloud Functions to process all batch transformations and continuous streaming analytics
Rehost the existing data processing jobs directly on Compute Engine virtual machines using custom autoscaling and OS-level cron scheduling
An enterprise operates several on-premises data processing pipelines that process both historical batch logs and real-time streaming transactional data. The operations team spends significant time managing cluster nodes, provisioning compute capacity for peak hours, and handling cascading job failures.
Leadership wants to modernize this architecture to minimize operational maintenance, achieve automatic horizontal scaling for variable data volumes, and unify their batch and streaming processing models.
Which modernization and re-platforming strategy should the enterprise implement?