3 ms·
It is true, we're initially targeting providers that will give you a "server via API call". When you're developing against AppEngine (and I imagine Azure), you'
by polvi 17y ago
It is true, we're initially targeting providers that will give you a "server via API call". When you're developing against AppEngine (and I imagine Azure), you're committing to that platform, because it is very very specific. Whereas when you develop against Amazon or Slicehost, the server is the common unit ... which you are free to do whatever you like with.
That said, I think there is a lot of room for a similar project with storage. Amazon S3, Rackspace Cloud Files ... and maybe Azure will fit in there?
As for libcloud, we're trying to provide a DBI like thing for cloud server providers. It's not the end-all solution, but it is a clean first step towards cloud portability.
- sriramk 17y agoYou can hack around it (but like I said, it isn't very clean). I can't speak for AppEngine or the others but on Windows Azure, you're really committing to Windows but not Windows Azure. So in theory, anything that works on Windows should work on us (we don't run things in a sandbox as some people like to say though we do run you currently in a normal user account without admin privs). One way to implement this would be wrap a Windows Azure service around whatever you want to do on a node/server and then deploy that service. For example, if you have a Windows server where you install a ASP.NET app or a PHP site by xcopying binaries, you could do the same thing by wrapping that into a web role and put that in a Windows Azure service. By doing this, you do miss out on some of the advantages of the platform but it should make it fit into your model.