RRK - Infra. Modernization Flashcards
Prioritize Clients & Stakeholders
make to-do lists
separate important from urgent
estimate the time, effort and resources needed for each task
reevaluate tasks
Sales Discovery Process
qualify
profile
questions/discovery
propose/demo
evaluation
technical close
support/grow
Value Proposition of Cloud Computing
Companies built their own data centers to run their businesses. This required a large, upfront capital investment, a lengthy procurement cycle, and placed the responsibility of creating, running, and maintaining all the hardware and software for the business on a group of dedicated resources.
As a result, businesses had a tough time keeping up with upgrades and introducing new functionality. They were slow to respond to customer needs and changes in the market.
With cloud computing, companies are able to host their applications, mission-critical workloads, and special projects on the infrastructure built and maintained by a third-party provider. This allows companies to avoid large upfront hardware investments, and only pay for what they use, similar to a utility. Additionally, customers receive automatic functionality upgrades and access to a platform that has a lot of features.
Cloud computing providers, such as Google Cloud Platform, they own and maintain the network-connected hardware required for these application services, while customers provision and use what they need via a web application.
When & Why to move to the Cloud
There are multiple reasons for widespread cloud migration, but they all share a common theme: For most businesses, the cloud simply works better than so-called on-premises.
And it isn’t just about money. While any organization is interested in cutting costs, the Druva survey also found the main drivers of cloud migration were disaster recovery, ease of management, and archival.
Other reasons for increasing cloud migration:
The cloud has matured.
Yes, money is a factor, in several ways.
ROI is easier to forecast, and implementation costs are minimal.
Storage is easier and less expensive.
It is scalable without breaking the budget, enabling both online and geographic expansion.
It lets an organization do more with less downtime, cost, and loss.
It reduces infrastructure overhead.
The cloud is reliable. A cloud vendor will go out of business if it isn’t.
It is highly available.
It gives remote employees access and the ability to work over the internet.
It offers better security.
Cloud Security
Google Cloud Platform (GCP) security fundamentals include having disaster recovery plans, having high visibility of the environment, monitoring logs of cloud activity, using identity access management (IAM) tools, utilizing automated services, and encrypting data at all times.
As with any public cloud provider, there are aspects of the cloud environment that the customer is responsible for and aspects the provider is responsible for. The shared responsibility varies between different service models: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). The following image shows the different responsibilities.
plan
–DR Recovery Plan
visibility/monitor.
- -GCP security command center
- -cloud monitoring
IAM
- -cloud IAM
- -VPCs
automation
encrypt
- -data-at-rest is encrypted by default
- -cloud HSM to secure crypto keys
- -application-level security (ATLS)
- -cloud KMS
- -cloud audit logs
IaaS vs. PaaS vs. SaaS
a) IaaS – infrastructure as a service – IT Admins (Google Compute Engine)
- -This is the lowest level a cloud provider can offer and involves a cloud provider supplying the bare infrastructure these include middleware, Network Cables, CPUs, GPUs, RAM, Persistent Storage, Servers and Base Operating System Images e.g Debian Linux, CentOS, Windows etc.
PaaS – platform as a service – software developers (Google App Engine)
–the cloud-vendor will handle all the details of CPU types, memory, RAM, storage, networking etc. You as the client have a moderate amount of control over the actual platform since the cloud-provider handles all the details of the infrastructure for you. You request the platform of choice and build on it.
SaaS – software as a service – end users (Gmail, Google Docs, etc.)
–the most common services cloud providers supply. They are tailored for end users and are accessed primarily through websites
Concepts
Migrate an enterprise workload
–Define starting environment (on-prem, colocation, other public cloud)
–Define target environment (GCP)
Types of migrations
–Lift and shift – move workloads from a source environment to a target environment with minor or no modifications or refactoring.
–Improve and move – modernize the workload while migrating it.
–Rip and replace – decommission an existing app and completely redesign and rewrite it as a cloud-native app.
Migrations - Phase1: Assess
perform a thorough assessment and discovery of your existing environment in order to understand your app and environment inventory, identify app dependencies and requirements, perform total cost of ownership calculations, and establish app performance benchmarks.
Take inventory
Catalog apps
Educate organization
Experiment & design POCs
Calculate TCO
Choose which to migrate first
Migrations - Phase2: Plan
planning includes identity management, organization and project structure, networking, sorting your apps, and developing a prioritized migration strategy.
Establish user and service identities
Design your resource organization
Define groups and roles for resource access
Design your network topology and establish connectivity
Migrations - Phase 3: Deploy
design, implement and execute a deployment process to move workloads to Google Cloud.
Fully manual deployments Configuration management tools Container orchestration Deployment automation Infrastructure as code
Migrations - Phase 4: Optimize
begin to take full advantage of cloud-native technologies and capabilities to expand your business’s potential to things such as performance, scalability, disaster recovery, costs, training, as well as opening the doors to machine learning and artificial intelligence integrations for your app.
Build and train your team
Monitor everything
Automate everything
Codify everything
Use managed services instead of self-managed ones
Optimize for performance and scalability
Reduce costs
DR
Disaster Recover (DR) is a subset of business continuity planning. DR planning begins with a business impact analysis that defines two key metrics.
RTO
Recovery Time Objective (RTO) – which is the maximum acceptable length of time that your application can be offline. This value is usually defined as part of a larger service level agreement (SLA).
RPO
Recovery Point Objective (RPO) – which is the maximum acceptable length of time during which data might be lost from your application due to a major incident.
SLO
Service Level Objective (SLO) – which is a key measurable element of an SLA. SLOs are specific, measurable characteristics of the SLA, such as availability, throughput, frequency, response time, or quality. RTOs and RPOs are measurable and should be considered SLOs.
SLA
Service Level Agreement (SLA) – is the entire agreement that specifies what service is to be provided, how it is supported, times, locations, costs, performance, penalties, and responsibilities of the parties involved. An SLA can contain many SLOs.
HA
High Availability (HA) – HA helps to ensure an agreed level of operational performance, usually uptime, for a higher than normal period. When you run production workloads on Google Cloud, you might use a globally distributed system so that if something goes wrong in one region, the application continues to provide service even if it’s less widely available. In essence, that application invokes its DR plan.
Google Cloud offers several features that are relevant to DR planning?
A global network
Redundancy
Scalability
Security
Compliance
DR patterns
Cold
Warm
Hot
Create a detailed DR plan
Design according to your recovery goals - The typical way to do this is to look at your RTO and RPO values and which DR pattern you can adopt to meet those values.
Design for end-to-end recovery – Make sure your DR plan addresses the full recovery process, from backup to restore to cleanup.
Make your tasks specific – Make each task in your DR plan consist of one or more concrete, unambiguous commands or actions.
Implement control measures
Add controls to prevent disasters from occurring and to detect issues before they occur.
Prepare your software
Part of your DR planning is to make sure that the software you rely on is ready for a recovery event.
Verify that you can install your software
Design continuous deployment for recovery
Implement security and compliance controls
The same controls that you have in your production environment must apply to your recovered environment. Compliance regulations will also apply to your recovered environment.
Configure security the same for the DR and production environments
Verify your DR security
Make sure users can log in to the DR environment
Train users
Make sure that the DR environment meets compliance requirements
Use Cloud Storage as part of your daily backup routines
Manage secrets properly
Treat recovered data like production data
Make sure your DR plan works
You want to make sure that your planning pays off by making sure that if disaster does strike, everything works as you intend.
Maintain more than one data recovery path
Test your plan regularly
Automate infrastructure provisioning with Deployment Manager
Monitor and debug your tests with Cloud Logging and Cloud Monitoring
Test that permissions and user access work in the DR environment like they do in the production environment.
Perform penetration testing on your DR environment.
Google Cloud Adoption Framework
The framework builds a structure on the rubric of people, process, and technology that customers can work with, providing a solid assessment of where they are in their journey to the cloud and actionable programs that get them to where they want to be.
Learn: The quality and scale of the learning programs you have in place to upskill your technical teams, and your ability to augment your IT staff with experienced partners. Who is engaged? How widespread is that engagement? How concerted is the effort? How effective are the results?
Lead: The extent to which IT teams are supported by a mandate from leadership to migrate to cloud, and the degree to which the teams themselves are cross-functional, collaborative, and self-motivated. How are the teams structured? Have they got executive sponsorship? How are cloud projects budgeted, governed, assessed?
Scale: The extent to which you use cloud-native services that reduce operational overhead and automate manual processes and policies. How are cloud-based services provisioned? How is capacity for workloads allocated? How are application updates managed?
Secure: The capability to protect your services from unauthorized and inappropriate access with a multilayered, identity-centric security model. Dependent also on the advanced maturity of the other three themes. What controls are in place? What technologies used? What strategies govern the whole?
Cloud Maturity Assessment
As a result of this exercise, you should have an understanding of your organization’s vision for adoption of cloud, and an assessment of your current capabilities.
Rehost - Lift-and-shift: “Moving out of a data center”
Replatform - Move and improve: “Application Modernization”
Refactor - Rip and replace: “Building in and for the Cloud”
What is a migration factory?
The concept of the migration factory addresses the challenge of executing a large migration program and delivers a proven, scalable approach aligned to the Google Cloud Adoption Framework in order to:
Migrate and manage large volumes of systems and applications at a high velocity with high-quality and minimal business impact
Initiate and drive new, cloud-native ways of working, such as automated deployment/ DevOps
Establish a new collaborative, joint teamwork model within IT and in cooperation with the business
The migration factory approach is very well-suited for large-scale migration (500+ servers and 200+ applications) taking a lift-and shift or replatform approach. The key is that there is an overarching commonality in all migrations which justifies the setup of a rigorous process, dedicated teams, and investment in tools and automation.
f) Establishing a migration factory
Process pillar - Each migration factory should follow a well-defined, holistic, comprehensive end-to-end process.
People pillar - Based on an understanding of the end-to-end migration process and the total migration scope, there are two key considerations:
–What expertise/which teams are needed to run the process (for example, server administrators, database admins, network engineers, QA/testers)?
–What is the target for migration velocity, and what’s the overall scale of the program? This leads to a requirement for availability from these teams. What capacity does every team need to provide to keep the migration factory line running at the required velocity?
Technology pillar - The third pillar of the migration factory are the tools and technologies used to run it. There are a large number of technical tools to help to migrate workloads. Instead of getting in the details and strengths of each of them, let’s start with the ones which are least obvious but essential. At the core is a tool to drive, manage, orchestrate, and report on the individual migration processes. Basically, a project management (PM) application.
Compute Engine
Computing infrastructure in predefined or custom machine sizes to accelerate your cloud transformation
Three types of machine families
General purpose (N2, N2D, E2)
- -Webservers
- -Databases
Compute optimized (C2)
- -HPC
- -Gaming
- -Electronic Design Automation
- -Single Threaded Applications
Memory optimized (M2)
- -Larger In-memory Databases (SAP HANA)
- -In-memory Analytics
- -GPU (ML or Medical Analysis)
Benefits of Compute Engine
- -Live migrations – keeps running during maintenance
- -Right size recommendations – suggests resizing for efficiency and cost
- -Container support – support deployment of containers
Cost – pay for what you use
- -Sustained use savings – automatic discounts for running VMs significant portion of the month
- -Committed use discounts – up to 57% savings no up-front costs
- -Preemptible VMs – save up to 80% for running batch jobs and fault-tolerant workloads
Anthos
lets you build, deploy, and manage applications anywhere in a secure, consistent manner. You can modernize existing applications running on virtual machines while deploying cloud-native apps on containers in an increasingly hybrid and multi-cloud world. Our application platform provides a consistent development and operations experience across all your deployments while reducing operational overhead and improving developer productivity.
Anthos Compenents
Anthos GKE
Anthos Config Management
Anthos Service Mesh
Anthos security
Anthos Benefits
Manage applications, anywhere
Deliver software faster
Protect applications and software supply chain
Reduce cost
Cloud Deployment Manager
allows you to specify all the resources needed for your application in a declarative format using yaml. You can also use Python or Jinja2 templates to parameterize the configuration and allow reuse of common deployment paradigms such as a load balanced, auto-scaled instance group. Treat your configuration as code and perform repeatable deployments.
Repeatable deployment process
Declarative language
Focus on the application
Template-driven
Cloud Deployment Manager
Parallel deployment
Templates
Updates
Input and output parameters
Schema files
References
Preview mode
Console UI
VM Migrations
Moving VMs to the cloud can help you avoid expensive refresh cycles. Use discovery and assessment tools to understand the cost benefit of moving to the cloud, then execute using our portfolio of migration solutions.
Shift your VMware landscape directly into Google Cloud
Migrate your workloads into Compute Engine
Upgrade to Containers
VM Migrations Benefits
Do more, pay less
Improve performance
Fast, flexible, safe storage
Distributed Systems Design
Scalability
Reliability
Availability
Efficiency
Serviceability/Manageability
Load Balancing
Caching
Sharding
Indexing
Proxies
Queues
Redundancy
SQL vs. NoSQL
