2009-12-10 107 views
11

这似乎是无法避免的关于云计算的炒作,但到新平台的实际过渡是受到很多的讨论......云托管与主机托管

从理论的角度来看,以下可以说:

云:

  • 结构的变化(你可能不安装任何你想要的)
  • 学习曲线(由于上述)
  • 无故障转移(因为失败是照顾)
  • 颗粒费用(每GHz或GB的支付)
  • 即时的可扩展性(不那么瞬间,但至少透明?)?更低的延迟

管理:

  • 故障转移(取决于提供商)
  • 手动的可扩展性(需要维护)
  • 静态成本(你付出的包,你是否完全或不使用它)
  • 成本较低(仅限入门包)
  • 数据所有权(您这样做)
  • 自由(你呢)?较低的延迟(取决于提供商)

假设上述内容是正确的,然而,在应用程序本身上,逻辑位置是“它取决于......”。 现在出现了一个隐藏的问题:您如何分析您的j2ee应用程序以确定它是否是云端应用程序;知道它是

  • 一中的服务/功能的数量相当大的应用程序(即,小服务程序)
  • 依赖于一个复杂的数据库(即NUM表。)
  • 并不需要太多的媒体资源,主要以文本为基础
+0

CloudHosting +托管托管与无限带宽的母版脚本+资源托管(js/css/img/vid) – Roch

回答

1

你在谈论什么样的云服务? IaaSPaaS,DaaS?

结构的变化(你可能不安装任何你想要的)

依赖:从“管理服务器”的平台(例如GAE)移动可能。(由于上述)

学习曲线

亚马逊EC2可能不是一个大的学习曲线,如果你是用来运行自己的服务器

无故障切换(因为故障照顾)

依赖:E​​C2 - >你必须推出自己的

瞬时可扩展性(不是瞬时的,但至少是透明的?)?更低的延迟 依赖:E​​C2 - >你必须制定此计划/使用附属服务

+0

是GAE不是关系型,但您只关注开发,另一方面,EC2并非如此自动但有关系数据库... –

2

“现在到了隐藏的问题:你将如何配置您的J2EE应用程序,以确定它是否是云或不是候选人;知道它是“

作为一边,使该明确的问题。使它成为这个问题的标题。把它放在问题的开始。如果可能的话,删除所有的假设,并专注于问题。

这就是我们所做的。

  1. 致电您的“云”或“托管服务”安排的一些供应商。不是很多。每一个或两个。

  2. 问他们他们支持什么。更重要的是,他们不支持

  3. 然后,给出不支持的功能的简短列表,查看这些功能的代码。如果他们不支持你需要的东西,你需要做一些架构工作。或者将它们从您的首选供应商列表中划掉

  4. 对于优秀的供应商,请写一份试点合同,让您免费(或便宜)访问几个月来安装和测试。如果它不起作用,你没有付出太多。

“但是,为什么要在尝试托管它时可能无法正常工作?”

什么费用?你可以花几个月“学习”你的代码。或者你可以尝试主持它。通常,“尝试托管它”将在几天内得到答案。仅仅做这件事就不那么费力。

+0

有双方的一切:) 你的愿景“这是不太努力,只是做它。”非常有启发性 –

+1

@ hkernel:在这个行业中有太多的机会。根据既定事实工作更好。所以尝试一些托管并收集一些数据。即使这一切都落空了,你现在有了事实和经验;事实具有实实在在的价值。抓住他们。并愿意付费以获得它们。 –

+0

从已建立的事实开始工作+1 .. –

1

有许多云供应商而据我见过有两种主要类型的人:支持云计算平台

  • 问鼎(如亚马逊的E2C,MS天青)
  • 虚拟实例提供者为您提供创建大量运行实例的能力(例如RightScale)

就平台而言,请注意关系数据库支持仍然很差,学习曲线很长。

至于虚拟实例提供者,学习曲线实际上很少(你只需启动实例),但实例需要某种方式来同步...对于复杂的应用程序,这可能无效。

至于你的原始问题:我不认为你有任何标准的方式可以配置应用程序应该/可以移到云端。您可能需要熟悉这些选项,缩小到几个提供商,并查看您将获得的好处是否会对托管托管(您目前可能正在执行的操作)有任何重大的胜利。

+0

故障转移如何处理,硬件崩溃时数据和软件会发生什么变化? –

+0

好问题。这是你需要问的问题,以及你的托管服务提供商。 –

0

我认为你必须关注的要点是:

granular cost (pay per Ghz or Gbyte) 
instantaneous scalability (not so instantaneous, but at least transparent?) ? lower latency 

更改您的应用程序在云上运行需要的时间量好,但如果云不降低它不会真正的问题您的成本和/或您并不真正需要即时/快速的可扩展性(经典示例是电子商务应用程序)

考虑到这两点后。国际海事组织你应该考虑的是relies on a complex database (ie. num. tables),因为依赖于它的“困惑”,改变到云环境可能会非常麻烦。

1

在某些方面比较谷歌应用程序引擎(GAE)和亚马逊EC2就像比较苹果和橙子。

使用ec2,您将得到一个操作系统,可以安装或不安装服务器软件(tomcat,数据库等;您的选择取决于您选择的ami)。有了ec2,你需要一个(或是一个)系统管理员来让事情顺利进行。 ec2上的负载平衡是你必须弄清楚和实现的东西;我从来没有这样做过。 ec2的一大优点是可以以编程方式启动和停止新实例,并与常规Web服务器提供商进行比较,只需在实例启动并运行时付费。您可以使用此“自动旋转向上/向下”来实现您的负载平衡和故障转移。但是你必须做这个实现(再次,我没有这方面的经验)。

使用谷歌应用程序引擎(gae),所有的系统管理都为您照顾。它也可以根据需要自动扩展,无论是在应用程序端还是在数据库端。你也只支付你使用的东西;没有命中的闲置应用程序不会产生任何费用。 gae的缺点在于您受限于您可以使用的语言; python和java(或者运行在jvm上的东西,比如jruby)。更大的缺点是数据库不是sql(他们不称之为数据库;他们称之为数据存储),并且如果您有现有的数据库,可能需要重新制作ddl;在程序员的时间里,了解它是如何工作的以及如何有效地使用它是一个明确的成本。因此,如果你从头开始(或者愿意重写),并且你有足够的资源和时间来学习它的方法,那么gae可能就是要走的路。如果您拥有系统管理员或系统管理员的技能并且有时间或知道如何设置负载平衡和故障转移,那么ec2可能是一条可行的路。如果你的应用程序会闲置很多,那么ec2是昂贵的;上一次我检查它是每月70美元左右的小例子。

+0

是的,如上所述,一个典型的云应用程序将是一个潜力巨大(风险很大)的电子商务应用程序,因此,转移资本投资到运营投资是有道理的。 (请参阅Above-The-Clouds论文) 我认为,这主要与潜在更大的应用程序有关。 除了价格差异之外,GAE不会告诉您使用的是哪种处理器,而EC2则是.. –