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 is 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 may be 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 on 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, then 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 the 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, GreatInside, currently has 6 machines running Apache and Tomcat, and 4 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 24GB for the Tomcat servers and 16GB for the IIS servers. VCPUs are more complicated, though.

The existing Tomcat servers 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 2 hyperthreads, that means you need to multiply the number of cores by 2 to get the number of threads, and thus the number of vCPUs.

So our Tomcat servers have the equivalent of 8 vCPUs (4 cores times 2) and our IIS servers have the equivalent of 4 vCPUs (2 cores times 2). Of course, if we really wanted to be accurate, we’d 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 8 vCPUs and 24GB of RAM for the Tomcat servers and 4 vCPUs and 16GB of RAM for the IIS servers. Do any of the predefined machine types match these requirements?  Well, the n1-standard-4 is almost identical to the IIS server requirements. It has 4 vCPUs and 15GB 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 8 vCPUs and 30GB of memory. That’s 6GB 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.

I should mention that there are a couple of ways to reduce those costs: sustained-use discounts and committed-use discounts. If you know that you’re going to be running an instance continuously for a long period of time, then you can pay much less by purchasing either a one-year or three-year contract, which is called a committed-use contract. This will typically reduce the cost by up to 57%. However, that’s a pretty big commitment, so Google provides a way to reduce costs without signing a long-term contract. You start getting an automatic discount after an instance runs for more than 25% of a month, and the discount increases the longer the instance runs during that month. For most machine types, you’ll receive a sustained-use discount of 30% if you run the instance for the entire month.

Okay, let’s get back to our case study. Since IIS and SQL Server run on Windows, we’ll need to figure out how to license them. Let’s start with IIS. For Windows Server itself, you can either use Google’s pay-as-you-go Windows licensing or you can bring your own license. 

There are two ways to use Google’s pay-as-you-go Windows licensing. 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. 

If you want to bring your own Windows licenses, then you can run your Windows VMs on sole-tenant nodes, which are dedicated physical servers that are not shared with other customers.

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 active Software Assurance contracts for its Microsoft applications, then you can move those licenses to either Compute Engine instances or sole-tenant nodes.

Now let’s move on to SQL Server. You can use any of the options I just mentioned, but fortunately, there are also easier options for SQL Server. One option is to create instances with pre-configured SQL Server boot disks . These include pay-as-you-go licenses for both Windows Server and SQL Server. The second option is to use Cloud SQL, which is a managed service. I’ll tell you more about it in the next video.

For premium Linux OSs (such as Red Hat or SUSE), licensing is much simpler. You can either create an instance with a pre-configured boot disk  or you can import your Linux VM. In both cases, you can either use a Google pay-as-you-go license  or bring your own license.

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.