作者介绍:徐桂林,当前在FIT2CLOUD负责公司的技术布道和生态合作。在此之前先后供职于意法半导体、Autodesk和阿里云。徐桂林热衷于云计算(尤其是公有云IaaS平台),有过多年AWS的生产环境工作经历,是较早在国内分享AWS上实践经验的作者之一。
包月惯性思维制约了国内公有云的发展
现在,业务上云已经成为一个潮流。尤其是对于公司内部的技术人员而言,经常会有很强的技术冲动去让业务上云。同时,云供应商们的大力宣传让公司决策层及业务人员对于上云也有非常高的期待。但是,不管怎么说,公司业务系统上云还是一个技术活。作为公司内技术人员,仍然要从技术的角度充分考虑上云的路径、节奏以及具体技术方案。所以,很多时候技术人员的上云姿势比上云自身还重要。选择一个正确的上云姿势会让你的上云过程更加顺利,并能够为未来充分释放云生产力奠定基础,最终达成公司上云的初心:促进业务创新。
当企业决定上云后,掌握正确的上云节奏是让整个上云过程顺利的最关键因素。一般来说,如下路径是企业最常见的上云节奏:
在这个节奏中,技术人员要特别注意下面两点:
上云过程的第一步(在云上进行开发测试)是一个非常重要的步骤,这是技术人员更深入理解云的关键阶段。但现实过程中很多技术人员都忽略了这一步的重要性。他们习惯于选择一些测试工具在云上进行测试,然后以这个测试结果作为认识云的主要信息来源。如果测试结果合适的话就直接在云上部署服务。这种方式经常会让技术人员在未充分了解云的情况下上线服务,会给后来云上运维及运营带来很多不确定因素。一个更为推荐的方式是技术人员以云为开发测试环境,并在其上不断迭代版本,尽早暴露系统在云上运行的问题。同时,这个过程也是技术人员深入理解云平台,不断调整使用云资源方式的过程。另外,由于云资源的按需付费特征,从成本上看其也特别适合作为开发测试环境。
在整个上云过程中,不同阶段对于云平台的要求是不尽相同。如果就IaaS层面来说,我们认为上图不同阶段对于云平台的要求大体如下
所以,随着上云过程的不断深入,技术人员需要持续考察云平台的支撑能力是否能够匹配当前的上云阶段的需求。
目前,市场上云供应商比较多,即使是面向技术人员的IaaS和PaaS也有不少。所以,如何为你的上云业务选择合适的云平台就是技术人员必须要面对的重要问题。不同业务、同一个业务不同阶段对于云平台的需求都不尽相同。就IaaS层面来说,技术人员在选择云平台时需要注意如下几个问题:
避免被企业宣传所影响,抛弃“云是万能钥匙”的认识。在选择任何云平台前都要充分做好验证工作(POC);
明确核心验证指标,避免要一个面面俱全的方案。即使是今天,云平台仍然在快速发展阶段,可能还没有为你提供全面完整的解决方案。但是,如果因此而望而却步则有可能因噎废食。所以在做云平台验证之前需要明确业务要求的核心指标,之后再以此为参照做云平台的验证工作。对于目前还不能完全满足的其他指标可以考虑通过技术架构、辅助工具、管理方式等途径解决;
转变思路,抛弃不再合适的做法。用户对于云时代IT基础设施的很多需求没有改变,但是也有不少思路发生了巨大变化。例如,自服务IT就是一个非常好的例子。传统IT中企业倾向通过集中化申请、审批每一份资源来控制成本,而在云时代使用这一套方式管理云资源将极大限制云平台的生产力。一个更好的方式可能是通过成本预算和费用管理的方式来控制,但不去限制技术人员如何具体使用每一项资源。只有这样才能够充分释放技术人员的生产力,达到效率和成本的新均衡。
当技术人员上云后,其最常见的云资源管理方式就是云平台的Web控制台。用户可以通过控制台申请、释放资源,完成资源的配置等等。控制台对于用户管理云资源很直观,但是控制台UI交互的方式却限制了云资源“可编程”特性的发挥,限制通过自动化完成开发、测试以及运维管理工作的能力。所以,技术人员上云过程中一定要注意尽可能多使用云平台提供的API工具(包括命令行工具和各种语言SDK)管理资源。通过这些工具,技术人员可以完成很多控制台并不擅长的工作,例如:
常见的批量操作,例如按一定标准批量申请、释放资源,对于一批资源进行批量配置等。
流程自动化操作,例如自动化完成资源获取、初始化、业务部署以及加入系统这一整个流程。
资源调度操作,例如按照一定标准完成资源自动扩缩容,以提高系统应对不同业务负载的能力。
在传统IT中,很多公司的开发测试环境与生产环境相关独立,甚至网络也相互隔离。这是一个非常必要的最佳实践,但在云上如何落实这一实践?其实,云为此提供了一种最简单直接的方案,就是通过不同的云帐号来完成不同环境的隔离。不同云帐号之间资源、网络天然隔离,并且可以把他们交给不同的人员进行管理。当然,这种隔离也会带来数据交换的不方便,一般来说有下面几个途径解决不同帐号下的数据交换问题:
通过云平台提供的跨帐号资源共享能力。例如,跨帐号的镜像共享机制,数据跨帐号访问的授权问题。
通过集中化的服务交换数据。例如,通过集中化的制品(artifacts)库在开发测试和生产环境中共享部署组件包。
业务负载上的弹性是系统弹性最重要的指标。云平台为业务负载弹性提供了非常好的基础设施支持。无论是传统的应用,还是新型云应用都可以从此获取极大帮助。例如,传统游戏应用都是按分区模式运营,并且很少涉及到线上跨区数据访问。云的这种弹性交付模式也可以让其在开合服上带来很大灵活性。而新型云应用一般都按水平伸缩和状态无关来设计技术架构,则更能发挥云平台的弹性。因此,技术人员决定上云时需要仔细思考业务负载的弹性特征如何,能否在技术架构或者基础设施层让整个系统更有弹性,从而让你的系统因为上云可以获得更好的弹性。
除了业务负载上的弹性,业务系统的容错性和高可用同样也是系统弹性设计中的重要考量。云上资源的获取非常容易,所以在容错处理乃至备份容灾方面都可以充分利用这个特点。在系统出现问题时快速搭建全新环境并及时切换很多时候比在原来系统中恢复服务更有效。同样,云平台带来的另外一个好处就是全国(乃至全球)的基础设施资源标准化,可以让你的系统非常容易在不同区域进行部署,并且当一个区域出问题时候还可以及时切换到其他区域。这也是一个增强服务弹性和系统高可用性的重要途径之一。
自动化是大家经常提到的东西,并且在传统IT中也在不断的强调。那么技术人员上云和自动化有什么特别的关系?简单来说,云为传统IT中最难自动化的部分(基础设施)提供了自动化的可能,这也就意味着整个IT系统有可能从零开始全自动化搭建完成。传统IT技术人员的自动化链条很多时候都是以基础设施准备到位,甚至初始化完成为起点。而在云上技术人员一定要努力将自己的自动化链条向前延伸。具体来说,包括如下几点:
为此,很多云平台还为用户自动化基础设施提供了专门服务,如虚机及容器的镜像、基础设施模板、虚机的metadata&userdata,代码部署服务等等。这些服务都值得技术人员去了解和试用。
安全是很多客户对于云平台最大的担心。也正因如此,云供应商对安全做了大量的投入,提供了很多安全工具。对于技术人员来说,首先需要牢记在心的云上安全基本原则就是“责任共担原则”,也就是说云上安全是由云平台和客户共同担当。所以,云平台客户和技术人员一定不要指望上云后所有的安全问题都自动解决了,仍然要持续地加强自身的安全意识和安全技术能力。不过好消息是,和传统IT比,云供应商提供了更为丰富、更加易用的安全工具集,可以帮助用户更容易地构建一个安全服务。展开来说,包括如下几个方面:
当然,由于国内网络环境的恶劣性,网络攻击时而发生,如何保证网络访问安全是一个头疼的问题。在这方面,云平台无论从资源还是技术投入来说都会强于个体客户,所以这方面选择信赖云平台也是合理的。同时,云平台还会聚集大量的第三方安全公司,客户从此选择自己需要的合适云安全供应商也很方便。除此之外,主流云平台都会主动通过各种行业安全及合规认证,这对于有行业合规要求的客户非常有帮助。整体来说,作为技术人员,在上云过程中首先要树立“责任共担”的安全意识,然后重点关注云平台的安全工具、以及云平台推荐的各种安全最佳实践等,并按照业务需求使用好它们。如此,你会发现云平台其实比你想象的要安全得多。
【原文来源:云头条】