New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Does Google AppEngine have a viable competitor nowadays?
elwebmaster
Member
in General
Looking at the PaaS (Platform as a Service) market, I am finding only two options: Google App Engine and to some extend Amazon AWS.
I am talking about a service that can take care of an infinitely large database, load balancing, high availability, etc. with no maintenance required. Basically I just throw some Python code at it, and it will work equally fast for 100 users or 10,000,000 users.
Is there anything cheaper than Google App Engine which can do this? (Excluding Baidu BCE)
Comments
Maybe try mesosphere on digital ocean
Scalability isn't just a matter of software, it's mostly a matter of software architecture. How your app is coded matters a shitload lot. In regards to the db, how your schema and your queries matter the most in terms of speed and efficiency. Certainly, not having to create an manage a db cluster yourself is a win, but nothing more.
There is a lot more than that though. Like optimizing the DB servers. Knowing how many DB servers you need and in what configuration (multiple masters, master-slave, etc.), making sure they can all recover from failures. Then doing the same with the application server, again how many you need, how do they recover from failure, etc. Same with the reverse proxy / load balancer. And finally you have to secure all of that and keep it updated.
Mesosphere looks interesting.
Well, yes. That's why I said it's a win but that's only a small part of the picture and usually the easiest one. My point is that "getting a cloud db" !== "solved the scalability problem". You see, in our times, horizontal scaling in the sense of infrastructure is almost a commodity. Scaling the infrastructure doesn't equate scaling your application. That's my point.
I agree with you that having a scalable and robust infrastructure is only part of the solution, but I don't agree that it's the easiest one. Check out this discussion for example: http://stackoverflow.com/questions/25678049/how-to-setup-global-load-balancing-using-digital-ocean-dns-and-nginx . It doesn't even go into DB scalability and backup / restoration procedures.
Easiest in comparison, not easy There's nothing easy in scaling, unfortunately.
That guy is clueless, no wonder the top answer starts by pointing that out (politely).
So how does one build I highly scalable system then? I don't really care about "global load balancing" but I am truly scared when I think of all the things that can go wrong when a high number of users are hitting the system simultaneously, and the system has a large amount of data. Add to that the need to change table schemas or restore a DB backup because the one DB server failed...how would one even perform such tasks under load is beyond my imagination.
Eh...there are many more than that.
Microsoft Azure (which supports Java, Python, Node.js, as well as .NET): http://azure.microsoft.com/en-us/services/app-service/web/
OpenShift from RedHat: https://www.openshift.com/
IBM's BlueMix: http://www.ibm.com/cloud-computing/us/en/paas.html
There are plenty of others but I'm thinking that if you were really interested in, say, Oracle's PaaS offerings you wouldn't be asking on LET :-)
How are these PaaS offerings? Do they have an API to a datastore that will always be optimized, backed up and can handle any number of requests I throw at it? To me these are just IaaS advertised as PaaS. If I wanted IaaS I would go with iwStack.
From what I gather so far AppEngine has two alternatives: Heroku and AWS (but batteries not included).
The theoretical part of my response:
When your dataset is so huge that it needs to span multiple dbs, you need to "shard" your data, or everything becomes slow. The cluster will take care of the "sharding" but you have to configure it properly and most importantly, you have to make sure your queries are designed in a way that exploits sharding (otherwise it makes no point having it anyway). Another thing to notice is that at some point, you may have to pre-calculate query results on regular intervals (e.g. for aggregates). Some queries that work fast now, will become very slow as the dataset grows.
These are just 2 examples on a non-ending list. Tbh, I haven't seen any book/resource that can hold one's hand from start to finish, it's more of an ad hoc thing.
So, this gets me to the practical part of my answer: Build your app on any cloud MySQL (if you're going the relational way) and if and when your app gets huge, you will have more than enough money to hire a software architect with experience in scalability to re-design your app. In the mean time, just get a good enough programmer that understands speed and efficiency.
And that is because the scenarios are all different. Heck, even the same ERP, for example can be used extremely differently in different environments.
Each solution must match local conditions and your approach is the correct one have someone handle it as it grows, will also optimize hardware and software needs and optimise the indexes, querries, caching backups/replication, etc.
You must be there with the hand on it's pulse to know what it needs, where are the bottlenecks, no books can replace that hands-on experience and, why not admit it, intelligence to learn and adapt, investigate and guess right.
Um, how are they not? Azure was an earlier PaaS pioneer.
Is it really just a "data store" you want? DB as a service? There are plenty of those but that's not what I would call PaaS though the term is not well defined.
Google Cloud SQL, Racksspace, ClearDB, etc. Or MongoHQ, and whoever is doing CouchDB (I think it's IBM). These are DB as a Service (DBaaS) where you get a set amount of space and transactions. You want more, you pay more, but the service part of it is that you're not specifying what kind of hardware, you're not tuning/administering the engine, you're not responsible for backups, it's understood to be highly available with an specified SLA and you don't care about the architecture underneath that makes that happen, etc.
Yeah, I'd forgotten Heroku.
Let's be clear on terms:
IaaS: provider gives you a VM and other components, you put your solution together.
PaaS: you provide the code, provider gives you an environment. You don't specify operating system, CPU, etc. You pay per transaction or per abstracted performance metric. And yes, Azure is an excellent example - you code to their platform but you don't specify it's going to run on a machine with so many CPUs or even what the operating system will be. You give them code and they run it, just like App Engine.
SaaS: provider provides the code, you just use it (e.g., Salesforce, or even Gmail as an example).
Azure is the only offering of the ones I've listed that I'm really familiar with. While they now offer IaaS, they also do PaaS and did it originally. You'd code up a web app and they ran it for you...just like App Engine.