
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
多云架构技术随着互联网的不断发展而得到了广泛的应用,而今天我们就通过案例分析来了解一下,多云架构实践需要注意哪些问题。
其实我一直就是这么想的,但有位经验老道的经理说服了我,强调企业应该有能力随时更换云服务商。这话听起来也有道理,所以我们就踏上了这条“不归路”。现在的我,会称这种思路为“过早优化症候群”。
按照多云设计思路,我开始审查“多云兼容性”并通过自主维护的SDK替代AWS提供的预制SDK。而这一切都是为了营造某种虚假的安全感,即如果AWS这家大受欢迎的云巨头哪天突然不行了,我们就能比较顺畅地完成大规模负载转移并值回投入的成本。我猜大家这么干是想证明自己有某种厉害的前瞻性,或者是野心太大把脑回路给带偏了。
而这也是我们做过的愚蠢的尝试,大大提高了向客户交付产品的难度。既然选择了AWS,请拜托各位别假装自己的应用程序还需要面向其他云环境部署。如果AWS过几天消失了,那确实得迁移应用程序;但有几个人敢说自己的公司能开得比AWS久?既然没这个信心,干嘛要在跟当前云无关的翻译层上浪费那么多时间、投入那么多金钱?
我们终得到的只是一堆始终跟不上节奏的库,开发人员也被搞得身心俱疲、没工夫研究AWS发布的一系列新功能。这些自定义库发挥不了AWS的云功能优势,我们自己也从来没试过更换云服务商或者搞什么双云部署。因为从经济层面讲,这么干没有任何意义。开发团队空耗许久,终什么都没有得到。
如果各位身边还有人鼓吹“必须保证不必依赖于单一云服务商”,拜托替我骂醒这家伙。与数据中心类似,在AWS当中设计、测试并成功运行多年的应用程序往往都带有与环境相匹配的某些预期和模式。针对其他不可知设计做出的优化,都必然在牺牲当前云服务商功能价值的同时、给开发团队带来本不必要的额外工作压力。
别当那种站关说话不腰疼的人,跟所有人对着干往往当不成力挽狂澜的英雄、反而让我们沦为众目睽睽下的小丑。另外,就算大家基本认定转向其他云服务商具有可靠的经济意义,也请至少留出3个月时间开展应用程序测试和移植,之后再考虑到底要不要具体实施。
云服务商当然会产生依赖性,就像编程语言一样。我们不可能随随便便就决定更换,甚至全面移植也不太现实。所以大家不妨把迁移议案当成一种演习偶尔试试,同时把大部分精力集中在产品与当前环境的充分融合上。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。