Mapping Needs to GCP Services
The course is part of these learning pathsSee 3 more
Google Cloud Platform (GCP) lets organizations take advantage of the powerful network and technologies that Google uses to deliver its own products. Global companies like Coca-Cola and cutting-edge technology stars like Spotify are already running sophisticated applications on GCP. This course will help you design an enterprise-class Google Cloud infrastructure for your own organization.
When you architect an infrastructure for mission-critical applications, not only do you need to choose the appropriate compute, storage, and networking components, but you also need to design for security, high availability, regulatory compliance, and disaster recovery. This course uses a case study to demonstrate how to apply these design principles to meet real-world requirements.
- Map compute, storage, and network needs to Google Cloud Platform services
- Create designs for high availability and disaster recovery
- Use appropriate authentication, roles, service accounts, and data protection
- Create a design to comply with regulatory requirements
Although most Google Cloud designs include virtual machine instances, that doesn't mean VMs are your only option for compute resources. Before you start designing a solution using only compute engine instances, you should consider App Engine and Kubernetes Engine.
App Engine is designed for people who don't want to manage an application's underlying infrastructure. App Engine provisions and scales all of the resources your application needs behind the scenes without any human intervention required. That sounds great doesn't it? So why wouldn't you use App Engine?
The main reason is that it's much easier to develop a new application on App Engine than it is to migrate an existing one to it. So if you're developing an application from scratch, then App Engine maybe a good choice. If you have an existing application, then you'll need to check if App Engine supports the programming languages your app is written in. And if your app has any operating system dependencies, such as only being able to run on Windows, which isn't supported by App Engine.
You'll also need to look at your application's architecture to see if it would be able to run App Engine without having to re-architect it. App Engine is designed for microservices based apps so if your existing application has a monolithic architecture, than it might require some work to migrate it.
For all of these reasons, it's usually advisable to use App Engine only for new applications rather than existing ones.
The next option is Kubernetes Engine. It provides many of the benefits of App Engine, in that you don't have to worry about underlying operating system running your application. It also handles scaling, although you have to configure that yourself first. It does require more management than App Engine, but it doesn't require as much management as Compute Engine.
The ideal case for using Kubernetes Engine is of course if your application already runs in containers, especially Docker containers since that's what Kubernetes Engine supports. On the other hand, if your application will only run on certain operating systems, especially Windows, then it won't run in Kubernetes Engine.
If you have an existing app that does not currently run in containers, then you might want to see if it's possible to containerize it so you can take advantage of Kubernetes Engine.
If your existing application runs on virtual machines then the easiest way to migrate it to Google Cloud is to use Compute Engine instances. If it doesn't run on virtual machines, then you'll have to virtualize it before you can run it on Google Cloud.
Although Compute Engine requires more management than App Engine or Kubernetes Engine, it does give you ultimate flexibility. For example, you could run an application that requires Windows, a specific network driver, and high performance GPUs.
Since our case study involves an existing application that doesn't currently run in containers, we're going to choose Compute Engine for our design.
The case study company, Great Inside, currently has six machines running Apache and Tomcat, and four machines running IIS. Let's have a look at Google's predefined machine types. We need to decide how many vCPUs and how much memory to use. Memory is pretty straightforward. Our existing machines have 24 gig for the Tomcat servers, and 16 gig for the IIS servers. vCPUs are more complicated though.
The existing Tomcat severs have two dual-core CPUs and the IIS servers have one dual-core CPU. How does that translate into vCPUs? Some people say that cores and vCPUs are equivalent, but that's not quite true. A vCPU on a Compute Engine instance is implemented as a single hyper-thread on an Intel Xeon Processor. Since each Xeon Processor has two hyper-threads, that means you need to multiply the number of cores by two to get the number of threads, and thus the number of vCPUs.
So our Tomcat servers have the equivalent of eight vCPUs, four cores times two, and our IIS servers have the equivalent of four vCPUs, two cores times two. Of course if we really wanted to be accurate, we need to take into account things like the clock speed of the CPUs, but we're not going to go that far.
So we need eight vCPUs and 24 gigs of RAM for the Tomcat servers, and four vCPUs and 16 gigs of RAM for the IIS servers. Do any of the predefined machine types match these requirements? Well, n1-standard-4 is almost identical to the IIS server requirements. It has four vCPUs and 15 gigs of RAM. Having one less gig of RAM is probably fine, but you can monitor it in production to make sure it's sufficient.
The Tomcat servers are another story though. The closest match is the n1-standard-8 which has eight vCPUs and 30 gigs of memory. That's six gig more than we need so we should consider a custom machine type. We can select the exact size we need. With this custom configuration, it says it will cost $190.54 per month. Let's see how that compares to the n1-standard-8. That costs $194.58 per month, which is more expensive, but only 2% more.
Since SQL Server and IIS run on Windows, we'll need to figure out how to license them. For Windows Server itself, there's really no other option than to use Google's pay-as-you-go Windows licensing. There are two ways to do this. The first way is to create a new instance with one of the pre-configured Windows Server boot disks. The second way is to import a Windows VM. There are two options for importing a VM. The first option is to import a virtual disk and turn it into an image that you can use to create a Compute Engine instance. That’s quite simple to do, but it’s not meant for migrating mission-critical applications or migrating a large number of VMs in an automated fashion.
A more sophisticated option is to use Cloud Migrate for Compute Engine. This service makes replicas of existing VMs you have running on-premises or on another cloud platform. It will take care of the many steps that are needed to migrate important applications. Regardless of which option you use to migrate your VMs, they’ll still use pay-as-you-go pricing for Windows because you can’t use your existing Windows licenses.
If you need to run any Microsoft applications, then you'll need licenses for those too of course. But Microsoft is more flexible with its application licensing than with Windows licensing. If your organization has a Microsoft Volume License with eligible server applications covered by active Microsoft Software Assurance contracts, then you can move those licenses to Google Cloud instances.
Alternatively, if you need to run SQL Server, which is the case for Grade Inside, then you can create instances with pre-configured SQL Server boot disks. These include pay-as-you-go licenses for both Windows Server and SQL Server.
For premium Linux OS such as Red Hat or SUSE, licensing is much simpler. You can either import your Linux VM and bring your own license. Or you can create an instance with a pre-configured boot disk.
I should mention one other Compute Engine option, Preemptible VMs. They're up to 80% cheaper than regular instances. But since Google can remove them with only 30 seconds notice, you would usually only use them as disposable instances. For things like big data batch jobs. That doesn't fit our use case, so we'll stick with regular instances.
And that's it for this lesson.
About the Author
Guy launched his first training website in 1995 and he's been helping people learn IT technologies ever since. He has been a sysadmin, instructor, sales engineer, IT manager, and entrepreneur. In his most recent venture, he founded and led a cloud-based training infrastructure company that provided virtual labs for some of the largest software vendors in the world. Guy’s passion is making complex technology easy to understand. His activities outside of work have included riding an elephant and skydiving (although not at the same time).