Network latency with using different PaaS solutions - google-app-engine

Not sure is this belongs to stackoverflow or stackexchange. Mods - please point me towards the right platform.
I am unable to find statistics for an average network latency (due to network calls) and average cost hike (because these platforms also charge for network ingress/egress) due to the amount of web-service calls involved - especially when we use different providers for webapp hosting and database hosting. Pretty much everything is on SSL to add more delay. Is this delay/cost noticeable to a consumer ? I understand caching will help, but there's a limit to that.
Just to add some context - I am wondering if it's a smart decision for a startup to go with PaaS (I am planning to use Cloudbees/mongolab); or prefer rolling out everything on IaaS (like EC2). I guess GAE will not have such issues because everything Datastore is a part of their cloud ?
Thanks !

Disclaimer: I'm working at CloudBees. Contact me ndeloof#cloudbees.com if you want to discuss specific application constraints
CloudBees (and probably other PaaS, can't tell) don't bill for network traffic. Compared to an IaaS that would bill I/O, network, CPU cycles, etc, a PaaS offer a higher level abstraction then pricing model.
Network latency indeed is a major topic being hosted on a PaaS, that may be hosted on another continent. CloudBees offer US-east and EU-west regions to host application. For European customers, being hosted in EU zone, with low-latency network connection is a major improvement.
Hosting on a IaaS vs a PaaS can make sense, but probably not as your startup is in early stage. Use the PaaS as a booster to get quicly online and deliver features to your customers. If/when you're successful, maybe you'd prefer for whatever reason to switch (partially?) to a IaaS, and even later follow Facebook and Google building your own DataCenter :P
We have many startups as CloudBees customers, that benefit high level service to reduce Time-to-market, and focus on company actual business. Even working on an IaaS is fun for engineers, from business perspective it's not really what you want developers to focus on when your company has to be quick on a competitive market - and there's lot's of other topics you can have engineers to have fun with ;)
I don't get your comment on GAE. Google is indeed hosting his own DataStore. A PaaS like CloudBees relies on partner SaaS for Mongo (mongoHQ.com) but as this one is hosted on AWS as well network latency is the same as if CloudBees hosted it's own mongo instances.

Related

Comparing cloud hosting technologies(Azure, EC2 or Google)

I'm going to start a simple SaaS application and am considering which cloud technology to go with(Azure, EC2 or Google).
Can someone who experience both (actual use)point the pros and cons(performence,costs,easy to develop,easy to maintain) of each technology and recommend his favorite?
Have you google'd this question?
https://softwareengineering.stackexchange.com/questions/64727/windows-azure-vs-amazon-ec2-vs-google-app-engine
Windows Azure for web developers vs Amazon EC2
http://programmerpayback.com/2009/02/04/scalable-windows-hosting-mosso-vs-ec2-vs-azure/
http://news.techworld.com/data-centre/3228389/windows-azure-versus-amazon-ec2/
This has been asked quite frequently with some fantastic answers.
If you are big into Java(Grails, JRuby etc)+MySql+ tomcat development nothing beats AWS elastic beanstalk. It let's you create a "real" relational mysql database on their infrastructure. And they provide 1 year free usage tier but it does not include RDS
Azures is great for all things microsoft. Though one can use AWS for IIS and MSSQL based app I have not done the price comparison myself.
Google AE is great from price point of view but you have to leave some of your conventional development practices on a side, one of them being relational database. This was one of the biggest reason why I did not try GAE. There is no fun in writing Grails app without the powerful GORM.
In current market other also provide cloud services like Microsoft Azure, Google. Then why Amazon? and what different service AWS provide than others. Amazon holds more than 36% stake in the cloud market. Also, top companies including Fortune 500 use Amazon Web Services. They all host their servers on AWS. The main reason behind is Amazon provide good service also its services are low cost comparatively others service, providers.
Why we need to learn AWS?
1) AWS is the leader and Fastest growing in the Cloud Computing market
2) It has more job opportunities than any other Cloud Provider
3) It has a more mature model of infrastructure, hence has a full stack of services, which complement each other
4) Companies are reserving a large share of their IT budget for upgrades and innovations in the cloud.
Here You will get a detailed description
https://answerdone.blogspot.com/2018/04/why-learn-amazon-web-services-aws-and.html

