Today’s post is from Philip Talamas, CIO Minyanville Media, Inc., a New York based financial media company. In this post, Philip looks at the benefits his company received from switching from a major public cloud provider to Google Cloud Platform. ...
Today’s post is from Philip Talamas, CIO Minyanville Media, Inc., a New York based financial media company. In this post, Philip looks at the benefits his company received from switching from a major public cloud provider to Google Cloud Platform.

At Minyanville Media, our goal is to create branded business content that informs, entertains, and educates all generations about the worlds of business and finance. We designed our premium Buzz & Banter app to serve this need. The Buzz ran on a competing cloud platform that presented increasing technical challenges as we expanded our customer base and feature set. We wanted a higher performing platform offering a more flexible and deeper feature set; we wanted to be certain we were serving our longtime clients as best as we could.

We consulted our strategic technology partner MediaAgility, and the company advised us to move to Google Cloud Platform. There were two obvious benefits to switching to Google Cloud Platform from our old provider: better reliability and automatic demand-based scaling of the application.



Every day, thousands of investors access our system globally, everywhere from Syracuse to Switzerland. They turn to us for reliable market intelligence and investing ideas. Today's economic uncertainty, coupled with high frequency trading, keeps us on our toes. When a central bank unexpectedly cuts interest rates or a hacked tweet sends markets into a tailspin, seconds matter. We are timely, or we are out of business. It’s as simple as that. Additionally, we serve two major online brokerage firms, which have very high standards for performance and reliability.

Hence, we decided to move Buzz and Banter to the Google Cloud Platform. The improvement and increase in operational speed was drastic. New Buzz, running on Google App Engine, updates content instantaneously -- even before our content management system refreshes to confirm publication. The icing on the cake is that our operating costs are significantly lower than what they were under our old provider.

It’s rare that everyone wins in a technology transition, but that’s exactly what’s been accomplished in our move to Google App Engine. With a better customer experience, lower operating costs, and fewer technological headaches, we only wish that we’d made the switch sooner.

- Contributed by Philip Talamas, CIO, Minyanville Media, Inc.

Android Studio lets you easily add a cloud backend to your application, right from your IDE. A backend allows you to implement functionality such as backing up user data to the cloud, serving content to client apps, real-time interactions, sending push notifications through ...
Android Studio lets you easily add a cloud backend to your application, right from your IDE. A backend allows you to implement functionality such as backing up user data to the cloud, serving content to client apps, real-time interactions, sending push notifications throughGoogle Cloud Messaging for Android, and more. Additionally, having your application’s backend hosted on Google App Engine means that you can focus on what the cloud application does, without having to worry about administration, reliability or scalability.

When you create a backend using Android Studio, it generates a new App Engine application under the same project, and gives your Android application the necessary libraries and a sample activity to interact with that backend. Support for GCM is built-in, making it easy to sync data across multiple devices. Once you've generated the project, you can
build and run your client and server code together, in a single environment, and even deploy your backend code right from Android Studio.

In this post we’ll focus on how to get started with the basic setup. From there it's easy to extend the basic setup to meet your needs.

Preliminary setup

Before you get started, make sure you take care of these tasks first:
  • Download Android Studio if you haven’t done so already and set it up.
  • Make sure you have an application project set up in Android Studio. You can use any working app that you want to integrate with your backend, even a sample app.
  • If you'll be running the app on an emulator, download the Google APIs Addon from the SDK Manager and run your app on that image.
  • Create a Google Cloud Platform project: In the Cloud Console, create a new project (or reuse an old one) and make note of the Project ID. Click on the words “Project ID” on the top left to toggle to the Project Number. Copy this as well.
  • Enable GCM and obtain API Key: In the Cloud Console, click on APIs and turn on the Google Cloud Messaging for Android API. Then, click on the “Register App” button on the top left, enter a name for the app, then select “Android” and “Accessing APIs via a web server”. In the resulting screen, expand the “Server Key” box and copy the API key.

1. Generate an App Engine project

In Android Studio, open an existing Android application that you want to modify, or create a new one. Select the Android app module under the Project node. Then click Tools > Google Cloud Endpoints > Create App Engine Backend.
In the wizard, enter the Project ID, Project Number, and API Key of your Cloud project.


