We don’t allow questions seeking recommendations for software libraries, tutorials, tools, books, or other off-site resources. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(13)
AppScale
AppScale 是一个允许用户部署和托管自己的 Google App Engine 应用程序的平台。 它通过 Amazon EC2 和 Eucalyptus 以及 Xen 和 KVM 自动执行。 它由 AppScale Systems 开发和维护。 它支持 Python、Go、PHP 和 Java Google App Engine 平台。
http://github.com/AppScale/appscale
同时...
...它是2015 年左右,容器似乎是前进的方向。 GAE 的替代方案正在出现:
Google 发布了 Kubernetes,这是他们为 管理 GCE 容器,但也可以在其他集群上使用。
Docker 上有一些即将推出的 PaaS,例如
值得关注的有趣内容。
AppScale
AppScale is a platform that allows users to deploy and host their own Google App Engine applications. It executes automatically over Amazon EC2 and Eucalyptus as well as Xen and KVM. It has been developed and is maintained by AppScale Systems. It supports the Python, Go, PHP, and Java Google App Engine platforms.
http://github.com/AppScale/appscale
In the mean time...
...it is amost 2015 and it seems that containers are the way to go forward. Alternatives to GAE are emerging:
Google has released Kubernetes, container scheduling software developed by them to manage GCE containers, but can be used on other clusters as well.
There are some upcoming PaaS on Docker such as
Interesting stuff to keep an eye on.
我认为现在没有 GAE 的其他替代方案(就代码可移植性而言),因为 GAE 是独一无二的。 当然,GAE 是云计算,但我将 GAE 视为云计算的一个子集。 亚马逊的 EC2 也是云计算(以及 Joyent Accelerators、Slicehost Slices),但显然它们也是两种不同的野兽。 因此,现在您所处的情况需要根据您的需求重新考虑您的架构。
GAE 的直接好处是它基本上是免维护的,因为它涉及基础设施(可扩展的 Web 服务器和数据库管理)。 GAE 更适合那些只想关注应用程序而不是底层系统的开发人员。在某种程度上,您可以认为该开发人员友好。 现在还应该说,这些其他云计算解决方案也试图通过提供 VM 映像/模板来让您只关心您的应用程序。 最终,您的需求将决定您应该采取的方法。
现在考虑到这一切,我们还可以构建也可以满足我们需求的混合解决方案和解决方法。 例如,GAE 似乎并不直接适合您描述的这个特定应用程序需求。 换句话说,GAE 提供的请求数量相对较高,CPU 周期数量较低(不确定付费版本是否会有所不同)。
然而,应对这一挑战的一种方法是构建一个定制的解决方案,其中 GAE 作为前端,Amazon AWS(EC2、S3 和 SQS)作为后端。 有人会说您不妨在 AWS 上构建整个堆栈,但这也可能涉及重写大量现有代码。 此外,作为解决方法,之前的 stackoverflow 帖子描述了一种在 GAE 中模拟后台任务的方法。 此外,您还可以使用 HTTP Map/Reduce 来分配工作负载。
I don't think there is another alternative (with regards to code portability) to GAE right now since GAE is in a class of its own. Sure GAE is cloud computing, but I see GAE as a subset of cloud computing. Amazon's EC2 is also cloud computing (as well as Joyent Accelerators, Slicehost Slices), but obviously they are two different beasts as well. So right now you're in a situation that requires rethinking your architecture depending on your needs.
The immediate benefits of GAE is that its essentially maintenance free as it relates to infrastructure (scalable web server and database administration). GAE is more tailored to those developers that only want to focus on their applications and not the underlying system.In a way you can consider that developer friendly. Now it should also be said that these other cloud computing solutions also try to allow you to only worry about your application as much as you like by providing VM images/templates. Ultimately your needs will dictate the approach you should take.
Now with all this in mind we can also construct hybrid solutions and workarounds that might fulfill our needs as well. For example, GAE doesn't seem directly suited to this specific app needs you describe. In other words, GAE offers relatively high number of requests, low number of cpu cycles (not sure if paid version will be any different).
However, one way to tackle this challenge is by building a customized solution involving GAE as the front end and Amazon AWS (EC2, S3, and SQS) as the backend. Some will say you might as well build your entire stack on AWS, but that may involve rewriting lots of existing code as well. Furthermore, as a workaround a previous stackoverflow post describes a method of simulating background tasks in GAE. Furthermore, you can look into HTTP Map/Reduce to distribute workload as well.
截至 2016 年,如果您愿意将 PaaS(平台即服务)和 < a href="https://en.wikipedia.org/wiki/Function_as_a_Service" rel="nofollow noreferrer">FaaS(功能即服务)在同一个无服务器计算 类别,那么您有一些 FaaS 选择。
专有
AWS Lambda
AWS Step Functions 是对 AWS Lambda 的补充。
Google Cloud Functions
截至 2016 年,它处于 alpha 阶段。
Azure Functions
打开
无服务器
IronFunctions
FaaS 与 CaaS(容器即服务)的竞争效果如何还有待观察。 前者看起来更轻。 两者似乎都适合微服务架构。
我预计功能(如 FaaS 中的)并不是最终的结果,并且许多年后我们将看到进一步的服务抽象,例如仅测试开发,然后是简单语言场景。
As of 2016, if you're willing to lump PaaS (platform as a service) and FaaS (function as a service) in the same serverless computing category, then you have a few FaaS options.
Proprietary
AWS Lambda
AWS Step Functions complements AWS Lambda.
Google Cloud Functions
As of 2016 it is in alpha.
Azure Functions
Open
Serverless
IronFunctions
It remains to seen how well FaaS competes with CaaS (container as a service). The former seems more lightweight. Both seem suited to microservices architectures.
I anticipate that functions (as in FaaS) are not the end of the line, and that many years forward we'll see further service abstractions, e.g. test-only development, followed by plain-language scenarios.
备择方案:
1. AppScale
2. Heroku。
参考:Google AppEngine 的替代方案?
Alternatives:
1. AppScale
2. Heroku.
Ref: Alternative for Google AppEngine?
亚马逊的弹性计算云或 EC2 是一个不错的选择。 您基本上在服务器上运行 Linux 虚拟机,您可以通过 Web 界面(用于启动和关闭)进行控制,当然还可以通过 SSH 或您通常设置的任何方式进行访问......
由于它是您控制的 Linux 安装,因此如果您愿意,您当然可以运行 python。
Amazon's Elastic Compute Cloud or EC2 is a good option. You basically run Linux VMs on their servers that you can control via a web interface (for powering up and down) and of course access via SSH or whatever you normally set up...
And as it's a linux install that you control, you can of course run python if you wish.
Microsoft Windows Azure 可能值得考虑。 恐怕我还没有使用过它,所以不能说它是否有任何好处,你应该记住它目前是一个 CTP。
在此处查看。
Microsoft Windows Azure might be worth consideration. I'm afraid I haven't used it so can't say if it's any good and you should bear in mind that it's a CTP at the moment.
Check it out here.
有点晚了,但我愿意尝试一下 Heroku:
https://www.heroku.com/about
A bit late, but I would give Heroku a go:
https://www.heroku.com/about
您可能还想看看 AWS Elastic Beanstalk - 它与 GAE 功能更接近,因为它被设计为 PaaS,而不是 IaaS(即 EC2)
You may also want to take a look at AWS Elastic Beanstalk - it has a closer equivalence to GAE functionality, in that it is designed to be PaaS, rather than an IaaS (i.e. EC2)
如果您对云感兴趣,并且可能想创建自己的云用于生产和/或测试,您必须查看 桉树。 据称它的代码与 EC2 兼容,但开源。
If you're interested in the cloud, and maybe want to create your own for production and/or testing you have to look at Eucalyptus. It's allegedly code compatible with EC2 but open source.
我更感兴趣的是了解 App Engine 如何轻松地与用于 CPU 密集型请求的另一台服务器相结合。
I'd be more interested in seeing how App Engine can be easily coupled with another server used for CPU intensive requests.
TyphoonAE 正在尝试执行此操作。 我还没有测试过它,但虽然它仍处于测试阶段,但看起来至少正在积极开发中。
TyphoonAE is trying to do this. I haven't tested it, but while it is still in beta, it looks like it's atleast in active development.
向云计算的转变发生得如此之快,您没有时间浪费在测试不同的平台上。
如果您也对 Java 感兴趣,我建议您尝试 Jelastic。
Jelastic 的最大优点之一是,除了应用程序功能的更改之外,您不需要对应用程序的代码进行任何更改,但这并不是因为所选平台需要这样做。 参考这一点,您实际上并没有浪费时间。部署过程非常完美,您可以将 .war 文件部署到任何其他地方。使用 GAE 需要您根据系统需求修改应用程序。 如果您碰巧开始使用 Java 并开始寻找更灵活的平台,Jelastic 是一个兼容的替代方案。
The shift to cloud computing is happening so rapidly that you have no time to waste for testing different platforms.
I suggest you trying out Jelastic if you are interested in Java as well.
One of the greatest things about Jelastic is that you do not need to make any changes in the code of your application, except the changes for your application functionality, but not for the reason the chosen platform demands this. With reference to this you do not actually waste your time.The deployment process is just flawless, and you can deploy your .war file anywhere further.Using GAE requires you to modify the app around their system needs. In case if you happen to get working with Java and start looking for a more flexible platform, Jelastic is a compatible alternative.
您还可以使用红帽的 Cape Dwarf 项目,在 Wildfly 应用程序服务器(以前的 JBoss)之上运行 GAE 应用程序,无需进行修改。
您可以在这里查看:
http://capedwarf.org/
You can also use Red Hat's Cape Dwarf project, to run GAE apps on top of the Wildfly appserver (previously JBoss) without modification.
You can check it out here:
http://capedwarf.org/