Final GAE vs AWS architectural decision

I know this has been asked one way or another before, but most of the main issues to do with GAE stability seem to have been asked around the end of 2008, early 2009, or aren't directly related to games at scale (which I'm interested in).
Basically, I have been arguing back and forth with my business partner about whether to use GAE or AWS for the back-end of our social game engine, and now it's crunch time. I love GAE (Java) for so many reasons, and although it used to be unstable, it's pretty good now. The main argument in favour of AWS is the fact that AWS has proven itself with multiple games running tens of millions of active users per day. The obvious pin-up child for AWS is Zynga, with its Farmville peaking at 80+million DAU. And that's just one of the hugely successful games running on the AWS infrastructure. Remarkable achievement.
So, one way or another it's KNOWN to work. GAE on the other hand doesn't have any examples that I could find doing these sorts of numbers. Not even close. So can I trust it? Is there a single example of a large social game with 2 million+ Daily Active Users, using GAE?
The main considerations for our social game back-end are:
Reliable CDN (Amazon CloudFront/S3 is excellent for this, as is Google's obviously excellent DataStore).
Ability to scale without falling over (AWS-EC2 is proven here, GAE doesn't seem to have examples of large game apps which can run into the 1000s of requests per second. GAE used to be quite unstable in this regard and so is my main concern).
Reliable no-SQL database. (AWS-SimpleDB and Google's DataStore are both excellent for this. We really don't need SQL).
Support/someone to call/contact if there is a problem. (This is one of the biggest worries with GAE. I have no idea who I can call, or if it's even possible. AWS has an SLA and support.)
I look forward to your thoughts, but please also note, this is not intended to start any sort of flame war. I love both systems, but both have their positives and negatives, but I'm about to make an architectural decision that likely won't be undone moving forward.
Regards,
Shane
I've never worked with AWS-EC2 so I'm going to share my knowledge just on the Google App Engine side.
Google App Engine is not meant to be a CDN; though it can serve static content through its powerful infrastructure providing caching close to the users, it does not guarantee the same kind of high quality and high availability service of a real CDN because it's not part of its duties.
Further data:
Maximum size of a file using the BlobStore service: 2 Gigabytes
Maximum size of a static file: 10 Megabytes
Currently App Engine always returns 200 status for static files even on Conditional gets (you have to rely on third party caching library like cirruxcache for example).
Recently Google App Engine team has shut down the App Gallery for one simple reason: too many Toy Apps!
Google wants to counteract this tendency showing successful businesses case studies; here are some of them:
BuddyPoke (viral Facebook app with 65 million installs)
WalkScore (serves 3 million request a day to thousands of real estate partner sites)
Webfillings
Snapabug
Optimizely
Ubisoft Facebook TikTok game
Other interesting case studies here
"We are well aware of downtimes and reliability issues, and are working hard to solve them: Improving App Engine reliability is our number one priority" was recently said by a Google Developer Relations Manager here.
App Engine is still in beta and is an evolving platform so you have to be prepared to deal with downtimes and issues.
Google App Engine team has just launched a preview of App Engine for Business providing 99.9% uptime service level agreement and premium developer support available.
Here is my opinion for what it's worth:
I'm aware that it's a tough call; having read a lot of articles about GAE I have mixed feelings about it because you can go from the recent catastrophic Carlos Ble report to the happy experience of Flower Garden or Gri.pe.
App Engine for Business looks promising and I would consider it in the case of a serious business project plan.
The fresh SDK 1.4.0 is huge and it clearly shows that the Team is really pushing hard to fix some annoying issues (Warmup requests) and relaxing some limitations (10 minutes process on TaskQueue).
Last thing to consider: if you are going to have big numbers, the Google App Engine Team will probably take your app as a successfull case study to follow with a boost of free and powerful Hype.
BuddyPoke is one example of a large-scale social app running on GAE. How large I'm not sure. This article says 30m daily page views (not users):
http://googleappengine.blogspot.com/2008/10/app-engine-case-studies.html
Their facebook page says 2.7 million monthly (not daily) users:
http://www.facebook.com/buddypoke
Although, they are also on a heap of other social networks:
http://www.buddypoke.com/
Personally I decided to go with GAE, for a couple of main reasons:
The unit of scalability is a single request, not a whole instance like it is with AWS.
I can work at a higher level, without having to worry about configuring instances.
If your point 4 is a big one for you, then you may be better off with AWS. With GAE there appears to be nothing you can do, and no-one you can contact.
About a week ago I had an issue with my app - it had suddenly started failing in Google's code, in a location which had been working fine for the last 5 days, ie since I had last uploaded my app. The only way to report issues to Google seems to be via their production issue template, here:
http://code.google.com/p/googleappengine/issues/entry?template=Production%20issue
I reported the issue, and didn't hear anything. Since it's running on Google's servers I was unable to resort to any 'usual' emergency tactics like restarting a server. An hour later and the problem resolved itself - I'm not sure if someone at Google saw my message and fixed something, or if it just went away. I updated my bug report to say the problem was fixed, but even now a week later the issue hasn't been closed or even acknowledged. Also since the issue has to be posted publicly, my app is now getting random hits from bots.
Admittedly my app is currently only in beta and so only has a hundred or so users, and so it wasn't a major incident for me. If I was getting thousands / millions of hits, maybe either Google would have noticed the problem themselves earlier, or they would have paid more attention to my bug report.
On your point 3, even my small app with a small amount of traffic throws occasional data store errors (even during times which aren't reported on the availability charts as outages).
Having said this, I still like GAE (I am using the Python version), and plan to stick with it. The promise of GAE is its scalability - although it falls over occasionally now for my small traffic, it shouldn't fall over any more when it scales to much more traffic (ie your point 2), provided I've coded it correctly to avoid contention. I'll see how it goes.
Finally regarding your point 1, the blobstore and/or static files are more like a CDN on GAE, than the datastore. However for very large amounts of traffic, a real CDN may be cheaper. It's also not necessarily a CDN, see Google app engine & CDN.

Google apps engine vs virtual/dedicated server

Hi I roll out some site on google apps engine but I'm not really happy about it for this reason:
django is not fully supported so no administration etc.
using django patch etc. sometimes give me some problem when new release on gae is out
a registering domain (with go daddy) and add it to google apps engine (no redirection)
seems take too times for display page
waste times to avoid some restrictions eg no sql, query number limited etc.
little scare because I've no great traffic but is rising up so I can predict how much
really cost
so my question is for your experience is better a slicehost style server (some dedicated server cost $50 and give you 1,5TB ) or other or google apps engine is economic and pro.
just for getting idea my site is yappiedo.com and sometimes seems slow
other Idea and suggerstions are welcome
thanks
In grab bag format:
As long as you have a model for making money off your visitors, you do not need to be scared about rising costs. See this blog for what happens when this guy was hit with major traffic. The costs are reasonable (for him at least) and any other non-GAE solution would have died a screaming death, costing him many thousands of dollars in lost revenue.
You are not working on a traditional relational system. You need to design your application to work with GAE's strengths, not to fight GAE's weaknesses. If you spend all your time working around datastore limitations, take your data model back to the drawing board and make one that plays well with GAE. De-normalization is usually the key word.
There are significant slowdowns associated with starting an instance of your application the first time. These go away when your app is hit often enough that it stays in memory
The should be no difference between hitting *.appspot.com and a properly setup google apps domain. Check your DNS configuration.
And the answer is: depends.

Looking for force.com's comparison with other cloud services & its pricing model

Lately I've been looking at force.com which happens to be SalesForce.com's cloud initiative. However, what I am unable to draw is its comparison with Amazon & Azure platforms. Force.com seems to be targeting Enterprises primarily, so I am not sure if as a small shop, I should be going that way. Mine is going to be a social networking portal. What attracted me to force.com is the 'chatter' platform. I am struggling to find information w.r.t. pricing of using this platform. Most of the pricing details are written in the format $xyz/user/month. Now that may go well for an enterprise but not for someone like me who is going for a social networking with unpredictable number of user. I get a feeling that I am missing something somewhere. Further, I don't see many review about the platform. Can someone throw some light on that as well?
Force.com is absolutely a PaaS offering making SFDC more than a CRM SaaS player. That being said I do not see them offering Chatter as a stand-alone application anytime soon, if ever. Force.com does have it's own pricing model. This is all readily available on their web site.
As always, it depends on what you want to achieve. Force.com is ideal for forms based, data-centric application development - check out Jason Ouelette's book on Force.com if you're interested in learning ideal app dev situations for Force.com. I suspect even the most aggressive Force.com supporters would not think of Force.com as being ideal for your purposes. Zoho and Caspio offer data driven PaaS as well, but again I do not think this is ideal for your application.
If I were in your position I would try to leverage a platform already developed for social networking purposes like Ning or even something like Google Groups. Can you achieve 90%+ of the end user functionality you're looking for with free services readily available?
This article is old but perhaps some of these examples other than Ning might help: http://www.techcrunch.com/2007/07/24/9-ways-to-build-your-own-social-network/
The Force.com developer challenges have shown you can build just about anything on Force.com, but just because you can do something doesn't mean you should.
To the other respondents - if you're not taking PaaS, in general, and Force.com, specifically, seriously as Custom App Dev platforms then you're behind the curve. Force.com is a great platform but I do not think it is well suited for your particular needs.
Force.com fails to deliver on one of the key cloud promises: scalability. It is a very resource-constrained environment, and developing even CRM products on it can be a trial if your customer's model of their business is not in line with Salesforce's. It is definitely not the right solution for a casual social-networking platform. You will be signing up to have your hands tied for very little gain.
A couple of links for you:
force.com evening the score and force.com VS net
Give a bit of a developers view on the force.com platform. You absolutely don't want to use the chatter application as it is available to an "org" but each user will need a license on your org to gain access to chatter.
There is a free edition which allows 100 users, so you could theoretically create a network of 100 users, but after that you'd have to start paying.
SFDC is also a platform, and the capabilities of the Java-like language (APEX) have grown significantly over time.
As for pricing, there are a lot of different options. There are light users and standard users, as well as pricing based on bandwidth. You can also negotiate with Salesforce over the pricing, but AFAIK there are not people building mass market applications based off of Force.com, largely because of these issues.

When should one use the following: Amazon EC2, Google App Engine, Microsoft Azure and Salesforce.com?

I am asking this in very general sense. Both from cloud provider and cloud consumer's perspective. Also the question is not for any specific kind of application (in fact the intention is to know which type of applications/domains can fit into which of the cloud slab -SaaS PaaS IaaS).
My understanding so far is:
IaaS: Raw Hardware (Processors, Networks, Storage).
PaaS: OS, System Softwares, Development Framework, Virtual Machines.
SaaS: Software Applications.
It would be great if Stackoverflower's can share their understanding and experiences of cloud computing concept.
EDIT: Ok, I will put it in more specific way -
Amazon EC2: You don't have control over hardware layer. But you can take your choice of OS image, Dev Framework (.NET, J2EE, LAMP) and Application and put it on EC2 hardware. Can you deploy an applications built with Google App Engine or Azure on EC2?
Google App Engine: You don't have control over hardware and OS and you get a specific Dev Framework to build your application. Can you take any existing Java or Python application and port it to GAE? Or vice versa, can applications that were built on GAE be taken out of GAE and ported to any Application Server like Websphere or Weblogic?
Azure: You don't have control over hardware and OS and you get a specific Dev Framework to build your application. Can you take any existing .NET application and port it to Azure? Or vice versa, can applications that were built on Azure be taken out of Azure and ported to any Application Server like Biztalk?
Good question! As you point out, the different offerings fit into different categories:
EC2 is Infrastructure as a Service; you get VM instances, and do with them as you wish. Rackspace Cloud Servers are more or less the same.
Azure, App Engine, and Salesforce are all Platform as a Service; they offer different levels of integration, though: Azure pretty much lets you run arbitrary background services, while App Engine is oriented around short lived request handler tasks (though it also supports a task queue and scheduled tasks). I'm not terribly familiar with Salesforce's offering, but my understanding is that it's similar to App Engine in some respects, though more specialized for its particular niche.
Cloud offerings that fall under Software as a Service are everything from infrastructure pieces like Amazon's Simple Storage Service and SimpleDB through to complete applications like Fog Creek's hosted FogBugz and, of course, StackExchange.
A good general rule is that the higher level the offering, the less work you'll have to do, but the more specific it is. If you want a bug tracker, using FogBugz is obviously going to be the least work; building one on top of App Engine or Azure is more work, but provides for more versatility, while building one on top of raw VMs like EC2 is even more work (quite a lot more, in fact), but provides for even more versatility. My general advice is to pick the highest level platform that still meets your requirements, and build from there.
This is an excellent question. Full disclosure as I am partial to Azure but have experience with the others.
Where I think Azure stands out from the others is the quick transition from on prem to the cloud. For example -
SQL Azure - change connection string, upload DB, go!
Queues work a lot like MSMQ.
Blobs are pretty much blobs any way you shake them but they scale like crazy.
The table storage component is good because it provides incredible scalability for name/value pairs - but takes some getting used to.
Service Bus is my favorite of the services because it allows for a variety of communications paradigms. Two SB endpoints first try to connect to each other, if they cannot, then they route through the cloud - makes for very secure and scalable processing when firewalls tend to get in the way.
Access control list - paired typically with the service bus to make sure the right people access the right things - think SAML in the cloud.
I hope that helps!
My cloud experience is currently limited to Salesforce.com
For standard business operations and automation it provides a significant number of features that allow us to get apps up and running very quickly. We are particularly benefitting from the following:
Security (Administrators can control access to objects and fields)
Workflow & Approvals
Automatic UI generation
Built in reporting and dashboards
Entire system (including our custom changes) is accessible via web services
Ability to make the data in the system available through public sites (e.g. eCommerce)
Large library of third party apps to solve standard problems
The platform does NOT solve every problem.
I would not use the platform to model a nuclear power station or build the next twitter.
The major points of cloud computing is to save on costs by paying for usage and enable immediate deployment of computing resources.
The costs are not purely x amount of cents per instance per hour. The costs include maintenance, development, administration, etc. The huge benefit of cloud, in my mind is to liberate the customers from having to manage anything that is not within the realm of their core business competency. If I am an insurance business, I want my developers to concentrate on my insurance problems that help solve needs of my claims, rates, etc. I would rather avoid dealing with problems of email servers, file servers, document repositories, and administrating OS patches, service packs, etc.
Thus, in my opinion, the biggest benefits are derived from the SaaS and PaaS cloud offerings. One should go to IaaS only when PaaS or SaaS have serious restrictions to specific needs (i.e. I need to install a set of proprietary COM components and Azure does not support them).
SaaS is good for commodity type of applications that are not the core line of business for the client, but are more of a utility. These are your typical Messaging systems, Portals, Document Repositories, Email systems, CRMs, ERP's, Accounting, etc. etc. etc. Why reinvent the wheel by writing your own when you can customize a well supported third party product.
PaaS is great for core line of business software that supports companies' main business offering. Abstracts clients from having to deal with OS management and lets clients concentrate on the business system development - something that noone else can do for the client.
One can also take advantage of the benefits of PaaS (let's say, Google App Engine) and extend it, at times and if necessary, by pulling out some virtual machines from IaaS providers (e.g. Amazon) to do some number crunching then just send back the output to Google App Engine.
This way, you get the best of both worlds -- you can rapidly develop scalable apps in GAE, then you can always augment it by running any program you want from Amazon virtual machines.
This keeps changing, now Windows Azure also supports VM, so it is also an IaaS provider now.
Now how about Free Amazon EC2 for a year to do a better comparision. Check this out.
http://www.buzzingup.com/2010/10/amazon-announces-free-cloud-services-for-new-developers/

Resources