楼炜
作者楼炜2017-08-01 17:42
副总经理/副总裁, 云星数据

企业级私有云构建的架构师阵型及架构策略分析

字数 3120阅读 4832评论 1赞 19

我相信每一位从事云相关的朋友都有自己对云的不同理解,有交集、有分歧,但我想,你的云、我的云,不要人云亦云就好。以下试从“我的云”角度,给大家分享一下我眼中的企业级私有云,以及其建设过程中需要的能力和策略。
之前分享一篇文章“’云不一定节省成本’——云产业发展观察与企业级IaaS建设实践”一文,其中简单描述了我对云产业的整体发展观察、和对IaaS、PaaS以及SaaS分别的细分、看法。
因为企业级私有云情况复杂,个性差异大,我先引用前文中的要点,然后展开分析:
根据IDC年初的分析报告,美国和中国云计算产业发展差异巨大:美国以公有云为主,SaaS最大、IaaS最小;而中国截然相反,以私有云为主,IaaS占了大约50%的份额。究其原因,跟中美两国云计算产业发展的阶段、成熟度有很大关系。
由于政府对云计算、互联网+、大数据的“十二五”、“十三五”政策持续推动,对于政务云建设的现实需求、统一纳管基础设施资源、节省成本等考虑,对云计算相关的投入较大。

在诸多产业中,中国私有云市场最主要的客户来自:通讯、金融、政府。金融行业受安全、政策、法规的约束,几乎不会选择纯公有云,大型国有银行私有云的建设步骤也很谨慎、渐进式,会首先考虑迁移非核心应用;小金融相对会对新技术比较开放,会实验一些开源的技术,如Openstack、ceph等。

今天要谈的企业级私有云着眼于两方面:企业级、私有云。(这是废话)

所谓的企业级大家都知道,就是成规模的、有一定量级的企业,而非SMB(中小型企业)。而私有云的概念大家很清楚,需要指出的是,国内私有云建设目前仍以IaaS为主,一部分企业已经先行一步(或者规划比较前卫的企业)的大企业已经开始PaaS建设,很少涉及SaaS(集团公司内使用的、实现了多租户的软件服务除外)。因此,本文以IaaS为主,兼顾PaaS,几乎不会涉及SaaS。
我不清楚大家看到标题的中的“架构师阵型”什么反应?我自己的感觉是:什么叫架构师阵型?为什么要阵型,我一个架构师加几个主力开发再加几个新手不就搞定了吗?或者,怎么组织阵型?诸如此类的问题。
个人认为很多因素都会影响企业云(IaaS为主,含PaaS、SaaS)架构的选择,主要有以下一些:个人认为很多因素都会影响企业云(IaaS为主,含PaaS、SaaS)架构的选择,主要有以下一些:
a) 企业IT发展规划
b) 企业组织架构
c) 企业管理制度
d) 业务类型
e) 应用层次
f) 利旧
g) 人员技能
h) 技术成熟度
i) 成本
j) 周期
k) 运维体制
l) 。。。
具体不展开讲,回到主题。如此纷繁复杂的众多因素,忽略其中某一个都有可能导致项目的失败。因此,我们需要一个架构师阵型(zhenxing),去换取一个企业级私有云项目的真行(zhenxing)!

抛开其它因素,只看业务和技术范畴,一个典型的云数据中心建设项目范围如下(这还远不能涵盖所有企业级私有云的范围):
1.jpg

1.jpg

试想一下,一个架构师能力再强,能cover上面所有方面的技术架构把控吗?因此,我们也需要一个架构师阵型,去完成一个项目的交付。

那么,接下来一个问题就是:我们怎样去构建架构师阵型?
接下来的图我借助了TOGAF的理念,并对之按照我自己的理解做了改写。
2.jpg

2.jpg

我试着定义这些架构师的分类、职责如下:
企业架构师:负责企业架构总体规划,使IT理解业务,促进信息化和业务衔接,牵头制定蓝图,指导各领域架构师,通过多个项目实施完成总体规划要求;
业务架构师:负责梳理业务流程、组织、角色;
应用架构师:负责梳理系统、服务、功能;
数据架构师:负责数据、业务对象、交互格式、安全与隐私;
技术架构师(技术专家):负责某一块专业的技术,如硬件、服务器、操作系统、网络;从工作职能分,也可以分为售前和交付等;
云架构师:分为云平台架构师和云服务架构师,前者负责云平台的整体规划、设计、实施等,后者负责云服务的梳理、定义等,二者可以兼顾。

