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.
