为什么一家传统券商选择将交易系统容器化?
在一切都嫌慢的“互联网时间”里,运维貌似成为最后掉链的一环,以“稳健”为主导的运维团队与“进取”的研发、运营团队无可避免产生冲突 它是在APM(应用性能监控)、Infrastructure As Code(可编程运维)、Virtualization(虚拟化)、Containerization(容器化)等等这些云计算时代的产物出现后,基于新的技术工具、技术理念而自然产生的. 持续集成(Continuous Integration)、持续交付(Continuous Delivery)、持续运维(Continuous Operation)是DevOps的具体环节和手段,它相当于把一条纯数字化链路上不同的参与者关联到一起 – 无论是开发工程师还是运维工程师,最终都不过是身份稍微差异的Information worker. DevOps可能不仅仅是个概念、方法论、技术新名词,它是伴随云计算自然发生的.但它的接受与运用,对于传统企业的IT,尤其是“维稳”为主导思想的受监管行业的IT,可能是一种文化冲击. 传统IT甚至是今天的很多技术相对前沿的互联网公司,依然把团队拆分成“运维”、“开发”,在组织结构层面建立相互制衡,以避免开发团队的“冲动冒进”导致生产系统的不稳定,但运维职能往往变成一种“权力”(privilege)- 系统的迭代更新都需要获得运维“审批”,这本身显然就是一个“脆弱系统”,因为对变更是绝不友好的.在技术进步、时代变迁的大环境下,这种过去合理的做法,早晚变成一个将要被颠覆的存在. 无论如何,我们认为割裂的讨论一个高性能运算(HPC)的技术系统(如证券交易系统)的容器化、“云化”是不够的,DevOps是构建“反脆弱”技术系统的方法论(起码到目前为止.也许将来有新的思维出现),也是我们系统能力的天然一部分. 我们从软件研发的视角、证券交易的视角来看待云计算,深感把促进基础设施数字化、运维代码化的容器化技术,运用到交易系统技术中,是天作之合 – 假如运用得当的话,结合机器学习和智能算法,能帮助我们构建一些“反脆弱”的技术方案(既然有能下围棋的阿尔法狗,我们是否也可以开始憧憬懂得自救的运维狗?). 可以看到的潮流脉络是,世界是越来越数字化的、变化是越来越频繁的、而IT是需要拥抱变化的,云计算则只是这个潮流里完全符合趋势而自然出现的技术阶段. 有一天Oracle、SAP、各种著名与非知名的专业软件都把它们自身的产品基于容器来构建(例如一个多进程组成的数据库实例里的进程各自运行在自己的容器中),也许对于行业监管者、企业技术决策者而言,云已经无需概念上的存在,而能被毫无质疑的接受. 但是这一天到来之前,大部分企业也许可以先尝试调整一个对云服务友好的财务制度 – 项目立项的时候,硬件预算按CPU核数、内存量、存储量来报算,有形的物理机器不再作为资产稽核到各条业务线各个项目组,一切物理硬件归IT.制度和文化,往往才是隐形的决定因素,不是吗? 文章出处:InfoQ (编辑:应用网_丽江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |