Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Abel Avram on Sep 13, 2011
Google has reacted to recent developments regarding the increase in GAE prices which took developers by surprise, making a number of adjustments to the pricing plan, the most important being: the new billing is delayed until November 1st and the number of free Instance-Hours is raised from 24/day to 28/day.
Google announced that GAE will leave the 3 years long preview state and enter normality back in May at IO 2011, practically saying that the previous pricing scheme did not provide enough revenue to sustain their cloud business:
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.
At that time, they announced a new pricing list and details on how users will be affected and how they can see the costs under the new pricing options. Google said that several features available to GAE business users (GAE4B) will be available to everyone, including “SLA, SSL for custom domains, SQL, Operational and Developer support, and the new business-oriented Terms of Service.”
Google also announced new Usage Types – Free, Paid Apps, and Premier Accounts –, and new usage fees for Instances, APIs, and Datastore Storage. The most important change seemed to be that from paying per CPU cycles to paying for Instance-Hours (IH). Under the new pricing scheme, one would pay for each application instance running even if that application is mostly idle. Also, the quotas for free usage have dropped, especially the API calls.
Google reiterated their intent to switch to the new billing system on August 31, saying that it will go into effect in the second part of September. Unlike the previous announcement which went mostly unnoticed, this want created a strong reaction among Google’s over 100,000 GAE developers, many being surprised by the change, and some expressing their dissatisfaction and announcing moving to other cheaper solutions.
Analyzing some of the comments posted by people on Google’s blog post, it seems that most complains come from people having simple websites, mostly static, and being idle most of the time. This is the case of Guillaume Laforge, Groovy Project Manager, who commented on a related Google Plus post:
I have a simple blog application (http://glaforge.appspot.com), with not much traffic, but enough of regular hits from random guys, feed readers, and Google search bots to keep my blog instance always on. Despite having toggled the "sliders" (max instances / idle time), my small blog will cost me quite a bit. I was really expecting a small blog website wouldn't be not free to run. I'm really disappointed.
Ten days later, Google reacted and announced a number of adjustments to the new GAE pricing. Besides better analysis tools, comparative usage reports, an extended 50% discount on instance prices until December 1st, and the intent to introduce Premier Accounts as soon as possible, the main adjustments are:
Also, Google has provided advice on how to lower the costs of running apps on GAE and how to manage resource usage, but the basics are: lower the number of running instances to a minimum possible and using reserved Instance-Hours which are cheaper. A developer applied the advice and wrote:
My billing went from $0.14/day to $3-$4/day (i can't afford $4/day... $1/day is my maximum right now). I set the "Set Max Idle instances" to 1 since I don't really need more than that most of the time, the 5-8 instances that I had were idle almost all day serving few requests. My costs are down to $0.39/day. 3x increase is more than ok with me, the old prices were to cheap anyway.
Premier Accounts offer the opportunity to large businesses to pay a monthly $500 fee for one account without having to pay $9/month/application as it is the case for Paid Apps. But there are still additional fees for running instances and using bandwidth. Although Google has touted the new GAE features as beneficial for large organizations, their costs will rise by a factor of 2 to 5, according to Peter Magnusson, Engineering Director at Google responsible for App Engine:
That said, the new App Engine prices are higher. In fact I expect many large applications after optimizing will end up paying 2-5x more than before. Many small applications will no longer fit into the free quota without optimization or performance tradeoffs. And many applications that only had to pay a little bit above free quota now have to pay more.
Google still believes their pricing is competitive to other offers, and invites developers to write to appengine_updated_pricing@google.com if that’s not their case.
The WebSphere Liberty Profile for Developers: An Introduction
Good Relationships: The Spring Data Neo4J Guide Book
Introduction to WebSphere Liberty Profile
Introducing SQLFire: a memory-optimized, high performance SQL database
VMware vFabric SQLFire - Test drive the data management system with memory speed, horizontal scalability and a familiar SQL interface
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
No comments
Watch Thread Reply