By Joseph Holley and Adrian Graham, Cloud Solutions Architects
Capturing logs in a visual effects (VFX), animation or games pipeline is useful for troubleshooting automated tools, keeping track of process runtimes and machine load and capturing historical data that occurs during the life of a production.
But collecting and making sense of these logs can be tricky, especially if you're working on the same project from multiple locations, or have limited resources on which to collect the logs themselves.
Collecting logs in the cloud enables you to understand this data by mining it with tools that deliver speed and power not possible from an on-premise logging server. Storage and data management is simple in the cloud and not bound by physical hardware. Additionally, you can access cloud logging resources globally; visual effects or animation facilities can access the same logging database regardless of physical location, making international productions far simpler to manage and understand.
We recently put together a tutorial that shows you how to integrate Stackdriver Logging, our hosted log management and analysis service for data running on Google Cloud Platform (GCP) and AWS, into your own visual effects or animation pipeline. It also shows some key storage strategies and how to migrate this data to BigQuery and other Google Cloud tools. Check it out, and let us know what other Google Cloud tools you’d like to learn how to use in your visual effects or animation pipeline. You can reach us on Twitter at @gcpjoe or @agrahamvfx.
Being able to diagnose application logs, errors and latency is key to understanding failures, but it can be tricky and time-consuming to implement correctly. That’s why we're happy to announce general availability of Stackdriver Diagnostics integration for ASP.NET Core applications, providing libraries to easily integrate Stackdriver Logging, Error Reporting and Trace into your ASP.NET Core applications, with a minimum of effort and code. While on the road to GA, we’ve fixed bugs, listened to and applied customer feedback, and have done extensive testing to make sure it's ready for your production workloads.
Now, let’s look at the various Google Cloud Platform (GCP) components that we integrated into this release, and how to begin using them to troubleshoot your ASP.NET Core application.
Stackdriver Logging
Stackdriver Logging allows you to store, search, analyze, monitor and alert on log data and events from GCP and AWS. Logging to Stackdriver is simple with Google.Cloud.Diagnostics.AspNetCore. The package uses ASP.NET Core’s built in logging API; simply add the Stackdriver provider and then create and use a logger as you normally would. Your logs will then show up in the Stackdriver Logging section of the Google Cloud Console.
Initializing and sending logs to Stackdriver Logging only requires a few lines of code:
public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
// Initialize Stackdriver Logging
loggerFactory.AddGoogle("YOUR-GOOGLE-PROJECT-ID");
...
}
public void LogMessage(ILoggerFactory loggerFactory)
{
// Send a log to Stackdriver Logging
var logger = loggerFactory.CreateLogger("NetworkLog");
logger.LogInformation("This is a log message.");
}
Here’s view of Stackdriver logs shown in Cloud Console:
This shows two different logs that were reported to Stackdriver. An expanded log shows its severity, timestamp, payload and many other useful pieces of information.
Stackdriver Error Reporting
Adding the Stackdriver Error Reporting middleware to the beginning of your middleware flow reports all uncaught exceptions to Stackdriver Error Reporting. Exceptions are grouped and shown in the Stackdriver Error Reporting section of Cloud Console.
Here’s how to initialize Stackdriver Error Reporting in your ASP.NET Core application:
public void ConfigureServices(IServiceCollection services)
{
services.AddGoogleExceptionLogging(options =>
{
options.ProjectId = "YOUR-GOOGLE-PROJECT-ID";
options.ServiceName = "ImageGenerator";
options.Version = "1.0.2";
});
...
}
public void Configure(IApplicationBuilder app)
{
// Use before handling any requests to ensure all unhandled exceptions are reported.
app.UseGoogleExceptionLogging();
...
}
You can also report caught and handled exceptions with the IExceptionLogger interface:
Here’s a view of Stackdriver Error Reports in Cloud Console:
This shows the occurrence of an error over time for a specific application and version. The exact error is shown on the bottom.
Stackdriver Trace
Stackdriver Trace captures latency information on all of your applications. For example, you can diagnose if HTTP requests are taking too long by using a Stackdriver Trace integration point. Similar to Error Reporting, Trace hooks into your middleware flow and should be added at the beginning of your middleware flow.
Initializing Stackdriver Trace is similar to setting up Stackdriver Error Reporting:
public void ConfigureServices(IServiceCollection services)
{
string projectId = "YOUR-GOOGLE-PROJECT-ID";
services.AddGoogleTrace(options =>
{
options.ProjectId = projectId;
});
...
}
public void Configure(IApplicationBuilder app)
{
// Use at the start of the request pipeline to ensure the entire request is traced.
app.UseGoogleTrace();
...
}
You can also manually trace a section of code that will be associated with the current request:
public void TraceHelloWorld(IManagedTracer tracer)
{
using (tracer.StartSpan(nameof(TraceHelloWorld)))
{
Console.Out.WriteLine("Hello, World!");
}
}
Here’s a view of a trace across multiple servers in Cloud Console:
This shows the time spent for portions of an HTTP request. The timeline shows both time spent on the front-end and on the back-end.
Not using ASP.NET Core?
If you are haven’t made the switch to ASP.NET Core but still want to use Stackdriver diagnostics tools, we also provide a package for ASP.NET accordingly named Google.Cloud.Diagnostics.AspNet. It provides simple Stackdriver diagnostics integration into ASP.NET applications. You can add Error Reporting and Tracing for MVC and Web API with a line of code to your ASP.NET application. And while ASP.NET does not have a logging API, we have also integrated Stackdriver Logging with log4net in our Google.Cloud.Logging.Log4Net package.
Our goal is to make GCP a great place to build and run ASP.NET and ASP.NET Core applications, and troubleshooting performance and errors is a big part of that. Let us know what you think of this new functionality, and leave us your feedback on GitHub.
In part 1 and part 2 of this series, we showed you how to build a conversational tour guide app with API.AI and Google Cloud Machine Learning APIs. In this final part, you’ll learn how to extend this app to the Google Assistant-supported devices (Google Home, eligible Android phones and iPhones, and Android Wear). And we’ll build this on top of the existing API.AI agent created in parts 1 and 2.
New Intents for Actions on Google
In part 1, we discussed the app’s input and output context relationships.
The where context requires the user to upload an image, which is not supported by the Google Assistant. We can modify the context relationship as below.
We will add three new intents, hours-no-context, ticket-no-context and map-no-context. Each intent will set location as the output context so that other intents can use the location as an input parameter.
Enable Actions on Google Integration
Now we’ll enable Actions on Google to support the Google Assistant.
Open your API.AI console. Under the Integrations Tab, turn on the Actions on Google integration.
In the popup dialog under Additional triggering intents, add all intents you want to support on the Google Assistant. The system will automatically set the Welcome Intent to Default Welcome Intent. You can also click SETTINGS under Actions on Google to bring up this settings dialog in the future. Note that the inquiry.where intent requires uploading an image and won’t work on the Google Assistant, so you should not add that intent to the triggering intents list. We discussed how to add a new intent to support that in New Intent for Actions on Google section.
After you’re done adding all the intents that we want to support on Google on Actions (e.g., hours-no-context intent) to the additional triggering intents list, hit UPDATE and TEST button on the bottom. It will generate a green box. Tap the VIEW button to go to the Actions on Google Web Simulator.
If this is your first time on Actions on Google console, it will prompt you to turn on Device Information and Voice & Audio Activity on your Activity controls center.
By default these settings are off. If you already turn them on, you won’t see the prompt.
Go back to the simulator after turning on these two settings. Now we're ready to test the integration on the simulator! Start by typing or saying “Talk to my test app”. The simulator will respond with the texts from the Default Welcome Intent. Afterward, you can test the app as if you were in the API.AI test console.
Difference between tell() and ask() APIs
As we mentioned in part 2, there is a subtle difference between tell() and ask() APIs when we implement the Cloud Function with the Actions on Google SDK. This doesn’t make much of a difference in part 1 and part 2, but it does in part 3 when we integrate Actions on Google. tell() will end the conversation and close the mic, while ask() will keep the conversation open and wait for the next user input.
You can test out the difference in the simulator. If you use tell() in the Cloud Functions, you’ll need to say “talk to my test app” again once you’ve triggered the intents with the Cloud Functions webhook such as the inquiry.parades intent “Are there any parades today?”. If you use ask(), you will still be in the test app conversation and won’t need to say “talk to my test app” again.
Next steps
We hope this example demonstrates how to build a simple app powered by machine learning. For more getting started info, you might also want to try:
The ability to control resources programmatically with tools they know and love can make a big difference for developers creating cloud-native applications. That’s why today, we released and open sourced a set of comprehensive modules to improve the ability for Puppet users to manage Google Cloud Platform (GCP) resources using the Puppet domain specific language, or DSL. The new modules follow Puppet’s object convergence model, allowing you to define the desired state of your GCP resources that our providers will enforce directly within the Puppet language.
These new modules are Puppet Approved, having passed the rigorous quality and review bar from Puppet Engineering team, and are open-source under the Apache-2.0 license, available from GCP’s Github repository.
We also released a unified authentication module that provides a single authentication mechanism for all the modules.
It’s important to note that Puppet is not a scripting language. Rather, it follows an object-convergence model, allowing you to define a desired state for your resource, which our providers make so by applying necessary changes.
In other words, with Puppet, you don’t say “run this list of commands to install Apache on my machine,” you say “Apache should be installed and configured.” There is some nuance here, but with the latter, Puppet handles verifying if Apache is installed, checks for the correct dependencies, upgrades it if it’s not at the correct version and — most importantly — does nothing if everything is good. Puppet already understands the implementation differences across operating system and will handle doing the right thing for your chosen distribution.
Following an object-convergence model has various benefits: It makes your resource manifest declarative, abstracting away various details (e.g., OS-specific actions); and it makes definitions simpler to read, modify and audit.
The following manifest creates a full Google Container Engine cluster, in just 15 lines of code.
gauth_credential { 'mycred':
provider => serviceaccount,
path => '/home/nelsona/my_account.json',scopes => ['https://www.googleapis.com/auth/cloud-platform'],
}
gcontainer_cluster { 'myapp-netes':
ensure => present,
initial_node_count => 2,
node_config => {
machine_type => 'n1-standard-4',# we want a 4-core machine for our clusterdisk_size_gb => 500, # ... and a lot of disk space
},
zone => 'us-central1-f',project => 'google.com:graphite-playground',credential => 'mycred',
}
For specific examples of how to use Puppet with the individual GCP modules, visit their respective Forge pages.
Getting started with Puppet on GCP
To hit the ground running with Puppet and GCP, follow these basic steps:
Install the appropriate modules.
Get a service account with privileges on the GCP resources you want to manage and enable the the APIs for each of the GCP services you intend to use.
All Google modules for Puppet are available on Puppet Forge. We also provide a “bundle” module that installs every GCP module at once, so you can choose the granularity of the code you pull into your infrastructure.
Note: Google modules requires neither administrator privileges nor special privileges/scopes on the machines being executed. It is safe to install the modules either as a regular user or in your Puppet master. Install on the master if you want it distributed to all clients.
The authentication module depends on a few gems released by Google. As with everything related to system configuration, you can install the gems using Puppet itself.
2. Get your service account credentials and enable APIs
To ensure maximum flexibility and portability, all authentication and authorization to your GCP resources must be done via service account credentials. Using service accounts allows you to restrict the privileges to the minimum necessary to perform the job.
Note: Because service accounts are portable, you don’t need to run Puppet inside GCP. Our modules run on any computer with internet access, including on other cloud providers. You might, for example, execute deployments from within a CI/CD system pipeline such as Travis or Jenkins, or from your own development machine.
Also make sure you have enabled the the APIs for each of the GCP services you intend to use.
3a. Define authentication mechanism
Once you have your service account, add this block to your manifest to begin authenticating with it. The resource title, here 'mycred'is referenced in the objects in the credential parameter.
You can manage any resource for which we provide a type. The example below creates a Kubernetes cluster in Google Container Engine. For the full list of resources that you can manage, please refer to the respective module documentation link or to this aggregate summary view.
gcontainer_cluster { 'myapp-netes':
ensure => present,
initial_node_count => 2,
node_config => {
machine_type => 'n1-standard-4', # we want a 4-core machine for our cluster
disk_size_gb => 500, # ... and a lot of disk space
},
project => 'google.com:graphite-playground',
credential => 'mycred',
}
4. Apply your manifest
Next, tell Puppet to enforce and bring your resources into the state described in the manifest. For example:
puppet apply <your-file.pp>
Please note that you can apply the manifest standalone, one time, or periodically in the background using an agent.
Next steps
You’re now ready to start managing your GCP resources with Puppet, and start reaping the benefits of cross-cloud configuration management. We will continue to improve the modules and add coverage to more Google products. We are also in the process of preparing the technology used to create these modules for release as open source. If you want have questions about this effort please visit Puppet on GCP Discussions forum, or reach out to us on puppet-on-gcp@google.com.
By Uday Savagaonkar, Technical Lead Manager, Nelly Porter, Senior Product Manager, Nadim Taha, Software Lead,
Benjamin Serebrin, Tech Lead and Neal Mueller, Product Marketing Lead
While there are no absolutes in computer security, we design, build and operate Google Cloud Platform (GCP) with the goal to protect customers' code and data. We harden our architecture at multiple layers, with components that include Google-designed hardware, a Google-controlled firmware stack, Google-curated OS images, a Google-hardened hypervisor, as well as data center physical security and services.
Photograph of Titan inside Google's purpose-built server
In this post, we provide details of the mechanisms of how we will establish a hardware root of trust using our custom chip, Titan.
First introduced at Google Cloud Next '17, Titan is a secure, low-power microcontroller designed with Google hardware security requirements and scenarios in mind. Let’s take a look at how Titan works to ensure that a machine boots from a known good state using verifiable code, and establishes the hardware root of trust for cryptographic operations in our data centers.
Photograph of Urs Hölzle unveiling Titan at Google Cloud Next '17 (YouTube)
Machine boot basics
Machines in Google’s datacenters, as with most modern computers, have multiple components, including one or more CPUs, RAM, Baseboard Management Controller (BMC), NIC, boot firmware, boot firmware flash and persistent storage. Let’s review how these components interact to boot the machine:
The machine's boot process starts when the BMC configuring the machine hardware lets the CPU come out of reset.
The CPU then loads the basic firmware (Boot or UEFI) from the boot firmware flash, which performs further hardware/software configuration.
Once the machine is sufficiently configured, the boot firmware accesses the "boot sector" on the machine's persistent storage, and loads a special program called the "boot loader" into the system memory.
The boot firmware then passes execution control to the boot loader, which loads the initial OS image from storage into system memory and passes execution control to the operating system.
In our datacenters, we protect the boot process with secure boot. Our machines boot a known firmware/software stack, cryptographically verify this stack and then gain (or fail to gain) access to resources on our network based on the status of that verification. Titan integrates with this process and offers additional layers of protection.
Typically, secure boot relies on a combination of an authenticated boot firmware and boot loader along with digitally signed boot files to provide its security guarantees. In addition, a secure element can provide private key storage and management. Titan not only meets these expectations, but goes above and beyond to provide two important additional security properties: remediation and first-instruction integrity. Trust can be re-established through remediation in the event that bugs in Titan firmware are found and patched, and first-instruction integrity allows us to identify the earliest code that runs on each machine’s startup cycle.
To achieve these security properties, Titan comprises several components: a secure application processor, a cryptographic co-processor, a hardware random number generator, a sophisticated key hierarchy, embedded static RAM (SRAM), embedded flash and a read-only memory block. Titan communicates with the main CPU via the Serial Peripheral Interface (SPI) bus, and interposes between the boot firmware flash of the first privileged component, e.g., the BMC or Platform Controller Hub (PCH), allowing Titan to observe every byte of boot firmware.
Titan's application processor immediately executes code from its embedded read-only memory when its host machine is powered up. The fabrication process lays down immutable code, known as the boot ROM, that is trusted implicitly and validated at every chip reset. Titan runs a Memory Built-In Self-Test every time the chip boots to ensure that all memory (including ROM) has not been tampered with. The next step is to load Titan’s firmware. Even though this firmware is embedded in the on-chip flash, the Titan boot ROM does not trust it blindly. Instead, the boot ROM verifies Titan's firmware using public key cryptography, and mixes the identity of this verified code into Titan's key hierarchy. Then, the boot ROM loads the verified firmware.
Once Titan has booted its own firmware in a secure fashion, it will turn its attention to the host’s boot firmware flash, and verify its contents using public key cryptography. Titan can gate PCH/BMC access to the boot firmware flash until after it has verified the flash content, at which point it signals readiness to release the rest of the machine from reset. Holding the machine in reset while Titan cryptographically verifies the boot firmware provides us the first-instruction integrity property: we know what boot firmware and OS booted on our machine from the very first instruction. In fact, we even know which microcode patches may have been fetched before the boot firmware's first instruction. Finally, the Google-verified boot firmware configures the machine and loads the boot loader, which subsequently verifies and loads the operating system.
Photograph of Titan up-close on a printed circuit board. Chip markings obscured.
Cryptographic identity using Titan
In addition to enabling secure boot, we’ve developed an end-to-end cryptographic identity system based on Titan that can act as the root of trust for varied cryptographic operations in our data centers. The Titan chip manufacturing process generates unique keying material for each chip, and securely stores this material—along with provenance information—into a registry database. The contents of this database are cryptographically protected using keys maintained in an offline quorum-based Titan Certification Authority (CA). Individual Titan chips can generate Certificate Signing Requests (CSRs) directed at the Titan CA, which—under the direction of a quorum of Titan identity administrators—can verify the authenticity of the CSRs using the information in the registry database before issuing identity certificates.
The Titan-based identity system not only verifies the provenance of the chips creating the CSRs, but also verifies the firmware running on the chips, as the code identity of the firmware is hashed into the on-chip key hierarchy. This property enables remediation and allows us to fix bugs in Titan firmware, and issue certificates that can only be wielded by patched Titan chips.
The Titan-based identity system enables back-end systems to securely provision secrets and keys to individual Titan-enabled machines, or jobs running on those machines. Titan is also able to chain and sign critical audit logs, making those logs tamper-evident. To offer tamper-evident logging capabilities, Titan cryptographically associates the log messages with successive values of a secure monotonic counter maintained by Titan, and signs these associations with its private key. This binding of log messages with secure monotonic counter values ensures that audit logs cannot be altered or deleted without detection, even by insiders with root access to the relevant machine.
Conclusion
Our goal is to protect the boot process by securing it with a dedicated entity that is explicitly engineered to behave in an expected manner. Titan provides this root of trust by enabling verification of the system firmware and software components, and establishes a strong, hardware-rooted system identity. Google designed Titan's hardware logic in-house to reduce the chances of hardware backdoors.
The Titan ecosystem ensures that production infrastructure boots securely using authorized and verifiable code.
In short:
Titan provides a hardware-based root of trust that establishes strong identity of a machine, with which we can make important security decisions and validate the “health” of the system.
Titan offers integrity verification of firmware and software components.
The system’s strong identity ensures that we'll have a non-repudiable audit trail of any changes done to the system. Tamper-evident logging capabilities help identify actions performed by an insider with root access.
Editor's Note: App Engine Firewall is now generally available. Learn more.
A key security feature for application developers and administrators is to be able to allow or deny incoming requests based on source IP addresses. This capability can help you do production testing without exposing your app to the world, block access to your app from specific geographies or block requests from a malicious user.
Today, we’re thrilled to announce the beta release of Google App Engine firewall. With App Engine firewall, you simply provide a set of rules, order them by priority and specify an IP address, or a set of IP addresses, to block or allow, and we’ll take care of the rest.
When App Engine firewall receives a request that you’ve configured to be denied, it returns an HTTP 403 Forbidden response without ever hitting your app. If your app is idle, this prevents new instances from spinning up, and if you’re getting heavy traffic, the denied request won’t add to your load — or cost you money.
App Engine firewall replaces the need for a code-based solution within your app that still allows requests in, but which can cost you resources and still expose your app.
Let’s say you’d like to test your application and give access only to browsers from your company’s private network. Open your firewall rules in the Cloud Console and you'll see a default rule that allows all traffic to your app.
First, add a new rule allowing traffic only from the range of IP addresses coming from your private network. Then, update the default rule to deny all traffic.
As with typical firewall semantics, App Engine firewall evaluates rules with a lower priority value first, followed by rules with a higher value. In the example above, the Allow rule with a priority of 100 is evaluated first, followed by the default rule.
To make sure that your set of firewall rules is working as intended, you can test an IP address to see if a request coming from this address would be allowed or denied.
From the Cloud Console, click the Test IP tab in the Firewall Rules section.
The response indicates if the request can proceed and indicates the specific firewall rule that matched the provided IP address.
With App Engine firewall, it’s easy to set up network access to your app and focus on what matters most: your app, without worrying about access control within your code. Check out the full documentation here.
App Engine firewall is in beta, so avoid using this functionality in production environments. If you have any questions, concerns or if something is not working as you’d expect, you can post in the Google App Engine forum, log a public issue or get in touch on the App Engine slack channel (#app-engine).
By Prajakta Joshi, Product Manager, Cloud Networking
We're excited to announce Network Service Tiers Alpha, making Google Cloud Platform (GCP) the first major public cloud to offer a tiered cloud network. We let you optimize for performance by choosing Premium Tier, which uses Google’s global network with unparalleled quality of service, or optimize for cost, using the new Standard Tier, an attractively-priced network with performance comparable to that of other leading public clouds.
"Over the last 18 years, we built the world’s largest network, which by some accounts delivers 25-30% of all internet traffic” said Urs Hölzle, SVP Technical Infrastructure, Google. “You enjoy the same infrastructure with Premium Tier. But for some use cases, you may prefer a cheaper, lower-performance alternative. With Network Service Tiers, you can choose the network that’s right for you, for each application.”
Power of Premium Tier
If you use Google Cloud today, then you already use the powerful Premium Tier.
Premium Tier delivers traffic over Google’s well-provisioned, low latency, highly reliable global network. This network consists of an extensive global private fiber network with over 100 points of presence (POPs) across the globe. By this measure, Google’s network is the largest of any public cloud provider.
In Premium Tier, inbound traffic from your end user to your application in Google Cloud enters Google’s private, high performance network at the POP closest to your end user, and GCP delivers this traffic to your application over its private network.
Outbound and Inbound traffic delivery
Similarly, GCP delivers outbound traffic from your application to end users on Google’s network and exits at the POP closest to them, wherever the end users are across the globe. Thus, most of this traffic reaches its destination with a single hop to the end user’s ISP, so it enjoys minimum congestion and maximum performance.
We architected the Google network to be highly redundant, to ensure high availability for your applications. There are at least three independent paths (N+2 redundancy) between any two locations on the Google network, helping ensure that traffic continues to flow between these two locations even in the event of a disruption. As a result, with Premium Tier, your traffic is unaffected by a single fiber cut. In many situations, traffic can flow to and from your application without interruption even with two simultaneous fiber cuts.
GCP customers use Global Load Balancing, another Premium Tier feature, extensively. You not only get the management simplicity of a single anycast IPv4 or IPv6 Virtual IP (VIP), but can also expand seamlessly across regions, and overflow or fail over to other regions.
With Premium Tier, you use the same network that delivers Google’s Search, Gmail, YouTube, and other services as well as the services of customers such as The Home Depot, Spotify and Evernote.
"75% of homedepot.com is now served out of Google Cloud. From the get-go, we wanted to run across multiple regions for high availability. Google's global network is one of the strongest features for choosing Google Cloud."
— Ravi Yeddula, Senior Director Platform Architecture & Application Development, The Home Depot.
Introducing Standard Tier
Our new Standard Tier delivers network quality comparable to that of other major public clouds, at a lower price than our Premium Tier.
Why is Standard Tier less expensive? Because we deliver your outbound traffic from GCP to the internet over transit (ISP) networks instead of Google’s network.
Outbound and Inbound traffic delivery
Similarly, we deliver your inbound traffic, from end user to GCP, on Google’s network only within the region where your GCP destination resides. If your user traffic originates from a different region, their traffic will first travel over transit (ISP) network(s) until it reaches the region of the GCP destination.
Standard Tier provides lower network performance and availability compared to Premium Tier. Since we deliver your outbound and inbound traffic on Google’s network only on the short hop between GCP and the POP closest to it, the performance, availability and redundancy characteristics of Standard Tier depend on the transit provider(s) carrying your traffic. Your traffic may experience congestion or outages more frequently relative to Premium Tier, but at a level comparable to other major public clouds.
We also provide only regional network services in Standard Tier, such as the new regional Cloud Load Balancing service. In this tier, your Load Balancing Virtual IP (VIP) is regional, similar to other public cloud offerings, and adds management complexity compared to Premium Tier Global Load Balancing, if you require multi-region deployment.
Compare performance of tiers
We commissioned Cedexis, an internet performance monitoring and optimization tools company, to take preliminary performance measurements for both Network Service Tiers. As expected, Premium Tier delivers higher throughput and lower latency than Standard Tier. You can view the live dashboards at www.cedexis.com/google-reports/ under the "Network Tiers" section. Cedexis also details their testing methodology on their website.
Cedexis graph below shows throughput for Premium and Standard Tier for HTTP Load Balancing traffic at 50th percentile. Standard (blue line) throughput is 3,223 kbps while Premium (green line) is 5,401 kbps, making Premium throughput ~1.7x times that of Standard. See Cedexis graph below:
In general, Premium Tier displays considerably higher throughput, at every percentile, than Standard Tier.
Compare pricing for tiers
We're introducing new pricing for Premium and Standard Tiers. You can review detailed pricing for both tiers here. This pricing will take effect when Network Service Tiers become Generally Available (GA). While in alpha and beta, existing internet egress pricing applies.
With the new Network Tiers pricing (effective at GA), outbound traffic (GCP to internet) is priced 24-33% lower in Standard Tier than in Premium Tier for North America and Europe. Standard Tier is less expensive than internet egress options offered by other major public cloud providers (based on typical published prices for July, 2017). Inbound traffic remains free for both Premium and Standard Tiers. We'll also change our current destination-based pricing for Premium Tier to be based on both source and destination of traffic since the cost of network traffic varies with the distance your traffic travels over Google’s network. In contrast, Standard Tier traffic will be source-based since it does not travel much over Google’s network.
Choose the right tier
The powerful Premium Tier remains the default tier for your workloads. Here’s a decision tree to help you choose the tier that best fits your requirements.
Configure the tier for your application(s)
One size does not fit all, and your applications in Google Cloud often have differing availability, performance, footprint and cost requirements. Configure the tier at the resource-level (per Instance, Instance template, Load balancer) if you want granular control or at the overarching project-level if you want to use the same tier across all resources.
Try Network Service Tiers today
“Cloud customers want choices in service levels and cost. Matching the right service to the right business requirements provides the alignment needed by customers. Google is the first public cloud provider to recognize that in the alpha release of Network Service Tiers. Premium Tier caters to those who need assured quality, and Standard Tier to those who need lower costs or have limited need for global networking.”
Great news, Rubyists! We recently released google-cloud-gemserver gem, making it possible to deploy a private gem server to Google Cloud Platform (GCP) with a single command:
This is a big deal for organizations that build libraries with proprietary business logic or that mirror public libraries for internal use. In Ruby, these libraries are called gems, and until recently, there wasn't a good hosted solution for serving them. For Ruby in particular, many developers found themselves building their own custom solutions or relying on third parties such as Gemfury.
Running a gem server run on GCP has a lot of advantages. Specifically, the above command deploys the gem server to a Google App Engine Flex instance, which has 99.95% uptime (Google Container Engine support coming soon). App Engine can also autoscale the number of instances based on CPU utilization to minimize the amount of maintenance for the gem server. Having the gem server on GCP also allows you to use existing cloud infrastructure such as Stackdriver Logging, Cloud Storage and direct access to the underlying VM running the gem server for fine-grained control. The gem server can store an unlimited amount of public and private gems allowing an unlimited amount of users with the correct permissions to access it. This level of flexibility and customization makes GCP a highly productive environment to deploy apps to, and the gem server is no exception.
Using the gem server
Let’s take a look at how to install and configure a private gem server.
To deploy your own private gem server to GCP:
First install the gem:
$ gem install google-cloud-gemserver
Ensure you have Cloud SDK installed and a GCP project created with billing enabled. Also ensure that you're authenticated with it. For a full list of prerequisites, read this checklist.
where MY_PROJECT_ID is the GCP project ID the gem server will be deployed to. This deploys the gem server to App Engine and creates a default key used to push and fetch gems from the gem server. For brevity, the value of this key will later be referred to as “my-key” and its name will later be referred to as “my-key-name”.
Now, you can access the gem server at http://[MY_PROJECT_ID].appspot.com. Gems can easily be pushed to the gem server with a key that has write access to the gem server. The above command generated a default key, my-key, that can be used. You can push a gem by running:
Before you can download gems from the gem server, you need to create a key that has read access to the gem server. Conveniently, the “create” command above also generated a default key. Installing gems uses bundler, which needs to be configured such that it associates the gem server with my-key when downloading gems, otherwise the download would fail with a 401 Unauthorized Error. This is also done automatically for my-key when you use the “create” command. Now, make a small modification to your Gemfile:
source “[GEMSERVER_URL]”
source “[GEMSERVER_URL]/private” do
gem “MY_GEM”
end
Then, run “bundle install” and it fetches and installs the gem “MY_GEM” from the gem server!
Conclusion
That is all it takes to spin up a personal, private gem server on GCP and access gems from it. Under the hood, it uses Google Cloud SQL to manage gem metadata, cached gems, authentication keys, etc., and Cloud Storage to maintain backups of the gems. The google-cloud-gemserver gem is built on top of an existing gem that runs a private gem server locally; it served as a base and was extended to work with GCP infrastructure. It's worth noting that the google-cloud-gemserver gem is open source and actively maintained. We're always looking to improve the gem and encourage contributions!
With all the buzz around Machine Learning as of late, it’s no surprise that companies are starting to experiment with their own ML models, and a lot of them are choosing TensorFlow. Because TensorFlow is open source, you can run it locally to quickly create prototypes and deploy fail-fast experiments that help you get your proof-of-concept working at a small scale. Then, when you’re ready, you can take TensorFlow, your data, and the same code and push it up into Google Cloud to take advantage of multiple CPUs, GPUs or soon even some TPUs.
When you get to the point where you’re ready to take your ML work to the next level, you will have to make some choices about how to set up your infrastructure. In general, many of these choices will impact how much time you spend on operational engineering work versus ML engineering work. To help, we’ve published a pair of solution tutorials to show you how you can create and run a distributed TensorFlow cluster on Google Compute Engine and run the same code to train the same model on Google Cloud Machine Learning Engine. The solutions use MNIST as the model, which isn’t necessarily the most exciting example to work with, but does allow us to emphasize the engineering aspects of the solutions.
We’ve already talked about the open-source nature of TensorFlow, allowing you to run it on your laptop, on a server in your private data center, or even a Raspberry PI. TensorFlow can also run in a distributed cluster, allowing you divide your training workloads across multiple machines, which can save you a significant amount of time waiting for results. The first solution shows you how to set up a group of Compute Engine instances running TensorFlow, as in Figure 1, by creating a reusable custom image, and executing an initiation script with Cloud Shell. There are quite a few steps involved in creating the environment and getting it to function properly. Even though they aren’t complex steps, they are operational engineering steps, and will take time away from your actual ML development.
Figure 1. A distributed TensorFlow cluster on Google Compute Engine.
The second solution uses the same code with Cloud ML Engine, and with one command you’ll automatically provision the compute resources needed to train your model. This solution also delves into some of the general details of neural networks and distributed training. It also gives you a chance to try out TensorBoard to visualize your training and resulting model as seen in Figure 2. The time you save provisioning compute resources can be spent analyzing your ML work more deeply.
Figure 2. Visualizing the training result with TensorBoard.
Regardless of how you train your model, the whole point is you want to use it to make predictions. Traditionally, this is where the most engineering work has to be done. In the case where you want to build a web-service to run your predictions, at a minimum, you’ll have to provision, configure and secure some web servers, load balancers, monitoring agents, and create some kind of versioning process. In both of these solutions, you’ll use the Cloud ML Engine prediction service to effectively offload all of those operational tasks to host your model in a reliable, scalable, and secure environment. Once you set up your model for predictions, you’ll quickly spin up a Cloud Datalab instance and download a simple notebook to execute and test the predictions. In this notebook you’ll draw a number with your mouse or trackpad, as in Figure 3, which will get converted to the appropriate image matrix format that matches the MNIST data format. The notebook will send your image to your new prediction API and tell you which number it detected as in Figure 4.
Figure 3.
Figure 4.
This brings up one last and critical point about the engineering efforts required to host your model for predictions, which is not deeply expanded upon in these solutions, but is something that Cloud ML Engine and Cloud Dataflow can easily address for you. When working with pre-built machine learning models that work on standard datasets, it can be easy to lose track of the fact that machine learning model training, deployment, and prediction are often at the end of a series of data pipelines. In the real world, it’s unlikely that your datasets will be pristine and collected specifically for the purpose of learning from the data.
Rather, you’ll usually have to preprocess the data before you can feed it into your TensorFlow model. Common preprocessing steps include de-duplication, scaling/transforming data values, creating vocabularies, and handling unusual situations. The TensorFlow model is then trained on the clean, processed data.
At prediction time, it is the same raw data that will be received from the client. Yet, your TensorFlow model has been trained with de-duplicated, transformed, and cleaned-up data with specific vocabulary mappings. Because your prediction infrastructure might not be written in Python, there is a significant amount of engineering work necessary to build libraries to carry out these tasks with exacting consistency in whatever language or system you use. Many times there is too much inconsistency in how the preprocessing is done before training versus how it’s done before prediction. Even the smallest amount of inconsistency can cause your predictions to behave poorly or unexpectedly. By using Cloud Dataflow to do the preprocessing and Cloud ML Engine to carry out the predictions, it’s possible to minimize or completely avoid this additional engineering work. This is because Cloud Dataflow can apply the same preprocessing transformation code to both historical data during training and real-time data during prediction.
Summary
Developing new machine learning models is getting easier as TensorFlow adds new APIs and abstraction layers and allows you to run it wherever you want. Cloud Machine Learning Engine is powered by TensorFlow so you aren’t locked into a proprietary managed service, and we’ll even show you how to build your own TensorFlow cluster on Compute Engine if you want. But we think that you might want to spend less time on the engineering work needed to set up your training and prediction environments, and more time tuning, analyzing and perfecting your model. With Cloud Machine Learning Engine, Cloud Datalab, and Cloud Dataflow you can optimize your time. Offload the operational engineering work to us, quickly and easily analyze and visualize your data, and build preprocessing pipelines that are reusable for training and prediction.