1. For Web Application they should use GCE with MIG and LBs 2. For NAS they could potentially use Filestore but it has a limitation of 64TB (I think 320TB for Filestore is in beta) and hence GCS would be a better option 3. Also they don't talk about provisioning resources on the Cloud & On-Prem but deploying applications on the Cloud & On-Prem that should be Jenkins install or from Marketplace 4. For DR you need to use Cloud CDN 5. For 2nd question the best option is C
Thanks for your video, very interesting. I believe, that the answer to the first question should be C. This is the recommended practice to choose appropriate machine types starting from the smallest instances. Option D also can be correct, but we can't be ensured that 1 core on-premise is the same thing as 1 vCPU in GCP.
Thank you Sergiy, yep C is very close and I still feel D is the right choice as per this article: cloud.google.com/solutions/resource-mappings-from-on-premises-hardware-to-gcp
@@CloudAdvocate I believe one reason to vote for D over C is that C talks about Production. Normally, you would not start small on Prod , you would atleast start with your present on prem resource level and then scale.
I think C & D are both technically right answer, but different practice approach. I would have choose D over C, because testing from the smallest possible (f1-micro?) is time consuming. I would choose to start with the matching spec and then monitoring the resource utilization, then adjust accordingly.
Answer c, makes sense over d due to the on prem being 'iscsi for vm host' So, looking at the physical hardware cores and RAM as several virtual machines might share them, would not be a best practice.
Hey, thank you for the content, it's nice to ear some else's thoughts on the case studies, and compare with your opinion. I agree with both answers, although the first one is hard. You could make a good case for at least one or two of the answers. But in a real life situation I would go for D as well.
Storage Transfer Service wouldn't work anyway *even if* it were cheap - STS is meant for transferring data from other cloud storage buckets and/or HTTP(S) endpoints into GCP. However, in the case of Dress4Win, they have data stored on physical machines. gsutil could work, although if there is a ton of data, they could also use a Transfer Appliance and a TA Rehydrator.
Hello, if you read the technical requirements, Implement a continuous deployment process for "deploying applications" to the on-premise data center or cloud. Here applications are nothing but microservices on Tomcat using Java, clearly "Springboot applications". Of course, the first requirement of Implementation of an automation framework for provisioning resources, the answer is terraform. Even if they use terraform for infra as code, they have to use a CICD pipeline for automation i.e Jenkins pipeline. So Terraform with Jenkins is the answer. As they are already using Jenkins on-premise. So they can use Jenkins too on Cloud on a Compute Instance. Anyways, good analysis. Thanks.
Thank you, yes. I just focussed on Infrastructure as a code to manage both on prem and cloud, hence terraform. But yes if there is a CI discussion..yes you are absolutely right.
Cloud SQL is not possible, as its capacity is limited to 30TB. Dress4Win already uses 600TB of storage on their SQL instance. It hence should be a bare bones with multiple PDs attached. I don't see any reason for using CDN to offload, but I reckon you intend to say DNS?
Appreciate if you can give the options for deployment of web and transactional layers for the same case study also couple of more questions with explanation for each case study..
