软件设计服务实施方案
云平台具有多种选择和约束,这些约束和约束肯定是由基础架构和业务需求驱动的,这些需求和约束确实使他们的定价计划和客户采用方式多样化。 但是它们通常也具有隐含的价值:考虑到某些约束条件进行设计将有助于扩展和复制,将提供性能提升并增加收入。 要求超时或对出站流量和数据存储使用的限制等约束是否真的那么糟糕? 但是,在为私人托管服务进行设计时,您可能会跳过或忽略其中的一些,而错过了改进服务设计的机会。 这里有几点值得考虑:
- 营利性设计 :无论您选择哪种PaaS,它始终会对网络流量,数据存储连接,数据存储空间等产生限制,这是合理而显而易见的:它们毕竟需要获利。 在为云设计时,您绝对需要面对这些限制,以尽量减少开支(查看数据模型,限制所需数据,限制出站流量,添加缓存机制等),因为您当然希望尽可能增加月收入。 为您的私人托管服务进行设计时,您可能并不会非常重视其中的一些参数,但是稍后会意识到它们的重要性。
- 为性能而设计 :作为上一点的一部分,您可能需要调整您的设计以适应某些云约束,并获得可观的性能提升,这与货币化没有直接关系(但是毕竟会以某种方式对其产生影响)。 您需要限制出站流量,请求超时,数据库中的查询数量,任何长时间运行的流程等:嗯,对这些主题施加一定的健康压力绝对不会损害您的设计。
- 针对最新技术和标准的设计 :PaaS通常不支持所有现有技术或每种技术的所有框架/工具,但它们通常提供众所周知且广泛使用的最常见的框架/工具,因为它们显然需要针对大型社区并提供便利您的部署(及其收益)。 这些限制可能会改变您有关构建管理的决定,例如,放弃您久经考验的ant脚本并在Heroku上使用Maven,或者最终停止使用某个古老而知名的库,而转向一个更现代,更有效的库。 尽管这可能会因意外的学习曲线而对路线图产生影响,并且您可能不会在漂亮的私人主机上遇到这个问题,但是在进行项目时可能是时候提升自己的能力了,您迟早会体会到的。 而且它可以在将来促进新团队成员的整合。
- 抽象设计 :大多数PaaS都将需要某种平台/ API依赖关系,这将使您的应用程序依赖于云平台,这是您肯定会避免的。 添加更多的抽象层可能会解决此问题:例如,您可以在GAE上使用Memcache或Big表,但是您的服务不应该知道您是否真的想保持平稳的可移植性。 确实,这是一项额外的工作,可能会影响选择目标Paas而不是其他目标Paas的决定,但是在以后的举动中值得这样做。 您可能不会在更开放的远程或私有主机上浪费时间和精力,但是您可能会在以后进行复杂的重构,并想知道为什么简单简洁的抽象不属于您的初始设计。
结论
尽管在为私有主机进行设计时会合理地忽略云约束,但是您可以记住一些约束并针对它们挑战设计,从而获得快速的增值:您的设计将如何React? 将应用程序部署到其他地方会容易吗? 您的获利能力会改善您的设计以适应其中任何一种情况吗?
只要听起来不完全是人造的,并且值得一试,您就会发现一些潜在的附加值。 您可能已经遗漏了许多非功能性需求,并且可能还考虑将云平台用于最终部署。 挑选两个或三个最常用的工具(AWS,GAE,Openshift,Heroku,Cloudbees值得一提,但不是唯一的),并敢于进行假想的设计。
软件设计服务实施方案