By Scott Van Woudenberg, Product Manager, Google Compute Engine

Google Compute Engine now supports nested virtualization in beta. This feature allows you to run one or more virtual machines inside a Compute Engine Linux virtual machine -- VMs inside of VMs. This leverages Intel VT-x, processor virtualization instructions, to deliver better performance than what's possible with alternative technologies like emulation.



Nested virtualization makes it easier for enterprise users to move their on-premises, virtualized workloads to the cloud without having to import and convert VM images. Dev/test and CI/CD workloads that need to validate software in multiple environments are a good match for nested virtualization. Nested virtualization also enables more cost-effective, cloud-based disaster recovery solutions and is ideal for technical training and certification courses where students need identical environments to practice the exercises.

You can enable nested virtualization on Linux VMs of any size or shape, including predefined and custom machine types and Preemptible VMs, as long as the VM is running on an Intel's Haswell CPU or newer. See our list of available regions and zones for the CPU platforms available in each zone. Compute Engine's nested virtualization currently supports KVM-based hypervisors.

A number of partners participated in our nested virtualization alpha, including Scale Computing and appOrbit.

Scale Computing is a leading provider of complete hyper-converged (HC3) solutions with thousands of deployments, from SMBs to enterprises. Scale has been building a new offering, HC3 Cloud Unity, in collaboration with Google, that creates a seamless, private virtual network that connects Scale's HC3 appliances running on-premises with virtualized HC3 appliances running on Compute Engine, and that uses our hardware-accelerated nested virtualization. Organizations can now move application workloads and data freely over HC3 Cloud Unity's virtual LAN, combining their GCP and on-premise environments to make a single platform.

appOrbit's application platform on Google Cloud gives end users the flexibility to make both legacy and cloud-native applications -- inclusive of the data they rely on -- portable to any modern infrastructure, without rewriting code, in minutes. Customers using appOrbit with Google's nested virtualization can rapidly deploy and run a broader set of application workloads with zero modification, as well as simultaneously manage hybrid infrastructure and realize the full value of hybrid IT.

Other Compute Engine customers, like Functionize, also participated in our nested virtualization alpha and were able to deliver benefits such as improved performance and lower cost to their customers.

"This is a huge win for QA and development teams who need native mobile systems, such as Android, for testing/validating mobile apps. Using Google’s new hardware-accelerated nested virtualization, Functionize now enables QA teams to dramatically reduce costs, time-to-test, and the pain of maintaining a complex device inventory." -- Tamas Cser, Founder and CEO, Functionize

To learn more, check out the Compute Engine nested virtualization documentation. And be sure to contact us to share your feedback or if you encounter any issues.

Ready to try out nested virtualization? Sign up for a free trial today and get $300 in credits to get started.

By Raphael Simon, CTO and Co-Founder of Shine

[Editor’s note: Technology today lets companies of any size take on entire industries simply with an innovative business model plus digital distribution. Take Shine, a French startup whose platform helps freelancers manage their finances -- and their administrative commitments. Here, Raphael Simon, Shine’s CTO and co-founder, talks about why Shine built a new bank on Google Cloud Platform, and in particular Cloud Spanner. Read on to learn how the enterprise-grade database combines the best of relational database structure and non-relational database scale with -- coming soon -- synchronous replication across regions and continents with a 99.999% (five nines) availability SLA.] 

More and more people are deciding to take the plunge and start a freelance career. Some of them by choice, others out of necessity. One of their biggest pain points is dealing with administrative tasks. In some countries, especially in Europe, the administrative burden of being a freelancer is similar to what a company of 10 or more people deals with. A freelancer doesn’t necessarily have the time or skills to manage all this paperwork. So we are building a new bank for freelancers from the ground up that helps automate administrative tasks associated with their business.

Shine’s banking services and financial tools make it as easy to work as a freelancer as it is to work for a larger company. We deal with administrative tasks on behalf of the freelancer so that he or she can focus on their job: finding and wowing clients.

Building our infrastructure 

