RRK - Infra. Modernization Flashcards
(37 cards)
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.
