Google App Engine [for Business] Goes Mainstream with Usage-Based Billing and New Features
• Updated 5/11/2011 with future App Engine Pricing and Features, the App Engine at I/O 2011, Day 2 post from the App Engine Blog and Navneet Joneja’s Google Storage for Developers open to all, with new features post to the Google Code blog (see end of post).
The Google App Engine Team posted The Year Ahead for Google App Engine! on 5/10/2011 in conjunction with its Google I/O conference being held 5/10 and 5/11/2011 in San Francisco’s Moscone Center:
Google App Engine has grown tremendously since it launched in Preview status in 2008. More than 100,000 developers use App Engine every month to deliver apps that dynamically scale with usage without the need to manage hardware or software. App Engine now hosts more than 200,000 active apps that serve over 1.5 billion site views daily. Over the last three years we’ve collected great feedback from our customers and have continued to improve our services. We are now confident that App Engine is almost ready to graduate from Preview status, and we are pleased to announce that graduation will be taking place later this year. Graduation indicates a long term commitment by Google to App Engine which in turn means a long term commitment by App Engine to our customers!
Google App Engine for Business
As you might recall, Google App Engine for Business (GAE4B) was announced at Google I/O last year. Since then we’ve been testing various aspects of the offering and getting a lot of feedback. At a high level what we’ve been hearing can be summarized as:
- Our customers are really excited about many of the features of GAE4B: SLA, SSL for custom domains, SQL, etc
- The per-user, per-app pricing is not appropriate for many customers that are excited about the GAE4B features because they are not always building applications focused on users within their organization.
- Because App Engine is currently a Preview product, some businesses are reluctant to heavily invest in the platform.
App Engine graduating from Preview later this year!
Based on this feedback we’ve decided to make some fairly large changes:For App Engine, leaving Preview will include providing all paid users a 99.95% uptime service level agreement, operational and developer support, billing via invoice, a new Terms of Service agreement geared towards businesses, and a new, easier to understand usage-based pricing structure for App Engine that is in line with the value App Engine provides. It will also reaffirm our deprecation policy whereby we will support deprecated versions of product APIs for 3 years, allowing applications written to prior API specifications to continue to function.
- We will be leaving Preview to become an official Google product! This is the top priority for our team and we are on schedule to graduate in the second half of this year. This does not mean we’ve stopped development of other much needed features, for example today we are releasing Backends.
- Most of the GAE4B features are going to be rolled into App Engine, enabling all paying customers to take advantage of them. This includes: SLA, SSL for custom domains, SQL, Operational and Developer support, and the new business-oriented Terms of Service. The domain console is currently in trusted tester and will remain so for the time being. GAE4B will no longer be offered as a standalone product.
- In order to become an official Google product we must restructure our pricing model to obtain sustainable revenue. Based on customer feedback this means focusing on usage-based pricing and placing per-user, per-app pricing on hold until further notice. [Emphasis added.]
New App Engine Pricing Model
Although the change won’t take place until later this year, we are announcing this today because it will impact all of our customers and we want to ensure they have enough lead time to understand and account for these changes. We encourage our customers to review the details of the new pricing model [see below], but the major changes are: Usage TypesUsage Fees
- Free Apps: Similar to the Free Apps of today but with more restrictive quotas [Emphasis added.]
- Paid Apps: Similar to Apps which have Billing Enabled today, except they will have a 99.95% SLA and cost $9/app/month in addition to usage fees. Customers will need to opt-in to this.
- Premier Accounts: A new offering which will allow a company to not pay for individual Apps but rather use as many as they need. Premier Accounts will be eligible to receive Operational Support for $500/month in addition to usage fees.
All of these changes (other than the HRD price change) will take effect later this year. We will be providing our customers samples of their new bills before the new pricing model is launched so that they will be able to see what will be changing.
- Instances: Due to customer feedback and to better service memory intensive applications, we will be eliminating CPU hours. Instead, our serving infrastructure will charge for the number of Instances running as a new unit called “Instance-hours (IH)” (1 instance running for 1 hour). These instances will be similar to the instances you can see in the Admin Console today with the exception that we will be improving our scheduler to ensure each instance has an appropriate level of utilization. IHs can either be pay-as-you-go ($0.08/IH) or you can commit to a minimum number of IHs over the course of a week and pay less for those reserved IHs ($0.05/IH).
- APIs: All APIs which are currently charged as CPU hours will instead be charged per operation. This is intended to make it easier to predict and understand the cost of an application. Our website contains the details of the API pricing.
- Datastore Storage: High Replication Datastore (HRD) storage is being reduced in price from $0.45/G/month to $0.24/G/month as of today. HRD has delivered essentially 99.999% uptime since we launched it in January. As of today HRD is the default option for new applications, and we strongly encourage users of the M/S Datastore to migrate to HRD. Master/Slave Datastore storage will increase to $0.24/G/month when App Engine leaves Preview. We are actively working on better tools to make this migration easier.
Thank you!
We are excited to graduate from Preview and we want to let everyone know how much we appreciate the support, commitment, and feedback we have received. We look forward to working with you for years to come!
There comes a time when a business unit must “obtain sustainable revenue” or it isn’t a business. GAE and GAE4B are joining the cloud mainstream as the services leave “Preview” status with usage-based pricing similar to Windows Azure, IBM SmartCloud Enterprise, and Amazon Web Services. I’d guess that 98% of the 100,000 developers run their Google Apps within the current free quota limits.
• The Google AppEngine Team posted future App Engine Pricing and Features on 5/10/2011:
As further proof of going mainstream with GAE and GAE4B, the Google App Engine Team announced the availability of long-running Backends and a High Replication Datastore in a App Engine 1.5.0 Release post of 5/10/2011:
Serving Changes
- Backends: Until now all App Engine applications have been running on short-lived dynamic instances that we spin up and down in response to application requests. This is great for building scalable web applications, but has a number of limitations if you are looking to build larger, long-lived, and/or memory intensive infrastructure. With 1.5.0, we are introducing Backends which will allow developers to do precisely this! Backends are developer-controlled, long-running, addressable sets of instances which are as large as the developer specifies. There are no request deadlines, they can be started and stopped (or dynamically start when called), they can use between 128M and 1G of memory and proportional CPU. If you’d like to find out more, have a read through our Backend docs for Java and Python.
- Pull Queues: Most of our users are heavily using Task Queues in their applications today, but there is lots of room for more flexibility. With 1.5.0 we are introducing Pull Queues to allow developers to “pull” tasks from a queue as applications are ready to process them, rather than relying on Task Queues to push tasks at a pre-configured rate. This means you can write a Backend to do some background processing and pull 1, 10, or 100s of tasks off the Pull Queue when the Backend is ready for more. In addition, we’ve introduced a REST API which will allow external services to do the same thing. For example, if you have an external server running to do image conversion or OCR, you can now use the REST API to pull tasks off, run them, and return the results. In conjunction with these 2 improvements, we’ve also increased the payload limits and processing rate. We are excited both about expanding the use of Task Queues as well as improving the ease of integration between App Engine and the rest of the cloud.
Datastore
- High Replication Datastore as default: After months of usage and feedback on the High Replication datastore (as well as a record of 99.999% uptime so far) we are now confident that it is the right path forward for the majority of our users. So, today we are doing two things: setting HRD as the default for all new apps created, lowering the price of HRD storage from $0.45 down to $0.24, and encouraging everybody to begin plans to migrate. We really appreciate all the time that early users of HRD put into trying it out and finding issues and have fixed a number of those issues with this release.
Changed APIs
- URLFetch API: In response to popular demand, the HTTP request and response sizes have been increased to 32 MB.
- Mail API: We have added a few restrictions to the Mail API to improve the reliability and reputation of the service for all applications. First, emails must be sent from email accounts managed by Google (either Gmail, or a domain signed up for Google Apps). Second, we’ve reduced the number of free recipients per day from 2000 to 100 for newly created applications. Both of these will help ensure mail from your application arrives at the destination reliably.
Administration
- Code downloads: As of 1.5.0, we have expanded the ability to download an Application’s source code to include both the user who uploaded the code to download it as well as the Owner(s) of the project as listed in the Admin Console. Owners were introduced in 1.4.2 as an admin role.
Go
- New runtime: With 1.5.0 we are launching an experimental runtime for the Go Programming Language. Go is an open source, statically typed, compiled language with a dynamic and lightweight feel. It’s also an interesting new option for App Engine because Go apps will be compiled to native code, making Go a good choice for more CPU-intensive tasks. As of today, the App Engine SDK for Go is available for download, and we will soon enable deployment of Go apps into the App Engine infrastructure. If you’re interested in starting early, sign up to be first through the door when we open it up to early testers. See the announcement on the Go Blog for more details.
There are plenty of additional changes and bug fixes in this release so please check out the full release notes, including all issues fixed for Java and Python. Finally if you are interested in where App Engine is heading later this year, check out our other announcement at I/O 2011!
Long-running Backends and a High Replication Datastore indicate that Google wants to compete with Amazon, Microsoft, IBM and others with similar PaaS/IaaS architectures.
The Go Proramming Language site offers documentation, downloadable packages, source code and a live demo in the Go Playground:
About the Go Playground
The Go Playground is a web service that runs on golang.org's servers. The service receives a Go program, compiles, links, and runs the program inside a sandbox, then returns the output.
There are limitations to the programs that can be run in the Playground. They must be single-threaded (but they may use many goroutines). There are also limits on execution time, and CPU and memory usage. The Playground can access only a subset of the standard library (notably absent are network and file system access). Therefore, the only communication a Playground program has to the outside world is via standard output.
Will Go gain market share from Java or .NET? I’m not so sure. The Go SDK for Google App Engine is available currently only for 32-bit and 64-bit Linux and the Mac OS.
• The App Engine Team posted App Engine at I/O 2011, Day 2 on 5/11/2011:
We’ve got a great set of sessions lined up for day two including updates on our progress with Full-text Search and MapReduce. We’ve also got two great sessions on a subject close to developers’ hearts: reliability.
Under the Covers with the High Replication Datastore - At 10:45 am, we jump into the internals of the High Replication Datastore (HRD), explaining how it works, how it differs from the Master/Slave configuration, and why developers love it. Now that HRD is the default configuration and cheaper to use, come find out what you’re missing.
Life in App Engine Production - At 3:00 pm, come meet the team wearing the pagers so you don’t have to, App Engine’s Site Reliability Engineers (SREs). In this session, they’ll give you a view of what life behind the scenes is like and why you should concentrate on your application and let the SREs take care of keeping the lights on. Learn how building on App Engine means your application gets its very own Devops team.
For those of you that couldn't make it to I/O this year, don’t stress. While we wish you were here, the I/O video team will soon have videos of all our sessions available so you can catch up from the comfort of your own home. We’ve even captured a few of our Developer Sandbox companies so you’ll get the full experience!
As session videos become available, I’ll update this post.
• Navneet Joneja’s posted Google Storage for Developers open to all, with new features to the Google Code blog on 5/10/2011:
For those of you who have been waiting to use Google Storage, we’re happy to announce that effective immediately, you can get a Google Storage for Developers account without needing to request an invitation.
OAuth 2.0 Support
OAuth 2.0 is the new recommended Google Storage authentication and authorization scheme. OAuth 2.0 is an industry standard that we’ve adopted across Google, offering many benefits:
- Simpler - never sign a request again! OAuth 2.0 uses access tokens for authentication, which obviate the need for complicated signature schemes. We recommend that all OAuth 2.0-authenticated requests be made over SSL.
- More flexible and powerful - OAuth 2.0 allows for three-legged authentication, where a user can grant an application permission to access Google Storage on their behalf (and revoke the grant at any time if necessary).
- Secure
- Your user name and password are used once to create a long-lived (refresh) token which is scoped to allow access to Google Storage o behalf of that account. Your user name and password never needs to live on disk.
- You don’t need to distribute your long-lived credentials to all the servers that need to access Google Storage. Instead, you can manage your long-lived credential centrally, and use it to create short-lived access tokens that you pass to your host cluster. This means that your long-lived tokens are safer.
- You can revoke credentials at any time.
Learn more about using OAuth 2.0 with Google Storage for Developers here.
Simplified Sharing
We’re happy to announce that your customers and partners no longer need to sign up for Google Storage in order to be able to access data that you’ve shared with them; you can now share data with anyone who has a Google account.New Storage Region: Europe
In response to popular demand, effective immediately, we’re adding a new option for data location. You can now choose to store your data in Europe - and get the same high-performance, massively scalable, reliable service as you do when you store your data in the United States.Regardless of which region you choose, your data will be replicated to multiple geographically diverse Google data centers within the region in order to provide high levels of availability and reliability.
Learn more here.
Team-oriented accounts
Google Storage now uses a team-oriented account model, which allows you to create and manage your account in a more natural way.We’ve moved to the Google API console for signup and administration, and adopted the same project-based account model that is used by other APIs. After creating a project, you configure billing for it once, and can then add any number of developers to it without requiring them to sign up for separate Google Storage accounts. This means individual developers on a team don’t need to configure billing in order to use Google Storage. This change also makes Google Storage account management consistent with other Google APIs.
Since buckets are now associated with projects rather than individuals, you will need to specify the new
x-goog-project-idheader with your list-buckets and create-bucket API calls. However, your existing code will continue to work using your new “default” project that already owns all the buckets you created before we implemented project-based accounts. Learn more about projects and the backwards-compatible default project mechanism here.Support for chunked transfer encoding
Google Storage now allows you to upload your data to Google Storage without knowing the object size in advance, using the standard HTTP chunked transfer encoding mechanism. Using this feature, you can stream data into Google Storage instead of buffering it on your own server before sending it to Google.New API Version
In order to continue to innovate and deliver high-impact features, we’ve found the need to make some backwards-incompatible changes. In order to deliver these features while retaining backwards compatibility for existing code that doesn’t need the new features, we’re introducing a new API version header. The new API version that implements this change is version 2. From version 2 onwards, all API calls will be versioned using the newx-goog-api-versionheader.Version 2 of the Google Storage API does not support HMAC signature-based authentication. Although we strongly recommend that you move your code to use OAuth 2.0, explicitly specify the project ID when creating and listing buckets and use the new API version header, your existing code will continue to work; if you don’t specify the API version in your request, your requests will still be handled by our old API.
Free Trial Use
Starting right now, all new accounts will receive a monthly free quota of:
- 5 GB of free storage,
- 25 GB of free data transfer into Google Storage,
- 25 GB of free data transfer out of Google Storage,
- 2,500 free PUT, POST and LIST requests, and
- 25,000 free GET, HEAD and other requests.
Existing accounts will continue to receive 100 GB of free storage until the July 1, 2011 and, in addition, will also receive the same free bandwidth and requests as new accounts. On July 1, 2011, they will automatically move to the new plan.
The new promotional plan will be effective until Dec 31, 2011. Please note that promotional usage will only apply to a user’s first project that uses Google Storage (for existing users, this is the project that was automatically created for them during the account migration).If you’re an existing Google Storage for Developers user, thank you for using our product and for your valuable feedback that continues to help us evolve the service to meet your needs. As always, we continue to welcome your feedback in our discussion group. If you haven’t yet tried Google Storage, get your Google Storage account and get started for free today.
An obvious advantage of Google Storage for Developers over Windows Azure blobs and Amazon S3 or EBS storage is provision for disaster recovery by replicating stored data to multiple, geo-dispersed data centers by default. On the other hand, a Windows Live Skydrive account offers 25 GB of free storage and doesn’t require a credit card to sign up.
Atom 1.0 site feed
0 comments:
Post a Comment