Posted by Filip Balejko, Software Engineer

Here at Google Cloud Platform, we're working tirelessly toward making Google Compute Engine the first place you turn when you need a scalable, manageable and reliable cloud on which to run your virtual machines.

A Managed Instance Group is a group of machines that are all built off the same instance template and is the foundation for easily building scalable, reliable systems. It lets you auto-heal VM instances by monitoring the state of machines and applications and recreating them when needed. It allows you to autoscale and load-balance to help you serve requests no matter the traffic growth. It also gives you the means to perform rolling updates on your software while it'a running, without any interruption.

Managed Instance Groups just got even better! For applications that require high availability, we're announcing the beta of Regional Managed Instance Groups. Now when you select a multi-zone configuration, Compute Engine automatically spreads the VMs across three zones in the same region equally, so that even in the rare case of a zone-level outage, two thirds of the instances continue to serve. When Autoscaler is enabled, it automatically adds instances to handle the increased traffic in other zones. You can further protect your system by overprovisioning your Regional Managed Instance Group.

This feature has been in the hands of select alpha partners for several months. We’re now ready to open it up to a wider range of Compute Engine users, across all Compute Engine regions. Click here for more information about regional managed instance groups

Posted by Craig McLuckie, Co-founder of Kubernetes and Senior Product Manager at Google

"So let me get this straight. You want to build an external version of the Borg task scheduler. One of our most important competitive advantages. The one we don’t even talk about externally. And, on top of that, you want to open source it?"

The story of how Kubernetes came to be starts here. It was Summer 2013, and we were in a room with Urs Holzle, head of technical infrastructure and chief architect of many of Google’s most important network innovations. We were pitching him our idea to build an open source container management system. But it wasn’t going well. Or so we thought.

To really understand how we ended up in that meeting, you have to back up a bit. For years, Google had been quietly building some of the best network infrastructure to power intensive online services like Google Search, Gmail and YouTube. We built everything from scratch because we had to, and in the early days, we were on a tight budget. In order to wring every possible ounce of performance out of our servers, we had started experimenting with containers over a decade ago. We built a cluster management system called Borg, which runs hundreds of thousands of jobs and makes computing much more efficient — allowing us to run our data centers at high utilization.

Later, we used this same infrastructure to deliver Google Cloud Platform, so anyone could use it for their computing needs. However, with the launch of our Infrastructure-as-a-Service platform Google Compute Engine, we noticed an interesting problem: customers were paying for a lot of CPUs, but their utilization rates were extremely low because they were running VMs. We knew we had an internal solution for this. And what’s more, we knew that containers were the future of computing — they’re scalable, portable and more efficient. The container system Docker was already up and running, and we thought it was great. But the trick, which we knew through years of trial and error within Google, was a great container management system. That’s what we wanted to build.

Even though we had been rejected before, we didn’t give up. Good ideas usually win out at Google, and we were convinced this was a good idea. We met with anyone who would listen to us to pitch the idea. A turning point was a fateful shuttle ride where I found myself sitting next to Eric Brewer, VP of Cloud, and one of Urs’s key strategists. I had an uninterrupted chunk of time to explain the idea to Eric, and he was convinced. Soon after, we got the green light from Urs.

In keeping with the Borg theme, we named it Project Seven of Nine. (Side note: in an homage to the original name, this is also why the Kubernetes logo has seven sides.) We wanted to build something that incorporated everything we had learned about container management at Google through the design and deployment of Borg and its successor, Omega — all combined with an elegant, simple and easy-to-use UI. In three months, we had a prototype that was ready to share.

We always believed that open-sourcing Kubernetes was the right way to go, bringing many benefits to the project. For one, feedback loops were essentially instantaneous — if there was a problem or something didn’t work quite right, we knew about it immediately. But most importantly, we were able to work with lots of great engineers, many of whom really understood the needs of businesses who would benefit from deploying containers (have a look at the Kubernetes blog for perspectives from some of the early contributors). It was a virtuous cycle: the work of talented engineers led to more interest in the project, which further increased the rate of improvement and usage.
What started as an internal summer conversation has evolved into a global movement. Kubernetes is now deployed in thousands of organizations (e.g., Box), supported by over 830 contributors that have collectively put in 237 person years of coding effort to date. Velocity that even our wildest goals didn’t anticipate. To our contributing peers and community advocates, a sincere thank you for making Kubernetes so welcoming and transparent. And to you Kubernetes, a very happy birthday to you!
If you haven’t tried Kubernetes, it’s easy to get started using Google Container Engine; begin your 60-day free trial here. And to learn more about the Kubernetes story, check out the Kubernetes Origins podcast on Software Engineering Daily.