This will create:
  • An App Engine project which contains the backend application source
  • An endpoints module with a RegisterActivity class, related resources, and client libraries for the Android app to communicate with the backend
The generated App Engine application (<app_name>-AppEngine) is an Apache Maven-based project. The Maven pom.xml file takes care of downloading all the dependencies, including the App Engine SDK. This module also contains the following:
  • A Google Cloud Endpoint (DeviceInfoEndpoint.java, auto-generated from DeviceInfo.java) that your Android app will “register” itself through. Your backend will use that registration info to send a push notification to the device.
  • A sample endpoint, MessageEndpoint.java, to list previously sent GCM messages and send new ones.
  • A starter web frontend application (index.html in webapp directory) that will show all the devices that have registered with your service, and a form to send them a GCM notification.

The endpoints module (<app_name>-endpoints) generated for you contains the classes and libraries needed by the Android application to interact with the backend:
  • A RegisterActivity.java class that, when invoked, will go through the GCM registration flow and also register itself with the recently created backend through DeviceInfoEndpoint.
  • Client libraries, so that the application can talk to the backend using an object rather than directly using raw REST calls.
  • XML files related to the newly created activity.

2. Add GCM registration to your app

In your Android application, you can call RegisterActivity whenever you want the registration to take place (for example, from within the onCreate() method of your main activity.
...
import android.content.Intent;
...

@Override
    protected void onCreate(Bundle savedInstanceState) {
        ...
        Intent intent = new Intent(this, RegisterActivity.class);
        startActivity(intent);
    }

3. Deploy the sample backend server

When you're ready to deploy an update to your ( the sample ) production backend in the cloud, you can do that easily from the IDE. Click on the “Maven Projects” button on the right edge of the IDE, under Plugins > App Engine, right-click and run the appengine:update goal.



As soon as the update is deployed, you can also access your endpoints through the APIs Explorer at http://<project-id>.appspot.com/_ah/api/explorer.
For testing and debugging, you can also run your backend server locally without having to deploy your changes to the production backend. To run the backend locally, just set the value of LOCAL_ANDROID_RUN to true in CloudEndpointUtils.java in the App Engine module.

4. Build and run the Android app

Now build and run your Android app. If you called RegisterActivity from within your main activity, the device will register itself with the GCM service and the App Engine app you just deployed. If you are running the app on an emulator, note that GCM functionality requires the Google APIs Addon image, which you can download from the SDK Manager.
You can access your sample web console on any browser at http://<project-id>.appspot.com. There, you will see that the app you just started has registered with the backend. Fill out the form and send a message to see GCM in action!

Extending the basic setup

It's easy to expand your cloud services right in Android Studio. You can add new server-side code and through Android Studio instantly generate your own custom endpoints to access those services from your Android app.

- Posted by Sachin Kotwani, Product Manager

On the Google Cloud Platform team we're always looking for ways to make developers' lives easier, so you can focus on building interesting applications instead of worrying about managing infrastructure.
On the Google Cloud Platform team we're always looking for ways to make developers' lives easier, so you can focus on building interesting applications instead of worrying about managing infrastructure.

We also want you to be as productive as possible when you're busy writing code. We provide an SDK which offers access to production APIs, in a way that's compatible with a local development environment.



But sometimes you just want to dip your toes in the water, and the prospect of setting up a local development environment seems daunting. What if you just want to try out some sample code? What if you want to see how the actual production APIs will behave? What if you could share a code snippet with a colleague and your entire environment came along for the ride? What if there was a playground where you could try out APIs, all from within your web browser?

We asked ourselves these same questions and decided to try an experiment: we created a Cloud Playground, a place for you to quickly test production APIs you're interested in using. Note: the Cloud Playground is currently limited to Python 2.7 App Engine apps.

To get you started, we added little green                                                   buttons to our getting started documentation, which take you straight to the Cloud Playground where you can edit and run the guestbook sample code as it appears in the documentation.


In addition, the main Cloud Playground page offers easy access to many more samples. There's even an option to clone other open source App Engine Python 2.7 template projects from Github.





































How does it work? The Cloud Playground is itself an open source project and consists of two modules:
  • mimic is a regular Python App Engine app, which serves as a development server (similar to the App Engine SDK "dev_appserver"), but which runs in the production App Engine environment, providing you access to the production APIs and environment while still offering a quick and easy way to test out bits of code.
  • bliss is a trivial browser-based code editor which lets you edit code in the mimic virtual file system (backed by the App Engine datastore), providing you with a user interface so you can see what the mimic app can do for you.
We previously blogged about DevTable which also uses mimic to speed up refresh cycles for their App Engine developers.

We look forward to seeing what you're able to build.


- Posted by Fred Sauer, Developer Advocate

We hear consistently from developers that they want to see more portability of their apps when working in the cloud.  The Google Cloud Platform team has been collaborating with the ...
We hear consistently from developers that they want to see more portability of their apps when working in the cloud.  The Google Cloud Platform team has been collaborating with the Redhat/JBoss Application Server team to help them provide an alternate implementation of Google App Engine running on top of JBoss to facilitate portability and openness.

The bulk of the collaborative work between Google and Redhat is really around the open source Test Compatibility Kit (TCK) project:
Google engineers provided many of the tests of the internal App Engine product, and RedHat engineers added many tests to verify that their implementation of App Engine is correct. These collections of tests have been tested against a local App Engine SDK, a CapeDwarf implementation, and the real Google App Engine running in the Google cloud.

In my previous life in the Java Enterprise, portability across different application servers was a very important feature. But it was never 100% achievable due to lack of some specifications (how do you specify load balancing, auto-scalability, NOSQL access or even simple APIs like caching). Compliance certification was done via a reference implementation (RI) and a Test Compatibility Kit.

Why is providing an App Engine TCK in the open source so important? A few reasons:

First reason: JBoss is one of the key leaders in the Java EE API specification and implementation: JPA, CDI, Beans validation, JAX-RS. JBoss working on implementing Google App Engine on top of their existing APIs helps customers address portability and testing concerns and helps validate our approach.

Second reason: If you are considering using App Engine but have had technical or business constraints for making the move to Google Cloud Platform, you now can when using CapeDwarf on your private cloud (or even private machine), on OpenShift or Google Compute Engine.

Third reason: If you are an existing Java EE JBoss customer, but are looking for easier and more “cloud ready” APIs than Java EE, you can start discovering the simplicity of App Engine APIs. The DNA for these APIs is not from Java EE, it is from the cloud.

Accessing the Datastore is as simple as writing:

DatastoreService ds = DatastoreServiceFactory.getDatastoreService();

No more non portable resource definition, funky XML files or command line tools, JNDI configuration and injection. An App Engine application comes with a complete runtime environment: a datastore, a user service, a mail service, a task queue system, a blob service, a chat service, and more.
An App Engine application does not need to specify load balancing parameters, autoscaling rules, failover across data center settings, replication configuration. It just works and scales automatically.

Fourth reason: If you are an App Engine customer and you love the App Engine APIs, but would like to deploy a new App Engine application on your private farm of servers, you now can with CapeDwarf.

Google has always been committed to the open web.  We are looking forward to moving these tests to open source.  But, of course, we know this is a two way street - we would love for you to provide new tests to us and the community so we can all grow together and improve our applications.  Adding such customer centric tests in the open source TCK would help provide a quick turn around (nobody wants to see a failing TCK build), and also help prevent future App Engine versions (we release the product once a month) from breaking customer tests.

Check it out for yourself: get the TCK code, run the tests and contribute new tests that match your App Engine Application, we are open!


-Posted by Ludovic Champenois, Software Engineer


Transferring large data sets (in the hundreds of terabytes and beyond) can be expensive and time-consuming over the public network. To help, we're beginning a limited preview of offline disk import for ...

Transferring large data sets (in the hundreds of terabytes and beyond) can be expensive and time-consuming over the public network. To help, we're beginning a limited preview of offline disk import for Google Cloud Storage, which lets you load data by sending us a physical hard disk drives (HDDs) of data that we load on your behalf. Using this option can be helpful if you’re limited to a slow, unreliable, or expensive Internet connection.

To use offline disk import, write your data to HDDs and then ship them to a Google import center using a mail carrier. For security during shipment, the data on the HDDs must be encrypted. Upon receiving the shipment, Google uploads the data into an empty Cloud Storage bucket that you designate. Because the data is loaded directly via Google's network, this approach may be faster or less expensive than transferring data over the Internet.

Offline disk import have a flat fee of $80 per HDD irrespective of the drive capacity or data size. During the limited preview, offline disk import is available for customers with a return address based in the United States. If you’re interested in using offline disk import, sign up for the limited preview. If you are outside the United states and are interested in offline disk import also let us know and we will follow up.

We are pleased to add this additional option for getting your data into the cloud. If you have a moderately sized data set, aren’t in a hurry to transfer your data, or have excellent throughput over the internet, you’ll likely be best served by using gsutil tool to transfer the data over the Internet.


Hot on the heels of this year’s Google I/O, Google App Engine 1.8.1 is now released. Below are some of the significant changes that are part of 1.8.1.
Hot on the heels of this year’s Google I/O, Google App Engine 1.8.1 is now released. Below are some of the significant changes that are part of 1.8.1.

Search API
In 1.8.1 we’re moving the Search API to Preview. The Search API allows your application to perform Google-like searches over structured data. You can search across several different types of data (plain text, HTML, atom, numbers, dates, and geographic locations).

This Preview release is one step closer to General Availability (GA). Between now and then we will only be making slight modifications to the API and adding an SLA. Finally, as part of the Preview, we will begin charging for operations and storage. Pricing details can be found here. Note that prices may change between now and GA.

Source Push-to-Deploy
App Engine now supports deployment of Python and PHP applications via the Git tool. Once you complete the initial setup steps, you will be ready to deploy apps with the same ease with which you push code to a git repository:
% git push appengine master
If you’re interested in test-driving this feature, you can get started here.

Google Cloud Storage Client Library
To improve access to Google Cloud Storage from App Engine, we’re now announcing the Preview release of the Cloud Storage Client Library. This client library contains much of the functionality available in the Files API (Python | Java), but provides stronger integrity guarantees and a better overall developer experience. The Cloud Storage Files API (currently Experimental) and the Cloud Storage Client Library overlap significantly, so we plan to decommission the Files API in a future release. The Cloud Storage Client Library will be upgraded to GA in an upcoming App Engine release, so we strongly encourage developers to start making the move over the next few months.

Task Queues
Many developers have requested an API for enqueuing tasks in asynchronously and this is now available in 1.8.1. Developers can quickly add tasks to any Task Queue without blocking, allowing your applications to process requests more efficiently.

Datastore
There are 2 significant Google Cloud Datastore changes in this release. First, we have improved performance by changing the Datastore default auto ID policy to use scattered IDs. This change will take effect for all versions of your app uploaded with the 1.8.1 SDK. Second, Python developers will be pleased to learn that the NDB library now supports ‘DISTINCT’ queries.

We covered a lot of new content at Google I/O last month, so check out the full session videos to see the latest across Google Cloud Platform.

The complete list of features and bug fixes for 1.8.1 can be found in our release notes. For App Engine coding questions and answers check us out on Stack Overflow, and for general discussion and feedback, find us on our Google Group.

-Posted by Chris Ramsdale, Product Manager

The Google Creative Lab team has built another fun Chrome Experiment called Cube Slam. Cube Slam connects players into a three dimensional, virtual gaming arena, complete with real-time audio, video, and data feeds.
The Google Creative Lab team has built another fun Chrome Experiment called Cube Slam. Cube Slam connects players into a three dimensional, virtual gaming arena, complete with real-time audio, video, and data feeds.

Cube Slam demonstrates some of the coolest new web technologies, all in one application:
  • WebRTC - WebRTC, a free, open project that provides Real-Time Communications (RTC) capabilities via simple Javascript APIs is built right into Chrome and other modern browsers (no plug-in required!). Cube Slam uses WebRTC to transmit a live audio and video feed from your opponent’s webcam, so you can see and hear your opponent react as the game unfolds.
  • WebGL - Using a combination of WebGL and the three.js JavaScript library, Cube Slam provides smooth, responsive, and fast rendering of 3D graphics.
  • Google Cloud Platform - The game is hosted by a scalable, high performance back end written in Go and served by Google App Engine. A STUN/TURN server running on Google Compute Engine is used to exchange data across and between firewalls.

Cube Slam is an open source project, available via this public repository. You can read more about the technology behind Cube Slam.

Here’s a screenshot of one of our engineers playing Cube Slam live:


We hope this Chrome experiment inspires you to build your own applications harnessing the Google Cloud Platform and the latest web technologies built right into Chrome!

Google BigQuery is designed to make it easy to analyze large amounts of data quickly. Today we announced several updates that give BigQuery the ability to handle arbitrarily large result sets, use window functions for advanced analytics, and cache query results. You are also getting new UI features, larger interactive quotas, and a new convenient tiered pricing scheme. In this post we'll dig further into the technical details of these new features.
Google BigQuery is designed to make it easy to analyze large amounts of data quickly. Today we announced several updates that give BigQuery the ability to handle arbitrarily large result sets, use window functions for advanced analytics, and cache query results. You are also getting new UI features, larger interactive quotas, and a new convenient tiered pricing scheme. In this post we'll dig further into the technical details of these new features.

Large results
BigQuery is able to process terabytes of data, but until today BigQuery could only output up to 128 MB of compressed data per query. Many of you asked for more and from now on BigQuery will be able to output results as large as the largest tables our customers have ever had.

To get this benefit, you should enable the new "--allow_large_results" flag when issuing a query job, and specify a destination table. All results will be saved to the new specified table (or appended, if the table exists). In the updated web UI these options can be found under the new "Enable Options" menu.

With this feature, you can run big transformations on your tables, plus get big subsets of data to further analyze from the new table.

Window functions
BigQuery's power is in the ability to interactively run aggregate queries over terabytes of data, but sometimes counts and averages are not enough. That's why BigQuery also lets you calculate quantiles, variance and standard deviation, as well as other advanced functions.

To make BigQuery even more powerful, today we are adding support for window functions (also known as "analytical functions") for ranking, percentiles, and relative row navigation. These new functions give you different ways to rank results, explore distributions and percentiles, and traverse results without the need for a self join.

To introduce these functions with an advanced example, let's use the dataset we collected from the Data Sensing Lab at Google I/O. With the percentile_cont() function it's easy to get the median temperature over each room:
SELECT percentile_cont(0.5) OVER (PARTITION BY room ORDER BY data) AS median, room
FROM [io_sensor_data.moscone_io13]
WHERE sensortype='temperature'
In this example, each original data row shows the median temperature for each room. To visualize it better, it's a good idea to group all results by room with an outer query:
SELECT MAX(median) AS median, room FROM (
  SELECT percentile_cont(0.5) OVER (PARTITION BY room ORDER BY data) AS median, room
  FROM [io_sensor_data.moscone_io13]
  WHERE sensortype='temperature'
)
GROUP BY room
We can add an additional outer query, to rank the rooms according to which one had the coldest median temperature. We'll use one of the new ranking window functions, dense_rank():
SELECT DENSE_RANK() OVER (ORDER BY median) rank, median, room FROM (
  SELECT MAX(median) AS median, room FROM (
    SELECT percentile_cont(0.5) OVER (PARTITION BY room ORDER BY data) AS median, room
    FROM [io_sensor_data.moscone_io13]
    WHERE sensortype='temperature'
  )
  GROUP BY room
)
We've updated the documentation with descriptions and examples for each of the new window functions. Note that they require the OVER() clause, with an optional PARTITION BY and sometimes required ORDER BY arguments. ORDER BY tells the window function what criteria to use to rank items, while PARTITION BY allows you to define multiple groups to be analyzed independently of each other.

The window functions don't work with the big GROUP EACH BY and JOIN EACH BY operators, but they do work with the traditional GROUP BY and JOIN BY. As a reminder, we announced GROUP EACH BY and JOIN EACH BY last March, to allow large join and group operations.

Query caching
BigQuery now remembers values that you've previously computed, saving you time and the cost of recalculating the query. To maintain privacy, queries are cached on a per-user basis. Cached results are only returned for tables that haven't changed since the last query, or for queries that are not dependent on non-deterministic parameters (such as the current time). Reading cached results is free, but each query still counts against the max number of queries per day quota.
Query results are kept cached for 24 hours, on a best effort basis.
You can disable query caching with the new flag --use_cache in bq, or "useQueryCache" in the API. This feature is also accessible with the new query options on the BigQuery Web UI.

BigQuery Web UI: Query validator, cost estimator, and abandonment
The BigQuery UI gets even better: You'll get instant information while writing a query if its syntax is valid. If the syntax is not valid, you'll know where the error is. If the syntax is valid, the UI will inform you how much the query would cost to run. This feature is also available with the bq tool and API, using the --dry_run flag.
An additional improvement: When running queries on the UI, previously you had to wait until its completion before starting another one. Now you have the option to abandon it, to start working on the next iteration of the query without waiting for the abandoned one.

Pricing updates
Starting in July, BigQuery pricing becomes more affordable for everyone: Data storage costs are going from $0.12/GB/month to $0.08/GB/month. And if you are a high-volume user, you'll soon be able to opt-in for tiered query pricing, for even better value.

Bigger quota
To support larger workloads we're doubling interactive query quotas for all users, from 200GB + 1 concurrent query, to 400 GB of concurrent queries + 2 additional queries of unlimited size.
These updates make BigQuery a faster, smarter, and even more affordable solution for ad hoc analysis of extremely large datasets. We expect they'll help to scale your projects, and we hope you'll share your use cases with us on Google+.

The BigQuery UI features a collection of public datasets for you to use when trying out these new features. To get started, visit our sign-up page and Quick Start guide. You should take a look at our API docs, and ask questions about BigQuery development on Stack Overflow. Finally, don't forget to give us feedback and join the discussion on our Cloud Platform Google+ page.

- Posted by Felipe Hoffa, Developer Programs Engineer

Today’s post is from Alex Kennberg, VP of Engineering at Synergyse. In this post, Alex describes how their company uses Google Cloud Platform to build their training solutions for Google Apps. ...
Today’s post is from Alex Kennberg, VP of Engineering at Synergyse. In this post, Alex describes how their company uses Google Cloud Platform to build their training solutions for Google Apps.

Synergyse chose to focus on enhancing training for Google Apps because of the continuous innovation it brings to the enterprise and education spaces. We built Synergyse Training for Google Apps, a fully interactive, measurable and scalable training solution that has been deployed throughout organizations and educational institutions globally.

We chose Google Cloud Platform and Google Chrome Extension as our technology stack. Going with Google App Engine is a perfect fit for us, because as a cloud service we don’t have to worry about IT issues with our servers and we get automatic scaling. At an early stage of development and deployment it might be especially hard to predict what the next year of usage is going to be like. App Engine allows us to focus on our product and not worry about fine details of operating the backend as much. App Engine also seamlessly connects to other Google services.
It’s a pleasure to be able to import a new service by simply importing the right official library. In matter of hours, I was able to drop in authentication (OpenID), database (Google Cloud SQL), storage and OAuth. Everything worked as expected. Since the libraries handle most of the hard work, our backend code is very lean and allows most things to be done by the client-side Javascript.

Pro Tip: Before deploying the latest code to App Engine, change the version in “appengine-web.xml” file. Next, go to the App Engine Dashboard and select your app. Choose Versions in the menu. From here you can choose who gets what version of your backend. Default version is served to everyone, while traffic splitting lets you test new versions on a smaller set of users first. For staging, we force our extension to access a specific version of the backend by pointing it to ..appspot.com.

In order to overlay our user interface (player, menu, etc) on top of Google Apps we built a Chrome Extension. The extension is written in Javascript, using standard browser APIs, jQuery and Google Closure. Specifically, our templates for the HTML parts are using Closure Templates and Javascript is compiled with Closure Compiler.

Google Closure Templates are well designed in that they have short-form commands and discourage me from adding complexity into the views. They also translate into readable Javascript and work well with the compiler. I use the compiler to help catch bugs, minify and obfuscate our code. There are compiler extern files that declare Chrome Extension and jQuery APIs here. To watch for code changes and automatically re-compile the templates and Javascript, I made this open source project.

Synergyse Training for Google Apps uses Google Cloud Platform and Google Chrome Extension to deliver its training to people around the world. With Google App Engine we get security, reliability and automatic scaling out of the box, which lets us focus on core product development. Google Chrome is a perfect vehicle for overlaying Synergyse user interface on top of Google Apps using the latest standard web technologies, and makes for an easy deployment process to our customers.

- Contributed by Alex Kennberg, Vice President, Synergyse


The following post was contributed by Ivan Stoyanov, VP of Engineering for Kinvey, a mobile Backend as a Service provider and Google Cloud Platform partner. Kinvey helps individual and enterprise developers dramatically reduce the time and cost of developing and maintaining a backend for their native and HTML5 mobile apps. ...
The following post was contributed by Ivan Stoyanov, VP of Engineering for Kinvey, a mobile Backend as a Service provider and Google Cloud Platform partner. Kinvey helps individual and enterprise developers dramatically reduce the time and cost of developing and maintaining a backend for their native and HTML5 mobile apps.

Over the past year at Kinvey we have observed a number of mobile development trends. First, developers are building more complex mobile apps and need to take them to market faster. Second, enterprise use cases are now the rule, not the exception. They present specific security and data transformation requirements which demand unique features. Third, even if Backend as a Service, or BaaS, meets the immediate requirements of an application, mobile developers need the peace of mind that their backend platform will be flexible enough to meet their needs in the future.

The best way for us to stay ahead of these trends and ensure we continue to meet developer requirements was to roll down the stack and integrate with Google App Engine. This integration makes it possible for developers to write code on App Engine and have that code run seamlessly as part of their Kinvey backend, offering more choice and flexibility to support more complex app requirements.

Increasingly Complex Requirements
Kinvey’s answer to complex custom requirements has been Business Logic (KBL). This feature allows developers to write their own code, in JavaScript, which Kinvey executes in a multi-tenant virtualized environment based on node.js. KBL supports common use cases such as message triggers on data changes and accessing third party APIs.

Yet as use cases grow in complexity, we find this feature is limited in several ways:

  1. The APIs are highly asynchronous. For many developers this is not a problem, but for a growing number of them, the execution flows are confusing and the complexity beyond a single page of code gets very high.
  2. Code is limited to a single language - JavaScript. Android developers, for example, are much more comfortable in Java territory, as are enterprise web application developers.
  3. Only Kinvey-approved modules are allowed.

Over the next month, as a technology partner of Google, we will make it possible for Business Logic code to run on Google App Engine, seamlessly hooking the App Engine app into your Kinvey backend. Developers will be able to write code in multiple languages, such as Java and Python, with simpler synchronous APIs as well as take advantage of Google App Engine’s development workflows.

Most importantly, developers will be able to go beyond Kinvey’s sandbox requirements and run virtually any APIs, including the large set of built-in App Engine APIs. For example, an app can take a user uploaded image and resize and convert it using the Image API, or use the XMPP API to enable instant messaging in a collaborative app.

Enterprise Features
Business-to-enterprise applications need to connect to on-prem database systems. Mission-critical apps have especially high requirements - a mobile application that connects to an existing CRM system needs complex user authorization and data transformation flows.

For enterprise mobile developers, this integration means easily running secure instances of Kinvey Data Link and Auth Link on App Engine to unlock enterprise databases such as a CRM system and performing complex BPI integrations.

Peace of Mind
By virtue of being a Platform as a Service (PaaS), Google App Engine provides stronger isolation, allowing developers to run virtually any code they want. This will allow for highly custom use cases to be offloaded to the PaaS infrastructure, while the backbone remains the out of the box backend provided by BaaS.

We think of this integration as bringing together the best of two worlds: BaaS and PaaS. The combination of these two cloud-based services allows developers to easily build complex applications on of a virtually limitless platform. As you can see in the Mobile Cloud Reference Architecture (below), we see Google App Engine as a bridge from BaaS to Enterprise systems.



For more information on the Kinvey / Google App Engine partnership and to get started building your enterprise mobile apps, visit us at kinvey.com/google-cloud.




Google Cloud SQL lets developers host their MySQL databases on Google Cloud Platform. We take care of replicating the data, backups, updates and other admin overheads so you can concentrate on launching great applications. The ...
Google Cloud SQL lets developers host their MySQL databases on Google Cloud Platform. We take care of replicating the data, backups, updates and other admin overheads so you can concentrate on launching great applications. The Cloud SQL API we are launching today makes it easier to manage lots of instances programmatically by providing an API for common tasks such as creating and deleting instances, increasing or reducing their size, and taking and restoring backups.

For example, you can create a new database instance in your project like this:
curl --header "Authorization: Bearer youraccesstoken" \
     --header "Content-Type: application/json" \
     https://www.googleapis.com/sql/v1beta1/projects/yourprojectid/instances \
     --data "{\"instance\" : \"instancename\",  \"project\" : \"yourprojectid\", 
\"settings\" : {\"tier\" : \"D2\"}}" -X POST
Orangescape is already using the API to run Kissflow, their popular workflow SaaS. They provide a separate instance for each of their customers, which gives great performance and security isolation (they avoid the ‘noisy neighbor’ problem). The result is thousands of customers and thousands of databases, and they use the Cloud SQL API to manage them all. This integrates the database management process into their service -- create, delete, backup, scale up, scale down -- with no admin overhead.

The Cloud SQL API is now available and you can read more about Orangescape’s experience in this case study.

- Posted by Joe Faith, Product Manager

(cross-posted on the Android Developers Blog)

Many of the best mobile app experiences are powered by services in the cloud. However, running your own servers can detract from focusing on your client experience. Google App Engine has long been a fantastic platform for mobile developers such as ...
(cross-posted on the Android Developers Blog)

Many of the best mobile app experiences are powered by services in the cloud. However, running your own servers can detract from focusing on your client experience. Google App Engine has long been a fantastic platform for mobile developers such as Pulse and SongPop. Now with the Mobile Backend Starter, we've made it even easier for you to get started with App Engine.

Mobile Backend Starter

Mobile Backend Starter is a one-click deployable, complete mobile backend that allows you to reap the benefits of a cloud backend with none of the headaches. It provides a ready-to-deploy, general purpose cloud backend and a general purpose client-side framework for Android.

Mobile Backend Starter gives you everything you need to rapidly set up a backend for your app, without needing to write any backend code. It includes a server that stores your data with App Engine and a client library and sample app for Android that make it easy to access that data. You can also add support for Google Cloud Messaging (GCM) and continuous queries that notify your app of events you are interested in. To keep users data secure, Mobile Backend Starter also includes built-in support for Google Authentication.


Features of Mobile Backend Starter include:
  • Cloud data storage: Users change devices and increasingly use multiple devices. Store any amount of data per user in the cloud to be accessed from anywhere.
  • Pub/Sub messaging: Send messages from one device, to any or all other devices. You can easily use 1:1 and 1:many messaging as well as broadcasting. This feature is useful for various applications including social apps, forums, chat, gaming, and group collaborations.
  • Push notifications: Data updated on one device is automatically available on all devices with GCM for Android.
  • Continuous queries: Create queries that run continuously on the server, automatically feeding updates to the client. These queries are powered by Prospective Search.
  • Google authentication and authorization: Keep data isolated per user or shared among users.
  • Free to get started, scales effortlessly with your needs: You can start by handling hundreds of users for free, then grow to any scale.

Quick setup and integration

You can setup and run the Mobile Backend Starter in just a few steps:
  1. First, go to the http://cloud.google.com/console, and create a project. Then click deploy.
  2. Click on settings to go to the admin panel for your new backend.  Under "Authentication / Authoirzation" select "Open (for development use only)" and save the changes.
  3. Next, download the Android client project and open it up in your Android IDE. Locate the Consts.java file and set the PROJECT_ID to the Project ID you created in the Google Cloud Console. 
  4. Now just build and run the Android application and you have a cloud enabled Android application

    Check out the complete docs for details on setup and to find out how to enable authentication, send push notifications, and use standing queries. The best part is you can download the complete source code of the backend on GitHub and customize it to meet your needs. 

    See Mobile Backend Starter in action at Google I/O

    To see Mobile Backend Starter in action, check out our talk at Google I/O 2013 (embedded below) called "From Nothing to Nirvana in Minutes: Cloud Backend for Your Android Application." The talk shows how to use Mobile Backend Starter to create a new backend server and integrate it with an Android app via Google Cloud Endpoints and the Google Plugin for Eclipse. We look forward to hearing your questions and learning about the amazing applications you have built. You can find us lurking on the Cloud Endpoints StackOverflow forum.