上云前须知的十件事

 

上云前你要知道的事~暂时停更一下架构系列...

上云,你需要知道的10件事


随着政策开放和IT趋势,目前已经上云以及正在观望的CIO/CTO们愈来愈多。然而打交道的过程中,我也发现了一些大佬们其实并没有想好上云方法和上云理由。今天暂时停更一下Azure架构系列,更新一篇上云思想,也算是“丑话说在前头”,望和大家交流以及给大家做些参考。

01

请先回顾你的架构和设计,保证它以及做好了上云的准备
可能说的有点笼统,但从实际出发,这个也是最重要最根本的问题。 你的解决方案有没有做好设计,有没有为云优化,有没有想过能不能放在公有云上?

很多时候,你的解决方案是需要重新build和重构的。举个例子,很多方案是构建在原本的单服务器上,并没有做好单点或者灾备方案,所有的扩展和架构都是建立在硬件scale up的基础上。如果这样,就很有可能在上云的途中发生问题。

再比如,如果你的网站是session控制的,在内部直连,没有考虑反向代理或者中间层分发,那在上云的时候你就有可能发现一些奇怪的问题和load balancer的情况,这些都是需要提前观察和准备的。

实际的情况自然复杂的多,但这些都是确实存在和已经解除过的问题。所以在此,非常推荐在上云之前,先review一下现存的架构和可能的问题,否则你会把现有的问题变得更有复杂。
02

云平台并不能满足你所有的性能需求
虽然云平台背后的计算能力非常强大,但请不要指望云平台能够解决你的性能需求。如同很多onprem的环境下,客户尝试升级CPU或者服务器内存,最后发觉网站或者应用并没有得到提高。可能很多问题出现在了你没有注意到的地方比如磁盘,比如response time,大部分在于应用。虽然很多人寄希望于auto scale之类的云特色,但相信我,优化你的代码和让它在云上跑的更顺会更重要。
03

不要选择云只因为他便宜
这可能是目前很多企业选择云的理由之一。也是云计算大肆宣扬和吹捧的好处之一。当然,相比一些固有的成熟的本地方案,云计算毫无疑问是便宜的。但这里的经济性是相对的,这取决于你的选择和你的方案情况。

举个例子,一个远超于自己真正workload的服务群集,一个永远不会自动伸缩的执行方案,一些永远跑不满的大数据分析,不会用或者没有用到刀口的方案并不一定会为你省掉多少钱。甚至一些云的“特性”还会让你产生类似云怎么那么不稳定的挫败感。

先确定和计算好使用情况,做好比较,货比三家总不会错。
04

不要做墙头草
这里并不是推荐说大家要绑在一个云平台上。多云和混合环境肯定是以后比较多见的架构。这里的墙头草,更多的是指在不一样的环境里摇摆,浅尝辄止后又大费工夫做迁移。

类似的事例也有,有的客户本来在本地的环境里跑的好好的,由于某些指标原因硬着头皮上了云,又没有做好上云的准备和前期规划,结果当然是悲惨的,花了大半年做的迁移,在放弃后,又做了大半年的fail back。劳民伤财,还在老板这吃力不讨好。

选定方案,做好规划,就应该果断拥抱变化,摇摆于稳定/基础/弄潮,只会得不偿失。
05

延迟和短暂性的问题是存在的
有别于你的本地环境,一切都是你自己做主。你可以买最好的cisco路由,F5负载均衡,买最好的server 和storage。云上的基础设施大家都一样,都是走的TCP,访问的HTTP。绕了大半个地球或者大半个中国,延迟必然存在。

你要做的,是选好于你最近的数据中心,当然,在你工厂旁边最好。计算好延迟对于你是否可以接受,你的应用是不是可以忍受。当然,一些短暂性的问题也是不可避免。举个例子,之前发生的一些大云计算平台(AWS,AZURE,GCE)都或多或少有因为硬件问题导致的VM重启或者软件问题导致的不可访问,这些都是必然会发生的。我们要做的是根据最佳实践和平台指导去完成可用性和业务需求可靠性。
06

做好POC,dry run
云是动态的,不同于你的数据中心,他的硬件和设计是你不可控的。在你的本地环境里,你几乎可以预测到你的应用的表现状态,然后在云上,你需要大量的测试和实际应用方能做到对应用的评价分析。

好在大多数云平台都有试用或者POC的环境,在真正理解你的应用在云上的表现后

再决定是否上云是再合理不过的事了。
07

真正了解供应商的SLA
在和云供应商的关系中,很重要的一点就是了解他们提供的SLA的含义。如上文提到,没有人能保证100%的可用性。目前大部分供应商的offer通常都在3~4个9左右。举个例子,azure提供99.95%的SLA保证,如果有高于这个时间的outage发生,微软就会赔付相关使用期间的费用。但前提是你使用了微软提供的可用性集,如果没有可用性集的支撑或者合理使用这个,供应商可不会提供赔付哦。

所以理解SLA和理解供应商提供的HA方案,于你的应用和你的商业保护而言,都是重中之重。
08

利用供应商提供的advance feature
如果你只用云的一些基础功能,并对一些供应商提供的feature嗤之以鼻,那就犹如丢了西瓜捡了芝麻。

犹记得Amazon有一个叫spot instance的feature,根据竞价和你的使用时间给你一定的折扣。这么优秀的feature和惠民措施,如果不用就有点暴殄天物了。

再举个现在比较火的微服务和docker管理系统为例,有些用户对于平台提供的MESOS、DCOS、Microservice都抱有疑虑,怕被平台绑定或者后期维护困难。其实目前的情况下,在不增加预算的前提,使用供应商的模板和集成方案未必是件坏事,在迁移方案广泛提出的现在,PAAS绑定已然不是个问题了。
09

安全和法务
国有国法,家有家规。运供应商也各有各的法规和方案。

一个很好的例子,某人利用境外云服务器提供VPN/IPSEC 服务,大肆宣传并以之牟利。这样的行为在天朝,自然是不能被宽恕的。目前在中国的几家服务商,也一直在被工信部询查和被改进。供应商的活咱们自不必操心,但自己的事,可的管好,尊重法务。

安全也是目前云计算流行下非常重要的一环。每时每刻都要成百上千的黑客跑着脚步扫着你的3389,22端口, 下木马抓肉鸡坐享免费的服务资源,觊觎公司资料和钱款。供应商自然有相应的防范策略,但更多的是需要上云者自己的注意和改进。
10

厂商支持
很多时候,商品的附加值包含了很多。如前期的研发投入,中期的宣传和运营,后期的售后支持和文档参考。 一个靠谱的厂商运营商,理应对整体方案和平台稳定性提供完善的支持和改进。消费者和业务决策者很多时候需要的是一个能负责的厂商,能对IT/业务流程有帮助的厂商。选择一家口碑好,或者有强大实力去为你负责的供应商也是很重要的一点。

最后的最后,上云不是一个 yes or not的问题。不是上了云或者上了云失败就是什么大事,云只是提供IT流程简化或者devops中的一环。最重要的始终是你的业务。脱离业务需求的决策通常都是失败的,如果发觉供应商性能不能满足或者提供的服务不给力,果断更新和回到原来的架构,也不失为明智。
Stan Peng


    关注 IT小圈子


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册