Posted by Apoorv Saxena, Cloud Natural Language and Translate API Product Manager, Dan Aharon, Cloud Speech API Product Manager and Dave Stiver, Product Manager, Google Cloud Platform


Following our announcements from GCP NEXT in March, we’re excited to share updates about Cloud Platform expansion and machine learning. Today we’re launching two new Machine Learning APIs into open beta and expanding our footprint in the United States.

Cloud Machine Learning APIs enter open beta

Google Cloud Platform unlocks the capability for enterprises to process unstructured data through machine learning. Today, we’re announcing two new Cloud Machine Learning products that are entering beta: Cloud Natural Language and Cloud Speech APIs.

We spend a lot of time thinking about how computer systems can read in order to process human language in intelligent ways. For example, we most recently open-sourced SyntaxNet (which includes Parsey McParseface), a natural language model that analyzes the grammatical structure of text with the best accuracy, speed and scale.

The new Google Cloud Natural Language API in open beta is based on our natural language understanding research. Cloud Natural Language lets you easily reveal the structure and meaning of your text in a variety of languages, with initial support for English, Spanish and Japanese. It includes:

• Sentiment Analysis: Understand the overall sentiment of a block of text
• Entity Recognition: Identify the most relevant entities for a block of text and label them with types such as person, organization, location, events, products and media
• Syntax Analysis: Identify parts of speech and create dependency parse trees for each sentence to reveal the structure and meaning of text

The new API is optimized to meet the scale and performance needs of developers and enterprises in a broad range of industries. For example, digital marketers can analyze online product reviews or service centers can determine sentiment from transcribed customer calls. We’ve also seen great results from our Alpha customers, including British online marketplace Ocado Technology.

To see Cloud Natural Language API in action, check out our demo that uses Cloud Natural Language to analyze top stories from The New York Times.

Google’s Cloud Natural Language API has shown it can accelerate our offering in the natural language understanding area and is a viable alter native to a custom model we had built for our initial use case.                                                              - Dan Nelson, Head of Data, Ocado Technology

Cloud Speech API will also enter open beta today. Enterprises and developers now have access to speech-to-text conversion in over 80 languages, for both apps and IoT devices. Cloud Speech API uses the voice recognition technology that has been powering your favorite products such as Google Search and Google Now.

More than 5,000 companies signed up for Speech API alpha, including:

• HyperConnect, a video chat app with over 50 million downloads in over 200 countries, uses a combination of our Cloud Speech and Translate API to automatically transcribe and translate conversations between people who speak different languages.
• VoiceBase, a leader in speech analytics as a service, uses Speech API to let developers surface insights and predict outcomes from call recordings.

This beta version adds new features based on customer feedback from alpha, such as:

• Word hints: custom words or phrases by context can be added to API calls to improve recognition. Useful for both command scenarios (e.g., a smart TV listening for “rewind” and “fast-forward” when watching a movie) and adding new words to the dictionary (e.g., recognizing names that may not be common in a specific language)
• Asynchronous calling: the API has been substantially simplified with new asynchronous calls that make developing voice-enabled apps easier and faster

To use our newest machine learning APIs in open beta and see more details about pricing, check out Cloud Natural Language and Cloud Speech on our website.

Google Cloud Platform expands on the North American West Coast

For Cloud Platform customers on the west coast of North America and Canada, we’re pleased to announce our Oregon Cloud Region (us-west1) is now open for business. This region initially includes three of our core offerings: Google Compute Engine, Google Cloud Storage and Google Container Engine, and features two Compute Engine zones to support high availability applications.

