cloudfoundry_首先尝试使用CloudFoundry

cloudfoundry

云在这里留下来。 当Google将Java用于其App Engine PaaS平台时（在只有Python之前），我在那里并尝试了它。 上周，VMWare推出了其竞争对手CloudFoundry平台，我想以同样的方式进行尝试。

从那时起，我就玩了一点，与GAE相比，它充满了很多惊喜。 这并不是说GAE不好，实际上，它是第一个在一定流量限制（这是一个很高的限制）下免费的PaaS，但是它确实存在一些限制，对开发人员来说是一个负担：

• 首先，如果您需要保留数据（可能的事件），则必须将JPA 1.0或JDO与下面的DataNucleus数据存储区一起使用。 这意味着您可以忘记NoSQL或MySQL或您首选的RDBMS。 此外，您还必须了解有关DataNucleus的所有知识，以便配置数据存储。 由于它不是一个广泛的产品（例如Hibernate或EclipseLink），因此这可能是一个很大的负担。
• 其次，在每个请求下，整个会话都被序列化。 这意味着每次都会有少量开销，并且可能会NotSerializableException 。 我认为（希望）自从我上次使用该行为以来，此行为已得到纠正，以便仅在需要时（即，将用户定向到另一台服务器时）进行序列化。
• 然后，“云”一词将具有表面价值：您看不到基础架构。 没有日志（尽管可以通过界面看到它们，但是您可以告别所有不错的日志配置），没有配置，没有临时文件，什么也没有！
• 最后，您只能访问Java API的一个子集：没有线程，没有文件等。白名单在那里可用：不要为高数字感到惊讶，实际上很少。 有1498个项目，而Java 6 API有3793个项目，这意味着您仅拥有所有功能的39％！

所有这些意味着您无法使用现有应用程序，无法将其上载到GAE并期望它像在本地服务器上运行一样运行。 实际上，将应用程序迁移到GAE是一个冗长的过程，具体取决于您使用的内容与允许使用的内容之间的差距。 最糟糕的是，一旦迁移，要么不能再在标准服务器上运行（或仅在提供的GAE沙箱中运行），要么既要配置GAE又要花费标准时间（很长！）。

CloudFoundry的好消息是这些限制不存在。 我尝试了两种不同的应用程序：

• Twaattin ，这是我的《 学习Vaadin》书的自定义应用程序，基于Vaadin和HSQLDB。 它还利用线程和文件，并且严重依赖Twitter API。
• Vaadin演示应用程序可以在他们的网站上找到，我已将其“原样”上传并上传。

两者都通过Spring Tools Suite无缝部署在CloudFoundry上。 此外，日志与其他任何本地服务器一样，都显示在“ STS日志”选项卡中。 例如，我忘了包括SLF4J，看到堆栈通知我这一点我感到很惊讶。

至于运行应用程序，则是相同的：它们以开箱即用的预期方式运行。 在我的STS中，我什至可以看到远程文件！ 这是一个Tomcat实例，我可以读取其配置文件和HSQL数据库文件。

整个事情甚至都与Spring无关。 好吧，肯定有帮助。 更具体地说，在没有Spring配置的情况下连接提供的数据库服务并非易事，但有可能的（如果遇到问题，请看这里 ）。 到目前为止，这是我发现的唯一负面问题。

明白这一点：这些不是生产应用程序，我没有执行任何性能测试（无论如何，服务条款都禁止这样做），Beta版不提供任何将来的帐单信息，也没有显示任何指标。 因此，我的观点只是从2年前尝试过GAE的开发人员的角度来看。 有鉴于此，直到证明了矛盾，CloudFoundry才是开发人员的梦想成真。

欢迎对自己测试CloudFoundry有兴趣并且不相信我的人的人这样做（我也希望获得反馈）。 可以在这里发送服务请求。 或者，您也可以在GitHub上获取源代码 ，并将CloudFoundry应用程序部署在自己的基础架构上。

玩得开心！

翻译自: https://blog.frankel.ch/first-try-with-cloudfoundry/

cloudfoundry