那么问题又来了,有的朋友会说,我所在的公司没有这么多(类型)架构师,是不是做不了这样的项目了?还有的朋友会说,我们以前做项目根本不需要这么复杂,1-2名架构师就搞定了。

首先,各个项目情况差异巨大,有的需求简单只是某大项目的一个子项目,有的相对复杂;有的大型企业已经梳理出完整的需求,或者咨询公司已经帮助完成整体设计。。。。。。等等等等,不一而足。

因此,我们需要根据前述的各种因素(前面因素a-k,甚至更多),根据完整的业务需求出发,做裁剪,组织合适的项目架构师阵型。还是那句话,适合项目的才是最好的,他(客户)好你(承建商)也好。

以下是我基于TOGAF修改的架构师技能定义:
先放图例:
3.jpg

3.jpg

接下来从企业架构师开始:

4.jpg

4.jpg

5.jpg
5.jpg

6.jpg
6.jpg

7.jpg
7.jpg

8.jpg
8.jpg

9.jpg
9.jpg

图放完了,说点感想:我个人始终认为,人的能力是一个多方面的综合体现,我们可以按照上述技能去参考,但切忌去套用、去按图索骥;还是要通过多方面的交流、沟通、实践来确定是否适合团队。

那么人有了,应该怎么组织设计架构呢?
我接下来谈谈架构策略,因为部分内容涉及到保密,只能模糊一下,我尽可能把要点分享给大家。

可以借用EA的思路,我们把企业架构设计类比成城市的战略、规划和建设实施,企业架构也可以看成对企业级战略、职能流程、组织、IT系统交互、流程描述、网络部署方式进行梳理;指导各个子系统的建设。
如下图:
10.jpg

10.jpg

从实际案例出发,大家能看得更明白:

1.某项目规划一个整体机房建设加6个PaaS平台,分别涵盖数字电视台、家庭医疗、电视电商、电子政务、视频点播、电视游戏等应用。
那么我们会规划这样的一个整体架构:
11.jpg

11.jpg

图中蓝色部分是几乎可以忽略的,浅绿色部分是需要关注的部分。因此,相应的架构团队就可以组件了:
12.jpg

12.jpg

再看另一个项目:
2.某项目以云数据中心系统建设为核心,依托其上承载物流、人力资源管理等20多个子系统。项目和子系统之间已经有良好的界限划分。
那么整体架构会是这样:
13.jpg

13.jpg

该项目除了企业架构,我们都要规划、设计。因此,架构师阵型是这样的:
14.jpg

14.jpg

我想,现在大家应该已经差不多明白了怎么规划整体架构、构建架构师(专家)团队的基本策略了。

事实上,我们在做复杂类型的云数据中心项目规划、实施和交付时,通常会遵循下面的规划设计框架:
15.jpg

15.jpg

因为众所周知的原因,我对上图的一些部分做了屏蔽。
大流程基本上会按照顶层设计(整体规划)、概要设计、集成管理三个步骤来考虑复杂云项目的规划和架构设计。

例如,在顶层设计时,通常会考虑整体规划、ROI分析、发展路线规划以及关键要素分析等内容。

整体规划:以行业发展趋势为引导、产业现状和趋势为基础、安全隔离/租户隔离和资源规模效应为平衡点、应用兼容性要求为判据,把企业在云领域的诉求经过量化分析后给出具备明确技术可行性和性价比合适的顶层架构。

而在概要设计阶段,基础设施概要设计是承接顶层设计之后,把用户诉求细分成各类专业需求,以及在需求和技术实现之间建立的桥梁。一个优秀的概要设计,是让用户菜单式选择的过程,同时也是具体指导详细设计和实施的框架。

16.jpg

16.jpg

“非功能性需求”在基础设施设计当中一样重要,包含容量规划、性能、可扩容性、可维护性和高可用性等内容。现代设计框架中考虑到容灾和安全已经非常复杂,所以单独作为主题。

归根到底还是那句话,根据各种因素考量、根据项目实际裁剪,制定自己的云架构策略、构建自己的架构师团队,你的云,我的云,终究殊途同归。

以上内容个人观点,如果有遗漏疏忽,还请专家们指点。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

19

添加新评论1 条评论

macroseamacrosea项目总监, 人民医院
2017-08-01 19:03
逻辑思维很缜密

楼炜@macrosea 谢谢夸奖,请多多交流、指正

2017-08-02 09:16
Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广