Our initial testing shows that users in cities such as Vancouver, Seattle, Portland, San Francisco and Los Angeles can expect to see a 30-80% reduction in latency for applications served from us-west1, compared to us-central1.

One industry where latency is critical is gaming. Players of today’s premium games expect twitch-fast networks to enable immersive, real-time gaming experiences. Multiplay is a unique video game hosting specialist behind many of today’s top AAA games. Multiplay’s games hosted out of the new us-west1 data center ensures that players in the western region of North America have a consistent, fast user experience on top of Google Cloud Platform.

Regional latency is a major factor in the gaming experience. Google Cloud Platform’s network is one of the best we’ve worked with, from a tech perspective but also in terms of the one-on-one support we’ve received from the team.                                                                                                                                                       - Paul Manuel, Director of Multiplay Game Services

And as we announced in March, Tokyo will be coming online later this year and we will announce more than 10 additional regions in 2017. For a current list of GCP regions, please have a look at the Cloud Locations page.

Posted by Steren Giannini, Product Manager, Google Cloud Platform

The combination of Google App Engine and Stackdriver Error Reporting is a powerful one. App Engine allows you to focus on your application without having to worry about the underlying infrastructure. Error Reporting, meanwhile, provides visibility into your application's health so that you can focus on relevant errors, detect new problems early and ultimately increase the quality of your application.

After a short beta period during which we fine-tuned the grouping algorithms and made sure it scaled for our biggest customers, Stackdriver Error Reporting is now generally available on Google App Engine standard environment. No setup is required — it just works out of the box for Java, Python, Go and PHP applications in the App Engine standard environment.

See your top application errors on the App Engine dashboard (click to enlarge)

Stackdriver Error Reporting works by automatically analyzing App Engine error logs, extracting more than one thousand stack traces per second in order to group and count them. You can opt to receive email notifications when there’s a new error that was never seen before. The report page lists which services and versions are affected, when the error was first seen and relevant exception stack frames.

Stackdriver Error Reporting shows affected versions, stack traces and a link to the request log (click to enlarge)

Early adopters of Stackdriver Error Reporting have very positive feedback.

We've been in search of a solution like this and were about to try wiring together various vendor solutions. Stackdriver Error Reporting really hits the mark and has immediately uncovered issues that had been unnoticed in production. I credit this tool with raising the quality and user experience of our product to a huge degree.
                                                                                    - John Koehl, CTO at Batterii

Visit http://console.cloud.google.com/errors to see any errors in your App Engine project.

Posted by Paul Newson, Mission Controller


Wait. That’s not Google. That’s Houston.

We do have a Mission Control at Google, named in honor of NASA’s Christopher C. Kraft Jr. Mission Control Center, pictured here. But at Google, Mission Control is not a place. It’s a six month rotation program for engineers working on product development to experience what it’s like to be a Site Reliability Engineer (SRE). The goal is to increase the number of engineers who understand the challenges of building and operating a high reliability service at Google's scale.

The Mission Control inspiration goes further; SREs at Google are issued jackets that bear a flight patch inspired by the one Gene Kranz had commissioned for the Mission Controllers in Houston ¹. It bears the “Kranz Dictum” of “Tough and Competent” in Latin: “Duri et Periti”. If you see someone wearing a leather jacket with this flight patch, you’re looking at a Google SRE.
But what is an SRE? According to Google Vice President of Engineering Ben Treynor Sloss, who coined the term SRE, “SRE is what happens when you ask a software engineer to design an operations function.” In 2003, Ben was asked to lead Google’s existing “Production Team” which at the time consisted of seven software engineers. The team started as a software engineering team, and since Ben is also a software engineer, he continued to grow a team that he, as a software engineer, would still want to work on. Thirteen years later, Ben leads a team of roughly 2,000 SREs, and it is still a team that software engineers want to work on. About half of the engineers who do a Mission Control rotation choose to remain an SRE after their rotation is complete.

Google has been putting the word out about SRE for the past couple of years. Ben gave a talk at SREcon14 where he shared the principles of SRE learned over 11 years of building the team at Google. Melissa Binde gave a talk at GCP Next 2016 where she provided some pointers on how to apply some of the techniques we use at Google to your workloads running in our cloud. And if you really want to dig deep, the Site Reliability Engineering book is now available, and highly recommended reading.