As a new bank, we had the opportunity to build our infrastructure from the ground up. Designing an infrastructure and choosing a database presents tough decisions, especially in the financial services world. Financial institutions come under tremendous scrutiny to demonstrate stability and security. Even a tiny leak of banking data can have tremendous consequences both for the bank and its clients, and any service interruption can trigger a banking license to be suspended or a transaction to be declined.

At the same time, it’s vital for us to optimize our resources so we can maximize the time we spend developing user-facing features. In our first six months, we iterated and validated a prototype app using Firebase, and secured our seed funding round (one of the largest in Europe in 2017).

Based on our positive experience with Firebase, plus the ease-of-use and attractive pricing that Google Cloud offered, we decided to build our platform on Google Cloud Platform (GCP). We were drawn to GCP because it has a simple, consistent interface that is easy to learn. We chose App Engine flexible environment with Google Cloud Endpoints for an auto-scaling microservices API. These helped us reduce the time, effort, and cost in terms of DevOps engineers, so we could invest more in developing features, while maintaining our agility. We use Cloud Identity and Access Management (Cloud IAM) to help control developer access to critical parts of the application such as customer bank account data. It was quite a relief to lean on a reliable partner like Google Cloud for this.

Database decisions 

Next came time to choose a database. Shine lives at the financial heart of our customers’ businesses and provides guidance on things like accounting and tax declaration. The app calculates the VAT for each invoice and forecasts the charges they must pay each quarter.

Due to the sensitivity of our customers’ data, the stakes are high. We pay careful attention to data integrity and availability and only a relational database with support for ACID transactions (Atomicity, Consistency, Isolation, Durability) can meet this requirement.

At the same time, we wanted to focus on the app and user experience, not on database administration or scalability issues. We’re trying to build the best possible product for our users, and administering a database has no direct value for our customers. In other words, we wanted a managed service.

Cloud Spanner combines a globally distributed relational database service with ACID transactions, industry-standard SQL semantics, horizontal scaling, and high availability. Cloud Spanner provided additional security, high-availability, and disaster recovery features out-of-the-box that would have taken months for us to implement on our own. Oh, and no need to worry about performance -- Cloud Spanner is fast. Indeed, Cloud Spanner has been a real asset to the project, from the ease-of-use of creating an instance to scaling the database.

Cloud Spanner pro tips 

We began working with Cloud Spanner 6 months ago, and have learned a lot along the way. Here are some technical notes about our deployment and some best practices that may be useful to you down the road:

• The first connection to Cloud Spanner takes a long time to initialize, which makes it difficult to expose an API through Cloud Functions. Instead, we used App Engine flexible environment to build our microservices API for a serverless approach that has very good performance. We use Cloud Functions for simple asynchronous scripts for background tasks that do not require an immediate answer to the client (e.g., sending an iOS notification given the user parameters) that we trigger via Cloud Pub/Sub. 
• Cloud Spanner allows us to change a schema in production without downtime. We always use a NOT NULL constraint, because we generally think that using NULL leads to more errors in application code. We always use a default value when we create an entity through our APIs and we use Cloud Dataflow to set values when we change a schema (e.g., adding a field to an entity). 
• With microservices, it’s generally a good practice to make sure every service has its own database to ensure data isolation between the different services. However, we adopted a slightly different strategy to optimize our use of Cloud Spanner. We have an instance on which there are three databases -- one for production, one for staging and one for testing our continuous integration (CI) pipeline. Each service has one or more interleaved tables that are isolated from others services’ tables (we do not use foreign-keys between tables from different services). This way our microservices data are not tightly “coupled”. 
• We created an internal query service that performs read-only queries to Cloud Spanner to generate a dashboard or do complex queries for analytics. It is the only service where we allow joins between tables across services. 
• We take advantage of Cloud Spanner’s scalability, and thus don’t delete any data that could one day be useful and/or profitable. 
• We store all of our business logs on Cloud Spanner, for example connection attempts to the application. We append the ‘-Logs’ suffix to them. 
• When possible, we always create an interleave. 

 In short, implementing Cloud Spanner has been a good choice for Shine:

• It’s saved us weeks, if not months, of coding. 
• We feel we can rely on it since it’s been battle-tested by Google. 
• We can focus on building a disruptive financial services product for freelancers and SMBs.

And because Cloud Spanner is fully managed and horizontally scalable, we don’t have to worry about hardware, security patches, scaling, database sharding, or the possibility of a long and risky database migration in the future. We are confident Cloud Spanner will grow with our business, particularly as we expand regionally and globally. I strongly recommend Cloud Spanner to any company looking for a complete database solution for business-critical, sensitive, and scalable data.

By Carol Martin, Community Marketing Manager

You’ve heard that old joke, “How do you get to Carnegie Hall?”

Practice, practice, practice. 

In that spirit, we’ve launched an online practice exam to help you determine your readiness for our professional-level Cloud Architect certification exam. Even if you have years of industry experience and taken all the right training courses, you now have a quick way to gauge whether you’re ready to be certified as a Cloud Architect.

The practice exam gives you 20 multiple-choice questions similar to those you might find on the actual exam. Once you complete it, we tell you which questions you answered correctly and incorrectly, so you can get a sense of how much more you need to prepare.

Here’s a sample question. The diagram below shows a typical CI/CD pipeline. Which GCP services should you use in boxes 1, 2, and 3?



That was a snap, right? Want to try some more? The practice exam is on our website and it’s available at no charge. Unlike an actual exam, there is no time limit; however, we do recommend you check yourself at 45 minutes to simulate exam conditions. Keep in mind that the actual Cloud Architect certification exam has more questions and lasts up to 120 minutes.

And no, the practice exam questions do not appear on the certification exam, although they are closely aligned.

So go ahead and take the Cloud Architect certification practice exam. You’ll be one step closer to Carnegie Hall.

By Paul Nash, Group Product Manager, Compute Engine

We are pleased to announce that we’re extending per-second billing, with a one minute minimum, to Compute Engine, Container Engine, Cloud Dataproc, and App Engine flexible environment VMs. These changes are effective today and are applicable to all VMs, including Preemptible VMs and VMs running our premium operating system images including Windows Server, Red Hat Enterprise Linux (RHEL), and SUSE Enterprise Linux Server.

These offerings join Persistent Disks, which has been billed by the second since its launch in 2013, as well as committed use discounts and GPUs; both of which have used per-second billing since their introduction.

In most cases, the difference between per-minute and per-second billing is very small -- we estimate it as a fraction of a percent. On the other hand, changing from per-hour billing to per-minute billing makes a big difference for applications (especially websites, mobile apps and data processing jobs) that get traffic spikes. The ability to scale up and down quickly could come at a significant cost if you had to pay for those machines for the full hour when you only needed them for a few minutes.

Let’s take an example. If, on average, your VM lifetime was being rounded up by 30 seconds with per-minute billing, then your savings from running 2,600 vCPUs each day would be enough to pay for your morning coffee (at 99 cents, assuming you can somehow find coffee for 99 cents). By comparison, the waste from per-hour billing would be enough to buy a coffee maker every morning (over $100 in this example).

As you can see, the value of increased billing precision is mostly in per-minute. This is probably why we haven’t heard many customers asking for per-second. But, we don’t want to make you choose between your morning coffee and your core hours, so we’re pleased to bring per-second billing to your VMs, with a one-minute minimum.

We’ve spent years focusing on real innovation for your benefit and will continue to do so. Being first with automatic discounts for use (sustained use discounts), predictably priced VMs for non-time sensitive applications (Preemptible VMs), the ability to pick the amount of RAM and vCPUs that you want (custom machine types), billing by the minute, and commitments that don’t force you to lock into pre-payments or particular machine types/families/zones (committed use discounts).

We will continue to build new ways for you to save money and we look forward to seeing how you push the limits of Google Cloud to make the previously impossible, possible.

To get started with Google Cloud Platform, sign up today and get $300 in free credits.