Tag Archives: Compute

Best practices for App Engine startup time: Google Cloud Performance Atlas

By Colt McAnlis, Developer Advocate

[Editor’s note: In the past couple of months, Colt McAnlis of Android Developers fame joined the Google Cloud developer advocate team. He jumped right in and started blogging — and vlogging — for the new Google Cloud Performance Atlas series, focused on extracting the best performance from your GCP assets. Check out this synopsis of his first video, where he tackles the problem of cold boot performance in App Engine standard environment. Vroom vroom!]

One of the fantastic features of App Engine standard environment is that it has load balancing built into it, and can spin up or spin down instances based upon traffic demands. This is great in situations where your content goes viral, or for daily ebb-and-flows of traffic, since you don’t have to spend time thinking about provisioning whatsoever.

As a baseline, it’s easy to establish that App Engine startup time is really fast. The following graph charts instance type vs. startup time for a basic Hello World application:


250ms is pretty fast to boot up an App Engine F2 type instance class. That’s faster than fetching a Javascript file from most CDNs on a 4G connection, and shows that App Engine responds quickly to requests to create new instances.

There are great resources that detail how App Engine manages instances, but for our purposes, there’s one main concept we’re concerned with: loading requests.

A loading request triggers App Engine’s load balancer to spin up a new instance. This is important to note, since the response time for a loading request will be significantly higher than average, since the request must wait for the instance to boot up before it's serviced.

As such, the key to being able to respond to rapid load balancing while keeping user experience high is to optimize the cold-boot performance of your App Engine application. Below, we’ve gathered a few suggestions on addressing the most common problems to cold-boot performance.

Leverage resident instances

Resident instances are instances that stick around regardless of the type of load your app is handling; even when you’ve scaled to zero, these instances will still be alive.

When spikes do occur, resident instances service requests that cannot be serviced in the time it would take to spin up a new instance; requests are routed to them while a new instance spins up. Once the new instance is up, traffic is routed to it and the resident instance goes back to being idle.


The point here is that resident instances are the key to rapid scale and not shooting users’ perception of latency through the roof. In effect, resident instances hide instance startup time from the user, which is a good thing!

For more information, check our our Cloud Performance Atlas article on how Resident instances helped a developer reduce their startup time.

Be careful with initializing global variables during parallel requests

While using global variables is a common programming practice, they can create a performance pitfall in certain scenarios relating to cold boot performance. If your global variable is initialized during the loading request AND you’ve got parallel requests enabled, your application can fall into a bit of a trap, where multiple parallel requests end up blocking, waiting on the first loading request to finish initializing of your global variable. You can see this effect in the logging snapshot below:
The very first request is our loading request, and the next batch is a set of blocked parallel requests, waiting for a global variable to initialize. You can see that these blocked requests can easily end up with 2x higher response latency, which is less than ideal.

For more info, check our our Cloud Performance Atlas article on how Global variables caused one developer a lot of headaches.

Be careful with dependencies

During cold-boot time, your application code is busy scanning and importing dependencies. The longer this takes, the longer it will take for your first line of code to execute. Some languages can optimize this process to be exceptionally fast, other languages are slower, but provide more flexibility.

And to be fair, most of the time, a standard application importing a few modules should have a negligible impact on performance. However, when third-party libraries get big enough, we start to see them do weird things with import semantics, which can mess up your boot time significantly.
Addressing dependency issues is no small feat. You might have to use warm-up requests, lazy-load your imports, or in the most extreme case, prune your dependency tree.

For more info, check our our Cloud Performance Atlas article on how the developer of a platypus-based calculator tracked down a dependency problem.


Every millisecond counts

In the end, optimizing cold-boot performance for App Engine instances is critical for scaling quickly and keeping user perception of latency in a good place. If you’d like to know more about ways to optimize your Google Cloud applications, check out the rest of the Google Cloud Performance Atlas blog posts and videos. Because when it comes to performance, every millisecond counts.

App Engine users, now you can configure custom domains from the API or CLI

By Lorne Kligerman, Product Manager

As a developer, your job is to provide a professional branded experience for your users. If you’re developing web apps, that means you’ll need to host your application on its own custom domain accessed securely over HTTPS with an SSL certificate.

With App Engine, it’s always been easy to access applications from their own hostname, e.g., <YOUR_PROJECT_ID>.appspot.com, but custom domains and SSL certificates could only be configured through the App Engine component of the Cloud Platform Console.

Today, we’re happy to announce that you can now manage both your custom domains and SSL certificates using the new beta features of the Admin API and gcloud command-line tool. These new beta features provide improved management, including the ability to automate mapping domains and uploading SSL certificates.

We hope these new API and CLI commands will simplify managing App Engine applications, help your business scale, and ultimately, allow you to spend more time writing code.

Managing App Engine custom domains from the CLI


To get started with the CLI, first install the Google Cloud SDK.

To use the new beta commands, make sure you’ve installed the beta component:

gcloud components install beta

And if you’ve already installed that component, make sure that it's up to date:

gcloud components update

Now that you’ve installed the new beta command, verify your domain to register ownership:

gcloud beta domains verify <DOMAIN>
gcloud beta domains list-verified

After you've verified ownership, map that domain to your App Engine application:

gcloud beta app domain-mappings create <DOMAIN>

You can also map your subdomains this way. Note that as of today, only the verified owner can create mappings to a domain.

With the response from the last command, complete the mapping to your application by updating the DNS records of your domain.

To create an HTTPS connection, upload your SSL certificate: 

gcloud beta app ssl-certificates create --display-name 
<CERT_DISPLAY_NAME> --certificate <CERT_DIRECTORY_PATH> 
--private-key <KEY_DIRECTORY_PATH>

Then update your domain mapping to include the certificate that you just uploaded:

gcloud beta app domain-mappings update <DOMAIN> --certificate-id 
<CERT_ID>

We're also excited to provide a single command that you can use to renew your certificate before it expires:

gcloud beta app ssl-certificates update <CERT_ID> --certificate 
<CERT_DIRECTORY_PATH> --private-key <KEY_DIRECTORY_PATH>