Over the next six months, I will be on the uncomfortably exciting adventure of my own Mission Control rotation with the SRE team in Seattle that looks after Google Compute Engine. I will also be sharing some of the things I learn along the way with everyone here on this blog. So, if you want to learn more about being an SRE and how Site Reliability Engineering impacts our cloud services, keep watching this space.

---

1 http://genedorr.com/patches/Ground.html

Posted by Belwadi Srikanth, Senior Product Manager, Google Cloud Platform

Today, we're excited to announce that Anvato is joining the Google Cloud Platform team. Anvato provides a software platform that fully automates the encoding, editing, publishing and secure distribution of video content across multiple platforms.

Anvato’s Media Content Platform, which counts many large media companies as customers, will complement our efforts to enable scalable media processing and workflows in the cloud.

The cloud is transforming the way video content is created and distributed to an array of connected devices, as well as the way users engage with this content. And in recent years, the adoption of over-the-top (OTT) technologies has emerged as a critical platform for delivering rich audio, video and other media via the Internet.

With OTT adoption rapidly accelerating, the Cloud Platform and Anvato teams will work together to deliver cloud solutions that help businesses in the media and entertainment industry scale their video infrastructure efforts and deliver high-quality, live video and on-demand content to consumers on any device — be it their smartphone, tablet or connected television.

The Google Cloud Platform team is committed to helping our customers in the media and entertainment industry manage their infrastructure more efficiently, provision servers and networks at rapid scale and remove unnecessary overhead. We’re thrilled to have the Anvato team join us in our mission.

We’ll have more details to share in the coming months — stay tuned!

Posted Shao-horng Yong, Google Cloud Platform, APAC Sales Engineer


Rayark, a mobile game developer founded in 2011, has published several award-winning games that have garnered millions of downloads. Earlier this month, it launched VOEZ, which is running in production on Google Container Engine (GKE).

Rayark chose to build VOEZ with containers because it wanted to make the game portable across clouds. In the gaming business, it's common for local game publishers to host a game on a separate infrastructure, for improved network latency and to satisfy regional go-to-market demands. Containers’ portable architecture plus Kubernetes will make it easy for Rayark to replicate VOEZ to companies who don't share its infrastructure. Containers also make more efficient use of underlying resources. Moreover, because containers’ underlying OS is already running, they can scale to handle burst demands much faster than virtual machines.

Two weeks after launch, VOEZ had already reached 2 million downloads, but for Rayark CTO Alvin Chung, that success was anything but assured. After all, one study showed that 86% of users deleted or uninstalled apps due to performance issues. Leading up to the launch, Chung wondered whether going with Container Engine was the right choice, whether the backend infrastructure would scale, whether the container technology would behave as expected, and whether Google Cloud Platform would provide the after-sales service that matched its marketing and pre-sales talk.

The answers to these questions started to unfold during beta testing, when 10,000 fans were invited to download VOEZ. The front-end HTTPS Load Balancer scaled seamlessly without any warm-up, but when Rayark conducted large-scale load testing, it started to see some potential bottlenecks. Cloud Platform’s solution architects team advised scaling Container Engine with DNS pods, sharding Redis and tracking down HTTPS connection resets that were related to Python. Once these issues were addressed, the application scaled smoothly. Front-end load balancing sees higher and higher peaks every night after 9 p.m., while backend infrastructure stays under 35% CPU utilization throughout.

Looking back, the success of the VOEZ launch was built on a number of high-level principles:

1. Take your time to produce quality software
2. Put together a strong developer team
3. Explore ways to handle load even if it means using relatively new technology
4. Think far, think big. Using open-source technology like containers ensures portability and helps avoid vendor lock-in
5. Perform large-scale testing. Your goal is for surprises to crop up as early as possible
6. Take advantage of on-site support and monitoring of the production infrastructure from Google partner and presales teams.

Hosting VOEZ on Container Engine has been a big success for Rayark. Here’s to the next two million downloads!