Serving 

SSCA App

Robust :
 

Hosting options on Google Cloud : 

Option  Product  Data storage  Load balancing  Scalability 

Static Cloud Storage  Cloud Storage bucket  HTTP(S) optional  Automatically 

website  Firebase Hosting 
Virtual Compute Engine Cloud SQL Admin API, Cloud Storage HTTP(S)  Automatically with managed i
machines  API, Datastore API, and TCP Proxy  nstance groups 
Cloud Bigtable API, or you can SSL Proxy 
use another external storage provider IPv6 termination 
. t Network 
Hard-disk-based persistent disks, call Cross-region 
ed standard persistent disks, Internal 
and solid-state
persistent disks (SSD). 
Containers GKE  Simdesignilar to Compute Engine Network  Cluster autoscaler 
but interacts with persistent disks dif HTTP(S) 
ferently 
Managed App Engine  Google Cloud services such as Cloud HTTP(S)  Managed by Google 
platform  SQL, Firestore, Cloud Storage, and Managed by
accessible third-party databases  Google 
Serverless  Cloud Run  Google Cloud services such as Cloud HTTP(S)  Managed by Google 
SQL, Firestore, Cloud Storage, and Managed by
accessible third-party databases  Google 
 
 App Engine VS Compute Engine
Google App Engine and Google Compute Engine are both services businesses can use for deploying applications
once they’ve been coded.  Google App Engine is a platform-as-a-service solution designed to make app
deployment as easy possible.  In contrast, Google Compute Engine is an infrastructure-as-a-service tool that
provides a highly configurable and flexible platform for application deployment. Both options are most popular
with small businesses, but Google App Engine is more popular with larger businesses, likely due to its automation
features.

Features

Google App Engine and Google Compute Engine both provide a platform for application deployment, but they also
have some standout features that are important to consider.

Google App Engine provides a host of automation features that make it easy for businesses to focus on app
development, instead of configuring the deployment.  As applications deployed on Google App Engine see more or
less use, the platform will automatically adjust the number of instances without input from a developer.  Google
App Engine also provides a software development kit to help users optimize applications for the platform.

Google Compute Engine allows for a high level of customization so users can set up their deployment however they
want.  Businesses with a skilled development team can create as many or as few virtual machines as they want,
while customizing them for the needs of their applications.  Google Compute Engine is also generally more
affordable compared to Google App Engine, which can make it more a pealing to businesses on a smaller budget.

Limitations

Google App Engine and Google Compute Engine both help businesses deploy their applications, but they also have
a few limitations that are important to consider.

Google App Engine provides a high level of automation and is simple to use, but isn’t as customizable as Google
Compute Engine.  Businesses with specific needs for their application may prefer the customizability of Google
Compute Engine.  Additionally, while Google App Engine’s software development kit is great for applications that
are developed with Google App Engine, it can be difficult to take advantage of it if for applications that were
developed before Google App Engine was selected.

Google Compute Engine is highly customizable, but it isn’t as automated or easy to use.  Businesses using Google
Compute Engine will have to manually adjust the volume of their virtual machines as application traffic grows or
shrinks.  Google Compute engine needs a development team to work with it, unlike Google App Engine, which can
be managed with less effort.=> Building our configuration from scratch.

Pricing

Google App Engine pricing depends on the type of instance, but starts as low as $»0.05 per hour per instance. 

Google Compute Engine offers pay as you go pricing starting as low as $0.006543 per hour.

=> We choose compute engine

 Compute Engine

=> Setting up manually

=> Building our configuration from scratch.

Steps we need to follow are:

. Understand the requirements. If you're building a new website, make sure you understand the components you need,
such as instances, storage needs, and networking infrastructure. If you're migrating your app from an existing solution,
you probably already understand these requirements, but you need think through how your existing setup maps
to Google Cloud services.

. Plan the design. Think through your architecture and write down your design. Be as explicit as you can.

. Create the components. The components that you might usually think of as physical assets, such as computers and
network switches, are provided through services in Compute Engine. For example, if you want a computer, you have to
create a Compute Engine instance. If you want a persistent hard disk drive, you create that, too. Cloud Deployment
Manager or Terraform makes this an easy and repeatable process.

