Google Cloud announces the Beta of single tenant instances

One of the characteristics of cloud computing is that when you launch a virtual machine, it gets distributed wherever it makes the most sense for the cloud provider. That usually means sharing servers with other customers in what is known as a multi-tenant environment. But what about times when you want a physical server dedicated just to you?

To help meet those kinds of demands, Google announced the Beta of Google Compute Engine Sole-tenant nodes, which have been designed for use cases such a regulatory or compliance where you require full control of the underlying physical machine, and sharing is not desirable.

“Normally, VM instances run on physical hosts that may be shared by many customers. With sole-tenant nodes, you have the host all to yourself,” Google wrote in a blog post announcing the new offering.

Diagram: Google

Google has tried to be as flexible as possible, letting the customer choose exactly what configuration they want in terms CPU and memory. Customers can also let Google choose the dedicated server that’s best at any particular moment, or you can manually select the server if you want that level of control. In both cases, you will be assigned a dedicated machine.

If you want to play with this, there is a free tier and then various pricing tiers for a variety of computing requirements. Regardless of your choice, you will be charged on a per-second basis with a one-minute minimum charge, according to Google.

Since this feature is still in Beta, it’s worth noting that it is not covered under any SLA. Microsoft and Amazon have similar offerings.


By Ron Miller

Four years after release of Kubernetes 1.0, it has come long way

On June 6th, 2014 Kubernetes 1.0 was released. At the time, nobody could have predicted that 4 years later that the project would become a de facto standard for container orchestration or that the biggest tech companies in the world would be backing it. That would come later.

If you think back to June 2014, containerization was just beginning to take off thanks to Docker, which was popularizing the concept with developers, but being so early there was no standard way to manage those containers.

Google had been using containers as a way to deliver applications for years and ran a tool called Borg to handle orchestration. It’s called an orchestrator because much like a conductor of an orchestra, it decides when a container is launched and when it shuts down once it’s completed its job.

At the time, two Google engineers, Craig McLuckie and Joe Beda, who would later go on to start Heptio, were looking at developing an orchestration tool like Borg for companies that might not have the depth of engineering talent of Google to make it work. They wanted to spread this idea of how they develop distributed applications to other developers.

Hello world

Before that first version hit the streets, what would become Kubernetes developed out of a need for an orchestration layer that Beda and McLuckie had been considering for a long time. They were both involved in bringing Google Compute Engine, Google’s Infrastructure as a Service offering, to market, but they felt like there was something missing in the tooling that would fill in the gaps between infrastructure and platform service offerings.

“We had long thought about trying to find a way to bring a sort of a more progressive orchestrated way of running applications in production. Just based on our own experiences with Google Compute Engine, we got to see firsthand some of the challenges that the enterprise faced in moving workloads to the cloud,” McLuckie explained.

He said that they also understood some of the limitations associated with virtual machine-based workloads and they were thinking about tooling to help with all of that. “And so we came up the idea to start a new project, which ultimately became Kubernetes.”

Let’s open source it

When Google began developing Kubernetes in March 2014, it wanted nothing less than to bring container orchestration to the masses. It was a big goal and McLuckie, Beda and teammate Brendan Burns (and later Tim Hockin) believed the only way to get there was to open source the technology and build a community around it. As it turns out, they were spot on with that assessment, but couldn’t have been 100 percent certain at the time. Nobody could have.

Photo: Cloud Native Computing Foudation

“If you look at the history, we made the decision to open source Kubernetes and make it a community-oriented project much sooner than conventional wisdom would dictate and focus on really building a community in an open and engaged fashion. And that really paid dividends as Kubernetes has accelerated and effectively become the standard for container orchestration,” McLuckie said.

The next thing they did was to create the Cloud Native Computing Foundation (CNCF) as an umbrella organization for the project. If you think about it, this project could have gone in several directions, as current CNCF director Dan Kohn described in a recent interview.

Going cloud native

Kohn said Kubernetes was unique in a couple of ways. First of all, it was based on existing technology developed over many years at Google. “Even though Kubernetes code was new, the concepts and engineering and know-how behind it was based on 15 years at Google building Borg (And a Borg replacement called Omega that failed),” Kohn said. The other thing was that Kubernetes was designed from the beginning to be open sourced.

Photo: Swapnil Bhartiya on Flickr. Used under CC by SA 2.0 license

He pointed out that Google could have gone in a few directions with Kubernetes. It could have created a commercial product and sold it through Google Cloud. It could have open sourced it, but had a strong central lead as they did with Go. They could have gone to the Linux Foundation and said they wanted to create a stand-alone Kubernetes Foundation. But they didn’t do any of these things.

McLuckie says they decided to something entirely different and place it under the auspices of the Linux Foundation, but not as Kubernetes project. Instead they wanted to create a new framework for cloud native computing itself and the CNCF was born. “The CNCF is a really important staging ground, not just for Kubernetes, but for the technologies that needed to come together to really complete the narrative, to make Kubernetes a much more comprehensive framework,” McLuckie explained.

Getting everyone going in the same direction

Over the last few years, we have watched as Kubernetes has grown into a container orchestration standard. Last summer in quick succession  a slew of major enterprise players joined CNCF as AWSOracleMicrosoftVMware and Pivotal all joined. They came together with Red Hat, Intel, IBM Cisco and others who were already members.

Cloud Native Computing Foundation Platinum members

Each these players no doubt wanted to control the orchestration layer, but they saw Kubernetes gaining momentum so rapidly, they had little choice but to go along. Kohn jokes that having all these big name players on board is like herding cats, but bringing in them in has been the goal all along. He said it just happened much faster than he thought it would.

In a recent interview with TechCrunch, David Aronchick, who runs the open source Kubeflow Kubernetes machine learning project at Google, was running Kubernetes in the early days. He is shocked by how quickly it has grown. “I couldn’t have predicted it would be like this. I joined in January, 2015 and took on project management for Google Kubernetes. I was stunned at the pent up demand for this kind of thing,” he told TechCrunch.

As it has grown, it has become readily apparent that McLuckie was right about building that cloud native framework instead of a stand-alone Kubernetes foundation. Today there are dozens of adjacent projects and the organization is thriving.

Nobody is more blown away by this than McLuckie himself who says seeing Kubernetes hit these various milestones since its 1.0 release has been amazing for him and his team to watch. “It’s just been a series of these wonderful kind of moments as Kubernetes has gained a head of steam, and it’s been  so much fun to see the the community really rally around it.”


By Ron Miller

The new Gmail will roll out to all users next month

Google today announced that the new version of Gmail will launch into general availability and become available to all G Suite users next month. The exact date remains up in the air but my guess is that it’ll be sooner than later.

The new Gmail offers features like message snoozing, attachment previews, a sidebar for both Google apps like Calendar and third-party services like Trello, offline support, confidential messages that self-destruct after a set time, and more. It’s also the only edition of Gmail that currently allows you to try out Smart Compose, which tries to complete your sentences for you.

Here is what the rollout will look like for G Suite users. Google didn’t detail what the plan for regular users will look like, but if you’re not a G Suite user, you can already try the new Gmail today anyway and chances are stragglers will also get switched over to the new version at a similar pace as G Suite users.

Starting in July, G Suite admins will be able to immediately transition all of their users to the new Gmail, but users can still opt out for another twelve weeks. After that time is up, all G Suite users will move to the new Gmail experience.

Admins can also give users the option to try the new Gmail at their own pace or — and this is the default setting — they can just wait another four weeks and then Google will automatically give users the option to opt in.

Eight weeks after general availability, so sometime in September, all users will be migrated automatically but can still opt out for another four weeks.

That all sounds a bit more complicated than necessary, but the main gist here is: chances are you’ll get access to the new Gmail next month and if you hate it, you can still opt out for a bit longer. Then, if you still hate it, you are out of luck because come October, you will be using the new Gmail no matter what.


By Frederic Lardinois

Kubernetes stands at an important inflection point

Last week at KubeCon and CloudNativeCon in Copenhagen, we saw an open source community coming together, full of vim and vigor and radiating positive energy as it recognized its growing clout in the enterprise world. This project, which came out of Google just a few years ago, has gained acceptance and popularity astonishingly rapidly — and that has raised both a sense of possibility and a boat load of questions.

At this year’s European version of the conference, the community seemed to be coming to grips with that rapid growth as large corporate organizations like Red Hat, IBM, Google, AWS and VMware all came together with developers and startups trying to figure out exactly what they had here with this new thing they found.

The project has been gaining acceptance as the defacto container orchestration tool, and as that happened, it was no longer about simply getting a project off the ground and proving that it could work in production. It now required a greater level of tooling and maturity that previously wasn’t necessary because it was simply too soon.

As this has happened, the various members who make up this growing group of users, need to figure out, mostly on the fly, how to make it all work when it is no longer just a couple of developers and a laptop. There are now big boy and big girl implementations and they require a new level of sophistication to make them work.

Against this backdrop, we saw a project that appeared to be at an inflection point. Much like a startup that realizes it actually achieved the product-market fit it had hypothesized, the Kubernetes community has to figure out how to take this to the next level — and that reality presents some serious challenges and enormous opportunities.

A community in transition

The Kubernetes project falls under the auspices of the Cloud Native Computing Foundation (or CNCF for short). Consider that at the opening keynote, CNCF director Dan Kohn was brimming with enthusiasm, proudly rattling off numbers to a packed audience, showing the enormous growth of the project.

Photo: Ron Miller

If you wanted proof of Kubernetes’ (and by extension cloud native computing’s) rapid ascension, consider that the attendance at KubeCon in Copenhagen last week numbered 4300 registered participants, triple the attendance in Berlin just last year.

The hotel and conference center were buzzing with conversation. Every corner and hallway, every bar stool in the hotel’s open lobby bar, at breakfast in the large breakfast room, by the many coffee machines scattered throughout the venue, and even throughout the city, people chatted, debated and discussed Kubernetes and the energy was palpable.

David Aronchick, who now runs the open source Kubeflow Kubernetes machine learning project at Google, was running Kubernetes in the early days (way back in 2015) and he was certainly surprised to see how big it has become in such a short time.

“I couldn’t have predicted it would be like this. I joined in January, 2015 and took on project management for Google Kubernetes. I was stunned at the pent up demand for this kind of thing,” he said.

Growing up

Yet there was great demand, and with each leap forward and each new level of maturity came a new set of problems to solve, which in turn has created opportunities for new services and startups to fill in the many gaps. As Aparna Sinha, who is the Kubernetes group product manager at Google, said in her conference keynote, enterprise companies want some level of certainty that earlier adopters were willing to forego to take a plunge into the new and exciting world of containers.

Photo: Cloud Native Computing Foundation

As she pointed out, for others to be pulled along and for this to truly reach another level of adoption, it’s going to require some enterprise-level features and that includes security, a higher level of application tooling and a better overall application development experience. All these types of features are coming, whether from Google or from the myriad of service providers who have popped up around the project to make it easier to build, deliver and manage Kubernetes applications.

Sinha says that one of the reasons the project has been able to take off as quickly as it has, is that its roots lie in a container orchestration tool called Borg, which the company has been using internally for years. While that evolved into what we know today as Kubernetes, it certainly required some significant repackaging to work outside of Google. Yet that early refinement at Google gave it an enormous head start over an average open source project — which could account for its meteoric rise.

“When you take something so well established and proven in a global environment like Google and put it out there, it’s not just like any open source project invented from scratch when there isn’t much known and things are being developed in real time,” she said.

For every action

One thing everyone seemed to recognize at KubeCon was that in spite of the head start and early successes, there remains much work to be done, many issues to resolve. The companies using it today mostly still fall under the early adopter moniker. This remains true even though there are some full blown enterprise implementations like CERN, the European physics organization, which has spun up 210 Kubernetes clusters or JD.com, the Chinese Internet shopping giant, which has 20K servers running Kubernetes with the largest cluster consisting of over 5000 servers. Still, it’s fair to say that most companies aren’t that far along yet.

Photo: Ron Miller

But the strength of an enthusiastic open source community like Kubernetes and cloud native computing in general, means that there are companies, some new and some established, trying to solve these problems, and the multitude of new ones that seem to pop up with each new milestone and each solved issue.

As Abbie Kearns, who runs another open source project, the Cloud Foundry Foundation, put it in her keynote, part of the beauty of open source is all those eyeballs on it to solve the scads of problems that are inevitably going to pop up as projects expand beyond their initial scope.

“Open source gives us the opportunity to do things we could never do on our own. Diversity of thought and participation is what makes open source so powerful and so innovative,” she said.

It’s worth noting that several speakers pointed out that diversity of thought also required actual diversity of membership to truly expand ideas to other ways of thinking and other life experiences. That too remains a challenge, as it does in technology and society at large.

In spite of this, Kubernetes has grown and developed rapidly, while benefiting from a community which so enthusiastically supports it. The challenge ahead is to take that early enthusiasm and translate it into more actual business use cases. That is the inflection point where the project finds itself, and the question is will it be able to take that next step toward broader adoption or reach a peak and fall back.


By Ron Miller

Google Kubeflow, machine learning for Kubernetes, begins to take shape

Ever since Google created Kubernetes as an open source container orchestration tool, it has seen it blossom in ways it might never have imagined. As the project gains in popularity, we are seeing many adjunct programs develop. Today, Google announced the release of version 0.1 of the Kubeflow open source tool, which is designed to bring machine learning to Kubernetes containers.

While Google has long since moved Kubernetes into the Cloud Native Computing Foundation, it continues to be actively involved, and Kubeflow is one manifestation of that. The project was only first announced at the end of last year at Kubecon in Austin, but it is beginning to gain some momentum.

David Aronchick, who runs Kubeflow for Google, led the Kubernetes team for 2.5 years before moving to Kubeflow. He says the idea behind the project is to enable data scientists to take advantage of running machine learning jobs on Kubernetes clusters. Kubeflow lets machine learning teams take existing jobs and simply attach them to a cluster without a lot of adapting.

With today’s announcement, the project begins to move ahead, and according to a blog post announcing the milestone, brings a new level of stability, while adding a slew of new features that the community has been requesting. These include Jupyter Hub for collaborative and interactive training on machine learning jobs and Tensorflow training and hosting support, among other elements.

Aronchick emphasizes that as an open source project you can bring whatever tools you like, and you are not limited to Tensorflow, despite the fact that this early version release does include support for Google’s machine learning tools. You can expect additional tool support as the project develops further.

In just over 4 months since the original announcement, the community has grown quickly with over 70 contributors, over 20 contributing organizations along with over 700 commits in 15 repositories. You can expect the next version, 0.2, sometime this summer.


By Ron Miller

Google Cloud expands its bet on managed database services

Google announced a number of updates to its cloud-based database services today. For the most part, we’re not talking about any groundbreaking new products here but all of these updates address specific pain points that enterprises suffer when they move to the cloud.

As Google Director of Product Management Dominic Preuss told me ahead of today’s announcements, Google long saw itself as a thought leader in the database space. For the longest time, though, that thought leadership was all about things like the Bigtable paper and didn’t really manifest itself in the form of products. Projects like the globally distributed Cloud Spanner database are now allowing Google Cloud to put its stamp on this market.

Preuss also noted that many of Google’s enterprise users often start with lifting and shifting their existing workloads to the cloud. Once they have done that, though, they are also looking to launch new applications in the cloud — and at that point, they typically want managed services that free them from having to do the grunt work of managing their own infrastructure.

Today’s announcements mostly fit into this mold of offering enterprises the kind of managed database services they are asking for.

The first of these is the beta launch of Cloud Memorystore for Redis, a fully managed in-memory data store for users who need in-memory caching for capacity buffering and similar use cases.

Google is also launching a new feature for Cloud Bigtable, the company’s NoSQL database service for big data workloads. Bigtable now features regional replication (or at least it will, once this has rolled out to all users within the next week or so). The general idea here is to give enterprises that previously used Cassandra for their on-premises workloads an alternative in the Google Cloud portfolio and these cross-zone replications increase the availability and durability of the data they store in the service.

With this update, Google is also making Cloud SQL for PostgreSQL generally available with a 99.95 percent SLA and it’s adding commit timestamps to Cloud Spanner.

What’s next for Google’s database portfolio? Unsurprisingly, Preuss wouldn’t say, but he did note that the company wants to help enterprises move as many of their workloads to the cloud as they can — and for the most part, that means managed services.


By Frederic Lardinois

Google Cloud releases Dialogflow Enterprise Edition for building chat apps

Building conversational interfaces is a hot new area for developers. Chatbots can be a way to reduce friction in websites and apps and to give customers quick answers to commonly asked questions in a conversational framework. Today, Google announced it was making Dialogflow Enterprise Edition generally available. It had previously been in Beta.

This technology came to them via the API.AI acquisition in 2016. Google wisely decided to change the name of the tool along the way, giving it a moniker that more closely matched what it actually does. The company reports that hundreds of thousands are developers are using the tool already to build conversational interfaces.

This isn’t just an all-Google tool though. It works across voice interface platforms including Google Assistant, Amazon Alexa and Facebook Messenger, giving developers a tool to develop their chat apps once and use them across several devices without having to change the underlying code in a significant way.

What’s more, with today’s release the company is providing increased functionality and making it easier to transition to the enterprise edition at the same time.

“Starting today, you can combine batch operations that would have required multiple API calls into a single API call, reducing lines of code and shortening development time. Dialogflow API V2 is also now the default for all new agents, integrating with Google Cloud Speech-to-Text, enabling agent management via API, supporting gRPC, and providing an easy transition to Enterprise Edition with no code migration,” Dan Aharon Google’s product manager for Cloud AI wrote in a company blog post announcing the tool.

The company showed off a few new customers using Dialogflow to build chat interfaces for their customers including KLM Royal Dutch Airlines, Domino’s and Ticketmaster.

The new tool, which is available today, supports over 30 languages and as a generally available enterprise product comes with a support package and service level agreement (SLA).

Google Cloud gives developers more insights into their networks

Google Cloud is launching a new feature today that will give its users a new way to monitor and optimize how their data flows between their servers in the Google Cloud and other Google Services, on-premises deployments and virtually any other internet endpoint. As the name implies, VPC Flow Logs are meant for businesses that already use Google’s Virtual Private Cloud features to isolate their resources from other users.

VPC Flow Logs monitors and logs all the network flows (both UDP and TCP) that are sent from and received by the virtual machines inside a VPC, including traffic between Google Cloud regions. All of that data can be exported to Stackdriver Logging or BigQuery, if you want to keep it in the Google Cloud, or you can use Cloud Pub/Sub to export it to other real-time analytics or security platform. The data updates every five seconds and Google premises that using this service has no impact on the performance of your deployed applications.

As the company notes in today’s announcement, this will allow network operators to get far more insights into the details of how the Google network performs and to troubleshoot issues if they arise. In addition, it will also allow them to optimize their network usage and costs by giving them more information about their global traffic.

All of this data is also quite useful for performing forensics when it looks like somebody may have gotten into your network, too. If that’s your main use case, though, you probably want to export your data to a specialized security information and event management (SIEM) platform from vendors like Splunk or ArcSight.

Hewlett Packard Enterprise to move HQ to San Jose

Hewlett Packard Enterprise is moving north from Palo Alto to San Jose. The company will relocate 1,000 employees to a 220,000 square feet space in late 2018. HPE is was spun off from Hewlett-Packard in 2015 and is focused on servers and storage.

This news comes months after HPE announced a different plan in which the company was moving to Santa Clara where Aruba Networks, a company it previously acquired, is headquartered.

HPE is going to occupy six floors in San Jose’s America Center, which is located near a forthcoming Berryessa BART station.

This move is the latest win for San Jose. Google recently announced it would move in the coming years. According to a report in Mercury News, the city of San Jose did not offer HPE any financial incentives.

Google expands its Cloud Platform region in the Netherlands

Google today announced that it has expanded its recently launched Cloud Platform region in the Netherlands with an additional zone. The investment, which is worth a reported 500 million euros, expands the existing Netherlands region from two to three regions. With this, all the four central European Google Cloud Platform zones now feature three zones (which are akin to what AWS would call “availability zones”) that allow developers to build highly available services across multiple data centers.

Google typically aims to have a least three zones in every region, so today’s announcement to expand its region in the Dutch province of Groningen doesn’t come as a major surprise.

With this move, Google is also making Cloud SpannerCloud BigtableManaged Instance Groups, and Cloud SQL available in the region.

Over the course of the last two years, Google has worked hard to expand its global data center footprint. While it still can’t compete with the likes of AWS and Azure, which currently offers more regions than any of its competitors, the company now has enough of a presence to be competitive in most markets.

In the near future, Google also plans to open regions in Los Angeles, Finland, Osaka and Hong Kong. The major blank spots on its current map remain Africa, China (for rather obvious reasons) and Eastern Europe, including Russia.