As with all beta releases, these commands should not yet be used in production environments. For complete details, please check out the full set of instructions, along with the API reference. If you have any questions or feedback, we’ll be watching the Google App Engine forum, you can log a public issue, or get in touch on the App Engine slack channel (#app-engine).

Enhancing the Python experience on App Engine

By Amir Rouzrokh, Product Manager

Developers have always been at the heart of Google Cloud Platform (GCP). And with App Engine, developers can focus on writing code that powers their business and leave the infrastructure hassle to Google, freeing themselves from tasks such as server management and capacity planning. Earlier this year, we announced the general availability of App Engine flexible environment, and later announced the expansion of App Engine to the europe-west region. Today we're happy to announce additional upgrades for Python users for both App Engine flexible and standard environments.
Starting today, App Engine flexible environment users can deploy to the latest version of Python, 3.6. We first supported Python 3 for App Engine flexible environment back in 2016, and have continued to update the runtime as the community releases new versions of Python 3 and Python 2. We'll continue to update the runtimes to the latest versions as soon as they become available. To see a demo on how to deploy a simple “Hello World” Flask web application that can deploy to Python 3 in under ten minutes, see our video in an earlier blogpost.

On App Engine standard environment, we’ve updated more than 2 million apps running Python 2.7.5 to Python 2.7.12 without any input needed from our users, and as of today, all new deployments will run in this new runtime. To see a demo on how to deploy a simple “Hello World” Flask web application that deploys in seconds and scales to millions of requests per second to Python 2 in under a minute, see our Getting Started guide. We're committed to updating Python to the latest versions of Python 2 as they become available, and bringing the latest versions of Python 3 to the App Engine standard environment is on our roadmap. Stay tuned!

On the libraries side, App Engine flexible environment users can continue to pull in any library the application requires by simply providing a requirements.txt file during deployment. App Engine standard environment users also now have updated runtime-provided libraries. Refer to the App Engine standard documentation for the full list of built-in and third-party libraries. We'll continue updating these libraries as new versions become available.

As of today, Python developers have deployed more than 6,000,000 applications to App Engine, and companies large and small continue to innovate without having to worry about infrastructure. App Engine has built in support for micro-services, auto scaling, load balancing, traffic splitting and much more. And with a commitment to open source and open cloud, App Engine continues to welcome contribution from the developer community on both the runtimes and the libraries. If you wish to keep up to date with the latest runtime releases, please bookmark the release notes page for Python on App Engine standard and flexible.

Feel free to reach out to us on Twitter using the handle @googlecloud. We're also on the Google Cloud Slack community. To get in touch, request an invite to join the Slack Python channel.

Happy coding!

Compute Engine updates bring Skylake GA, extended memory and more VM flexibility

By Hanan Youssef, Sami Iqram and Scott Van Woudenberg, Product Managers, Google Compute Engine

We’re pleased to announce several updates to Google Compute Engine that give you more powerful and flexible instances. Google Cloud is the first and only public cloud to deliver Intel’s next-generation Xeon server processor (codenamed Skylake), and starting today, it’s generally available (GA). In addition, we’ve made several other enhancements to Compute Engine:
  • Increased total amount of memory per instance by removing memory caps
  • Increased variety of machine shapes
  • Simple process to select a baseline processor type
  • Availability of 64-core processors in all regions
  • Broadwell CPUs available in all regions
These improvements help you get the performance from Compute Engine that you need, in the configuration you want.

Skylake is generally available

With up to 64 vCPUs and 455GB of RAM, Skylake-based instances support a wide range of compute-intensive workloads, including scientific modeling, genomic research, 3D rendering, data analytics and engineering simulations. Since we first launched Skylake for Compute Engine in February, GCP customers have run millions of hours of compute on Skylake VMs, seeing increased performance for a variety of applications.

With this GA release, you can create new VMs with Skylake across Compute Engine’s complete family of VM instance types — standard, highmem, highcpu, Custom Machine Types, as well as Preemptible VMs. You can provision Skylake VMs using Cloud Console, the gcloud command line tool, or our APIs. Skylake is available in three GCP regions: Western US, Western Europe and Eastern Asia Pacific. Customer demand for Skylake has been very strong; we have more capacity arriving every day, and support for additional regions and zones coming in the near future.

To help you experience Skylake, we're offering Skylake VMs at no additional cost for a limited time. After a 60-day promotional period, Skylake VMs will be priced at a 6-10% premium depending on the specific machine configuration. Given the significant performance increase over previous generations of Intel processors, this continues our record of providing a leading price-performance cloud computing platform.

CPU platform selector

Google Cloud Platform (GCP) regions and zones are equipped with a diverse set of Intel Xeon-based host machines, with CPUs including Sandy Bridge, Ivy Bridge, Haswell, Broadwell and now Skylake microarchitectures. In addition to fundamental systems features like clock speed and memory access time, these CPU platforms also support unique features like AVX-2 and AVX-512.

Now, with our Minimum CPU Platform feature, you can select a specific CPU platform for VMs in that zone, and Compute Engine will always schedule your VM to that CPU family or above. You can assign a minimum CPU platform to a VM from the Cloud Console, Google Cloud SDK, or API, with full flexibility to choose the CPU features that work best for your applications.

Enabling this enhanced flexibility also allows us to now offer Broadwell CPU support in every region, as well as the ability to create VMs up to 64 vCPUs in size.
In the gcloud command line tool, use the instances create subcommand, followed by the --min-cpu-platform flag to specify a minimum CPU platform.

For example, the following command creates an n1-standard-1 instance with the Intel Broadwell (or later) CPU platform. 

gcloud beta compute instances create example-instance --machine-type 
n1-standard-1 --min-cpu-platform “Intel Broadwell”

To see which CPUs are available in different GCP zones, check our Available Regions and Zones page. For complete instructions for using --min-cpu-platform, please refer to our documentation.

Extended memory, where you want it

Compute Engine Custom Machine Types allow you to create virtual machines with the vCPU and memory ratios to fit your application needs. Now, with extended memory, we’ve removed memory ratio restrictions for a vCPU (previously set at 6.5GB), for a maximum of 455GB of memory per VM instance. This is great news for applications like in-memory databases (e.g. Memcached & Redis), high-performance relational databases (e.g. Microsoft SQL Server) and NoSQL databases (e.g. MongoDB) that benefit from flexible memory configurations to achieve optimum price-performance. To learn more about the pricing for extended memory please take a look at our pricing page.

You can create a VM with extended memory using the Cloud Console, Cloud SDK or APIs.


For example, this command creates a 2 vCPU, 15GB memory instance (including an extended memory of 2GB):

gcloud beta compute instances create example-instance 
--custom-cpu 2 --custom-memory 15 --custom-extensions

Complete instructions for using extended memory are available in our documentation.

Get started today

The minimum CPU platform selector, extended memory to 455GB, availability of 64-core machines, Broadwell processors in all regions and the GA of Skylake processors are now all available for you and your applications. If you’re new to GCP you can try all of this out when you sign up for $300 free trial. We’d love to hear about the amazing things you do with these Compute Engine enhancements in the comments below.

Windows on the rise at GCP

By Chris Sells, Product Manager

It’s been a little over three months since we made our no-charge VM migration tool available for GCP in the Google Cloud Console, and customers have jumped at the chance to move their enterprise workloads to Google Cloud. While customers are moving applications using a variety of source operating systems to Google Cloud, we've been especially excited to see that almost half of the VM migrations to Google Cloud via this new service have been of Microsoft Windows workloads.

Why is this significant to you? Because our goal to make Google Cloud the best place to run any application — from Windows workloads to new cloud native applications. We believe that the significant number of Windows applications migrating to Google Cloud through this new service is indicative of strong demand to give enterprise Windows applications the agility, scale and security advantages of Google Cloud.
“We are leveraging Google Cloud to deliver the experiences our customers demand, and we want to make sure that all our workloads can take advantage of Google Cloud’s unique infrastructure and services. Using the free Google Cloud migration tools, we’ve been able to easily move our Windows servers to Google Cloud with near-zero downtime.” — Rob Wilson, CTO at Smyths Toys
We're happy to see customers take advantage of our first class support for Windows, SQL Server and both .NET and .NET Core on GCP. We’ve made sure that those applications are well-supported by providing support for Windows Server 2016 within weeks of it reaching GA, by adding support for SQL Server Web, Standard and Enterprise editions (including support for High Availability), by integrating Visual Studio and PowerShell, by making all of Google’s APIs available via NuGet and by joining the .NET Foundation’s Technical Steering Committee. Further, with Stackdriver Logging, Error Reporting and Trace support for Windows and .NET; developers and administrators have the support they need to build, deploy and manage their applications. Finally, with the recent announcement of .NET Core support in all of our libraries and tooling, as well as in our App Engine and Container Engine products, you’re covered into the future as well.

Internally, we’ve seen other signs of more Windows and .NET workloads running on GCP, including a 57% increase in Windows CPU usage in the second half of 2016. Further, we know that sometimes you need help to take advantage of the full capabilities of GCP, which is why we announced the Windows Partner Program. These top-notch systems integrators will help you to not just “lift & shift,” but rather to “move & improve,” with cutting-edge capabilities such as big data processing, data analytics, machine learning and container management.

Learn more about Windows, SQL Server and .NET on GCP; and don’t hesitate to reach out with questions and suggestions. We’ve had lots of folks make the switch already, we’d love you to join them. Our migration service is offered at no charge and you get $300 of GCP credits when you sign up so you can migrate a few servers to see how easy it is to run your windows apps in GCP. Click here to get started.

Solution guide: Best practices for migrating Virtual Machines

By Peter-Mark Verwoerd, Solutions Architect, Google Cloud

Migrating to the cloud can be a challenging project for any sized company. There are many different considerations in migrations, but one of the core tasks is to migrate virtual machines. Due to the variety of hardware, hypervisors and operating systems in use today, this can be a complex and daunting prospect.

The customer engineering team at Google Cloud has helped a number of customers migrate to GCP - customers like Spotify and Evernote. Based on those experiences and our understanding of how our own cloud works, we've released an article describing our recommended best practices on migrating virtual machines.

One of the tools that can help customers move to Google Cloud is CloudEndure. CloudEndure powers the Google VM Migration Service, and can simplify the process of moving virtual machines. CloudEndure joined us in this article with practical case studies of migrations that they've done for various customers.

We hope you find this article helpful while migrating to the cloud. If you decide to use the Migration Service, take a look at our tutorial to help guide you through the process.

Better VM Rightsizing Recommendations with the Stackdriver Agent

By Pawel Siarkiewicz, Product Manager

We launched the VM Rightsizing Recommendations beta in July of 2016 and since then many users have taken advantage of it to achieve savings or more optimal machine shapes.
Until recently, Rightsizing Recommendations were based solely on the CPU and memory statistics visible to the Compute Engine virtual machine manager. This approach works well for CPUs that can be accurately monitored, but is fairly limited for memory. There, the challenge is that the virtual machine manager has no insight into how the guest operating system manages the memory and what part is allocated for processes and caches, etc. Without understanding what exactly is happening inside a VM instance, a recommendation can’t be tailored to the real memory usage.
Recommendations without visibility to how the accessed RAM is used
This is where the Stackdriver Agent comes in. When you install it on your VM instance, the Stackdriver Agent exports additional metrics to our monitoring system. These metrics allow the Rightsizing Recommendations system to accurately determine how much memory is allocated by processes vs. operating system caches and how much memory it freed up. This, in turn, allows us to calculate recommendations that more closely match the real workload.
Stackdriver Agent-based recommendations with a look through to the used RAM
Is there a real benefit to the user? Absolutely! When comparing RAM recommendations made with and without the Stackdriver Agent, we see that on average the Agent-based recommendations save 50% more memory, and in some cases, even more. The agent provides better visibility, giving the Rightsizing Recommendations system more and better data to work with, which results in tangible savings to users.

If you wish to get started with Stackdriver Agent-based recommendations, just install the agent on your VMs. The additional metrics will be automatically used for Rightsizing Recommendations and you don’t even need a Stackdriver account.

NAB 2017: Rendering updates to GCP

By Todd Prives, Product Manager

Google Cloud Platform (GCP) is leading the way in cloud rendering solutions, and we're excited to make several announcements at the NAB 2017 show relating to our suite of solutions.

For our SaaS users, we've made several additions and price reductions to our Zync Render platform including:
  • Added rendering support for the popular Arnold Render for Cinema 4D. Arnold is a renderer used in countless feature film, advertising, VR and television projects and support in Cinema 4D allows Zync users to scale to tens of thousands of cores on demand when rendering a scene with Arnold.
  • We’ve also cut pricing for many Zync applications (Maya, Cinema 4D & Houdini) by up to 31%.
For our IaaS large studio customers who set up a custom rendering pipeline on GCP, we understand that establishing a secure connection to our platform is critical to ensure that sensitive pre-release content is protected at all times. We’ve worked with the leading Hollywood production studios to develop a Securing Rendering Workloads Solution that our customers can follow when building their rendering solution with us.

220,000 cores and counting: MIT math professor breaks record for largest ever Compute Engine job

By Alex Barrett, GCP Blog Editor & Michael Basilyan, Product Manager, Compute Engine

An MIT math professor recently broke the record for the largest ever Compute Engine cluster, with 220,000 cores on Preemptible VMs, the largest known high-performance computing cluster to ever run in the public cloud.

Andrew V. Sutherland is a computational number theorist and Principal Research Scientist at MIT, and is using Compute Engine to explore generalizations of the Sato-Tate Conjecture and the conjecture of Birch and Swinnerton-Dyer to curves of higher genus. In his latest run, he explored 1017 hyperelliptic curves of genus 3 in an effort to find curves whose L-functions can be easily computed, and which have potentially interesting Sato-Tate distributions. This yielded about 70,000 curves of interest, each of which will eventually have its own entry in the L-functions and Modular Forms Database (LMFDB).




Finding suitable genus 3 curves “is like searching for a needle in a fifteen-dimensional haystack,” Sutherland said. “Sometimes I like to describe my work as building telescopes for mathematicians.”

It also requires a lot of compute cycles: For each curve that's examined, its discriminant must be computed; the discriminant of a curve serves as an upper bound on the complexity of computing its L-function. This task is trivial in genus 1, but in genus 3 may involve evaluating a 50 million term polynomial in 15 variables. Each curve that's a candidate for inclusion in the LMFDB must also have many other of its arithmetic and geometric invariants computed, including an approximation of its L-function and Sato-Tate distribution, as well as information about any symmetries it may possess. The results can be quite large, and some of this information is stored as Cloud Storage nearline objects. Researchers can browse summaries of the results on the curve’s home page in the LMFDB, or download more detailed information to their own computer for further examination. The LMFDB provides an online interface to some 400 gigabytes of metadata housed in a MongoDB database that also runs on Compute Engine.

Sutherland began using Compute Engine in 2015. For his first-ever job, he fired up 2,250 32-core instances and completed about 60 CPU-years of computation in a single afternoon.

Before settling on Compute Engine, Sutherland ran jobs on his own 64-core machine, which could take months, or wrangled for compute time on one of MIT’s clusters. But getting the number of cores he needed often raised eyebrows, and he was limited by the software configurations he could use. By running on Compute Engine, Sutherland can install exactly the operating system, libraries and applications he needs, and thanks to root access, he can update his environment at will.

Sutherland considered running his jobs on AWS before choosing Google but was dissuaded by its Spot Instances model, which forces you to name your price up front, with prices that can vary significantly by region and fluctuate over time. A colleague encouraged him to try Compute Engine Preemptible VMs. These are full-featured instances that are priced up to 80% less than regular equivalents, but can be interrupted by Compute Engine. That was fine with Sutherland. His computations are embarrassingly parallel — they can be easily separated into multiple, independent tasks — and he grabs available instances across any and all Google Cloud Regions. An average of about 2-3% of his instances are typically preempted in any given hour, but a simple script automatically restarts them as needed until the whole job is complete.

To coordinate the instances working on a job, Sutherland uses a combination of Cloud Storage and Datastore. He used the python client API to implement a simple ticketing system in Datastore that assigns tasks to instances. Instances periodically checkpoint their progress on their local disks from which they can recover if preempted, and they store their final output data in a Cloud Storage bucket, where it may undergo further post-processing once the job has finished.

All told, having access to the scale and flexibility of Compute Engine has freed Sutherland up to think much bigger with his research. For his next run, he hopes to expand his search to non-hyperelliptic curves of genus 3, breaking his own record with a 400,000-core cluster. “It changes your whole outlook on research when you can ask a question and get an answer in hours rather than months,” he said. “You ask different questions.”

The state of Ruby on Google Cloud Platform

By Aja Hammerly, Developer Advocate

At Google Cloud Next '17 last month we announced that App Engine flexible environment is now generally available. This brings the convenience of App Engine to Rubyists running Rails, Sinatra or other Rack based web frameworks.

One question we frequently get is, "Can I run gems like nokogiri or database adapters that have C extensions on App Engine?” and the answer is yes. We tested the top 1000 Ruby libraries, a.k.a., gems, to ensure that the necessary dependencies are available. We also tested common tools like paperclip that don't build against C libraries but require them at runtime. And we know that people are using different versions of Ruby and Rails; App Engine obeys .ruby-version and we support all currently supported versions of MRI. We've also tested the gems with Rails 3, Rails 4 and Rails 5. At Next we also announced that Postgres on Cloud SQL is in beta. All of these things should make it easier to move your Rails and Sinatra applications to App Engine. More info on using Ruby on Google Cloud Platform (GCP) is available at http://cloud.google.com/ruby.

New gems on tap

We also have three gems that have reached general availability for the following products: Stackdriver Logging, Google Cloud Datastore and Google Cloud Storage. In addition there are three gems currently in beta for Google BigQuery, Google Cloud Translation API and Google Cloud Vision API. Our philosophy when working on the gems has been to embrace the Ruby ethos that programming should be fun. We try to make our gems idiomatic and make sense to Rubyists. For example, our logging library provides a drop-in replacement for the standard Ruby logger: 

require "google/cloud/logging"

logging = Google::Cloud::Logging.new
logger = logging.logger "my_app_log", resource, env: :production

logger.info "Job started"
logger.info { "Job started" }
logger.debug?

With the Cloud Datastore gem, creating entities is similar to creating tables using ActiveRecord. And with Cloud Storage, you can upload files or you can upload Ruby IO Objects. Using our products should not add significant cognitive load to your development tasks. And having a philosophy of "By Rubyists for Rubyists" makes that easier to do.

RailsConf

If you want to try out some of these libraries or spin up an application on App Engine, come find us at RailsConf 2017 in Phoenix, Arizona later this month. We're proud to be a Gold sponsor again this year. Based on feedback from last year, we're making our booth more interactive with codelabs, demos and of course even more stickers.

We also have three folks from the Google Ruby team giving talks. Daniel Azuma's talk, "What's my app really doing in production" will show you tools and tricks to instrument and debug misbehaving apps. Remi Taylor's talk, "Google Cloud >3 Ruby," will teach you about all the different tools we have for Ruby developers. Finally, in my talk, "Syntax isn't everything: NLP for Rubyists," I use the Google Cloud Natural Language API library and some stupid Ruby tricks to introduce you to natural language processing. If you'll be at RailsConf we really hope you'll come say hi.