. Configure and customize. After you have the components you want, you need to configure them, install and
configure software, and write and deploy any customization code that you require. You can replicate the configuration
by running shell scripts, which helps to speed future deployments. Deployment Manager helps here, too, by providing
declarative, flexible configuration templates for automatic deployment of resources. You can also take advantage of IT
automation tools such as Puppet and Chef.

. Deploy the assets. Presumably, you have web pages and images.

. Test. Verify that everything works as you expect.

. Deploy to production. Open up your site for the world to see and use.
Storing data with Compute Engine:
Persistent disks (Network Storage) on Compute Engine for use as primary storage for your instances. Compute
Engine offers both hard-disk-based persistent disks, called standard persistent disks, and solid-state persistent
disks (SSD). You can also choose to set up your preferred storage technology on Compute Engine by using
persistent disks. For example, you can set up PostgreSQL as your SQL database or MongoDB as your NoSQL storage.

Disk types:

When you configure a zonal or regional persistent disk, you can select one of the following disk types.

. Standard persistent disks (pd-standard) are backed by standard hard disk drives (HDD).

. Balanced persistent disks (pd-balanced) are backed by solid-state drives (SSD). They are an alternative to SSD
persistent disks that balance performance and cost.

. SSD persistent disks (pd-ssd) are backed by solid-state drives (SSD).

. Extreme persistent disks (pd-extreme) are backed by solid-state drives (SSD). With consistently high performance for
both random access workloads and bulk throughput, extreme persistent disks are designed for high-end database
workloads. Unlike other disk types, you can provision your desired IOPS.

Montréal (northamerica-northeast1)
Type Price (monthly in USD) Price 100 GB (monthly in USD)

Standard provisioned space $0.044 per GB

$4.4
SSD provisioned space $0.187 per GB
$18.7
Balanced provisioned space $0.110 per GB
$11
Extreme provisioned space $0.1375 per GB
$13.75
 Load balancing :
For any website that operates at scale, using load-balancing technologies to distribute the workload among servers
is often a requirement.

. Important Features:

- Health check - Route to healthy instances

Recover from failures

- Auto Scaling

- Global load balancing with single anycast IP

Also supports internal load balancing

. Enables:

- High Availability

- Auto Scaling

- Resiliency

Google Cloud HTTP(S) Load Balancing is a global, proxy-based Layer 7 load balancer that enables you to run and
scale your services worldwide behind a single external IP address. External HTTP(S) Load Balancing distributes
HTTP and HTTPS traffic to backends hosted on Compute Engine and Google Kubernetes Engine (GKE).

External HTTP(S) Load Balancing is implemented on Google Front Ends (GFEs). GFEs are distributed globally and
operate together using Google's global network and control plane. In the Premium Tier, GFEs offer multi-region
load balancing, directing traffic to the closest healthy backend that has capacity and terminating HTTP(S) traffic
as close as possible to your users. With Standard Tier, the load balancing is handled regionally.
 Montréal (northamerica-northeast1)
Item Price per unit (USD) Pricing unit

First 5 forwarding rules $0.028 Per Hour

Per additional forwarding rule $0.011 Per Hour

Ingress data processed by load balancer $0.009 Per GB

Content distribution with Compute Engine :
Because response time is a fundamental metric for any website, using a CDN to lower latency and increase
performance is often a requirement, especially for a site with global web traffic.

Cloud CDN uses Google's globally distributed edge points of presence to deliver content from cache locations
closest to users. Cloud CDN works with HTTP(S) load balancing. To serve content out of Compute Engine, Cloud
Storage, or both from a single IP address, enable Cloud CDN for an HTTP(S) load balancer.

Autoscaling with Compute Engine:

 You can set up your architecture to add and remove servers as demand varies. This approach can help to ensure
that your site performs well under peak load, while keeping costs under control during more-typical demand
periods. Compute Engine provides an autoscaler that you can use for this purpose.

Autoscaling is a feature of managed instance groups. A managed instance group is a pool of homogeneous virtual
machine instances, created from a common instance template. An autoscaler adds or remove instances in a
managed instance group. Although Compute Engine has both managed and unmanaged instance groups, you can
only use managed instance groups with an autoscaler. For more information, see autoscaling on Compute Engine.

For an in-depth look at what it takes to build a scalable and resilient web-app solution, see Building scalable and
resilient web apps.

!! Scalability in Comute Engine option: Automatically with managed instance groups 

Managed Instance Groups (MIG):

Benefits:

MIGs offer the following advantages:

. High availability.

. Keeping VM instances running. If a VM in the group stops, crashes, or is deleted by an action other than an instance
group management command (for example, an intentional scale in), the MIG automatically recreates that VM in
accordance with the original instance's specification (same VM name, same template) so that the VM can resume its
work.

. Application-based autohealing. You can also set up an application-based health check, which periodically verifies
that your application responds as expected on each of the MIG's instances. If an application is not responding on a VM,
the autohealer automatically recreates that VM for you. Checking that an application responds is more precise than
simply verifying that a VM is up and running.

. Regional (multiple zone) coverage. Regional MIGs let you spread app load across multiple zones. This replication
protects against zonal failures. If that happens, your app can continue serving traffic from instances running in the
remaining available zones in the same region.

. Load balancing. MIGs work with load balancing services to distribute traffic across all of the instances in the group.

. Scalability. When your apps require additional compute resources, autoscaled MIGs can automatically grow the
number of instances in the group to meet demand. If demand drops, autoscaled MIGs can automatically shrink to
reduce your costs.

. Automated updates. The MIG automatic updater lets you safely deploy new versions of software to instances in your
MIG and supports a flexible range of rollout scenarios, such as rolling updates and canary updates. You can control the
speed and scope of deployment as well as the level of disruption to your service.

. Support for stateful workloads. You can use MIGs for building highly available deployments and automating operation
of applications with stateful data or configuration, such as databases, DNS servers, legacy monolith applications, or
long-running batch computations with checkpointing. Stateful MIGs preserve each instance's unique state (instance
name, attached persistent disks, and metadata) on machine restart, recreation, auto-healing, and update events.
Groups of preemptible instances
For workloads where minimal costs are more important than speed of execution, you can reduce the cost of your
workload by using preemptible VM instances in your instance group. Preemptible instances last up to 24 hours, and
are preempted gracefully—your application has 30 seconds to exit correctly. Preemptible instances can be deleted
at any time, but autohealing will bring the instances back when preemptible capacity becomes available again.

Preemptible instances in a managed instance group

You can create preemptible instances in a managed instance group. Specify the preemptible option in the instance
template before you create or update the group.

Managed instance groups can create or add new preemptible instances only when additional Compute Engine
resources are available. If these resources are limited, managed instance groups will be unable to resize or
automatically scale the number of preemptible instances in the group.

Managed instance groups always attempt to maintain their target size or the size specified by the autoscaler for
that group. If Compute Engine stops a preemptible instance in a managed instance group, the group repeatedly
tries to recreate that instance using the specified instance template. If the necessary resources become available
again, the group recreates the instance and maintains the target group size.
Instance templates :
. Define machine type, image, labels, startup script and other properties

. Used to create VM instances a designnd managed instance groups

Static IP:

External IP in GCP changed when we stop and start a virtual machine.

At some point, one or more of your VM instances might be lost due to system or hardware failures. Some of the failures include
but are not limited to:

Unexpected single instance failure :

Unexpected single instance failures can be due to hardware or system failure. To mitigate these events, use persistent
disks and startup scripts to save your data and re-enable software after you restart the instance.

Unexpected single instance reboot

At some point in time, you will experience an unexpected single instance failure and reboot. Unlike unexpected
single instance failures, your instance fails and is automatically rebooted by the Compute Engine service. To help mitigate
these events, back up your data, use persistent disks, and use startup scripts to quickly re-configure software.

Zone or region failures

Zone and region failures are rare failures that can cause all of your instances in a given zone or region to be
inaccessible or fail.

To mitigate these failures, create diversity across regions and zones and implement load balancing. You should also back
up your data or replicate your persistent disks across multiple zones.

total Estimated Cost of 2 Static IPs : USD 2.92 per month

Logging and monitoring with Compute Engine:

Google Cloud includes features that you can use to keep tabs on what's happening with your website.

Cloud Logging collects and stores logs from apps and services on Google Cloud. You can view or export logs and
integrate third-party logs by using a logging agent.

Total cost

2 VMs with static IPs : USD 83.16 per 1 month

100 GB SSD provisioned space : USD 37.4 per month

Load balancing : USD 21.34 per month

Cloud DNS : USD 0.20 per month

Total 142.1

Just one instance:

100 GB SSD provisioned space : USD 37.4 per month

Total cost : USD 160.1 per mounth