刚刚进入计算和应用领域的开发人员和工程师经常通过最新、最新颖、最耀眼的技术来看待世界。 但更常见的情况是,事实是——就像我们这些科技行业资深人士的童年好友一样——这些概念和类似的实现一直存在。 随着业务需求和经济状况相对于底层实施约束和基础设施的趋同和分化,它们只是随着时间的推移而前进或后退。 事实上,不断发展的商业环境推动着需求和要求,从而导致特定的技术策略被重新发现或被搁置一旁。
本着这种精神,在下一组文章中,我将讨论未来几年将会出现的一些与应用相关的技术,特别是当我们向更加完全分散的应用交付结构和边缘的新兴角色发展时。 但首先,有必要分析一下我们为何以及如何走到今天的境地。
让我们从大约 20 年前开始我们的旅程,当时商业服务的数字化交付(当时还没有“应用”这个术语)是由私人拥有和运营的数据中心进行的。 这种技术策略在那个时代是足够且合适的,主要是因为在那个时期,只有最关键的业务运营才被“数字化”。 那个时代的数字化业务运营的一些例子包括:
鉴于当时典型商业组织(垂直整合、地理位置相同的劳动力以及对组织和 IT 基础设施的集中控制)的背景下,只有少数业务工作流(即最重要的工作流)以数字化方式交付和考虑,因此,很自然地,这在组织上反映为集中拥有和 IT 管理的数据中心,运行大部分或全部在内部开发的整体式“应用”。 基础设施、安全和应用(原名为“业务服务”)是一个垂直集成的堆栈。 因此,从非常真实的意义上讲,技术堆栈(集中式和单一式)模仿了组织和业务结构。
应用及其技术堆栈的下一步演进是由“数字化”扩展到次要业务工作流所推动的。 下一步,数字化工作流程将进一步扩大,不仅包括面向客户的工作流程(应用商店中应用程序的激增就证明了这一点,该工作流程已经商品化),还将范围扩大到包括组织内部的运营工作流程,这通常被称为企业数字化转型趋势的一部分。
因此,企业被迫重新考虑其业务组织战略。 一个具体的含义是,考虑到业务规模快速变化的业务问题,更加重视成本效率和灵活性。 这使支付模式偏向于公用事业定价模式,即按实际使用量付费,而不是预付费和为可能预期的更高负荷做好准备。 使用财务术语来说,应用基础设施的融资模式逐渐从前期资本支出模式转变为现收现付的运营支出策略。 同一时间段内的另一个同时发生的趋势也与成本效率和灵活性有关,即劳动力的地理分布更加分散,这推动了对比过去更加普遍和可靠的全天候连接的需求。
这些要求的影响——大量业务工作流的数字化、对 OpEx 成本模型灵活性的需求以及对全球 24/7 连接的要求——自然导致了创建一个由非常庞大、高度可用的虚拟数据中心组成的全球网络的环境,这些虚拟数据中心的使用按效用进行定价。 于是,公有云诞生了。
此外,一旦公共云的种子出现,就会创建一个自我强化的正反馈循环。 随着公共云作为应用平台逐渐成熟,它开始取代大部分之前由传统企业 IT 管理的低级网络基础设施。 因此,许多企业中的网络运营团队的范围缩小了,企业转而将重点转向应用部署和交付(又名“DevOps”)和应用安全(又名“SecOps”)。 当然,这并不普遍;服务提供商和大型企业有必要且有能力对其最关键或最敏感的工作流程进行内部 NetOps。
这个故事代表了云时代的第一阶段,其中公共云可以被看作是一种外包的、时间和资源共享的数据中心——换句话说,公共云抽象是基础设施即服务 (IaaS) 之一。
云时代的下一阶段由两种不同的新兴商业洞察所驱动,两者都需要以第一阶段/IaaS 范式为先决条件。 这些业务实现中的第一个是通过将业务价值的交付与交付数字化工作流的实施相隔离的能力而实现的。 更具体地说,企业现在可以开始想象一种执行策略,其中技术基础设施的较低层(现在作为公共云提供的服务进行管理)可以与企业领导者的主要关注点(围绕企业的价值主张和竞争差异化)分离。
第二个业务观察是,随着越来越多的传统工作流程实现数字化和自动化,更高级别的业务流程可以在更短的时间内进行调整和优化。 另一篇文章更详细地讨论了这种影响,阐述了数字化工作流程如何从简单的任务自动化发展到数字化优化(又名“数字化扩展”),并最终实现人工智能辅助业务增强。 作为这一趋势的例子,价格调整、员工时间安排和库存管理等各种各样的工作流程都受益于快速适应性,并创造了“业务敏捷性”一词。
这两种见解使企业获得了商业上的顿悟,即企业意识到将非企业核心竞争力的领域外包往往更具成本效益。 这反过来又促成了企业与其云提供商合作伙伴之间的双赢商业安排,双方都积极进一步提升公共云所提供的服务,从而减轻企业的额外技术负担。 然后,公共云扩展了这一概念,以提供更高级别的平台功能,例如数据库、文件系统、API 网关和无服务器计算平台,再次作为公共云中的服务。 此外,公共云提供商还提供集成的 OTT 服务,最常见的是在性能管理和安全领域。
结果是,随着云时代逐渐成熟,超越了第一阶段的 IaaS 模型,它迎来了云第二阶段范式,即平台即服务 (PaaS) 和软件即服务 (SaaS)。 随着云第二阶段的推进,支持应用所需的大部分(如果不是全部)基础设施都可以从企业外包给云提供商,从而可以大规模优化基础设施,并组建更大的专家团队来专注于任何广泛需要的应用服务。 虽然这确实使企业能够将其技术预算集中在核心业务逻辑上,但它往往导致一个不良的副作用(从企业的角度来看),即“锁定”特定的云供应商。 为了减轻这种影响,企业努力使用与供应商无关的技术来定义和规范其核心业务价值的表达,特别是在 API 和计算模型的关键领域,并使用 REST 和 gRPC API 技术实现,并由虚拟化和容器化的计算模型——Kubernetes 支持。
“应用”发展的第三阶段,也是目前正在出现的阶段,是由我们几乎不认为是工作流程的日常活动的数字化推动的。 与第 1 阶段和第 2 阶段相比,这两个阶段主要是业务流程和一小部分交易消费者工作流程上线,而这一阶段则是要创造无处不在、无缝融入我们日常“人类生活”行为的数字体验。 目前,完整的用例仍在不断展开,但我们已经看到了利用增强现实、自动家庭监控系统和电网级电源管理等技术的新兴用例中丰富而多面的未来之路。 这些解决方案主要与现实世界进行交互,通常使用智能设备——自动驾驶汽车、数字助理、摄像头以及各种智能家电。
从企业角度来看,下一次转变将更加重视数字消费者的用户体验。 这种对用户体验的关注,加上对设备而不是人类将成为数字化流程的直接客户的观察,意味着数字消费者的用户体验要求将比数字化发展的前几个阶段更加多样化。 下一次转变,从第 2 阶段到第 3 阶段,将与前一次转变(从第 1 阶段到第 2 阶段)不同。 具体而言,下一步将不是对通常的数字体验指标(即“使其更快、更低延迟”)的简单推断,而是为“应用”提供更广泛的选择,以便进行应用交付权衡,从而允许根据正在处理的用例背景下的数字消费者需求定制体验。
从技术人员的角度来看,业务需求的含义是,消费体验要求的多样性增加将导致需要构建相应灵活、适应性强的手段来权衡、指定和优化常见的应用交付指标:延迟、带宽、可靠性和可用性。 例如,增强现实体验系统可能需要非常低的延迟和高带宽,但对丢失一小部分网络流量有更强的容忍度。 相反,用于报警系统的家用摄像机可能需要高带宽,但可以容忍(相对)更长的延迟,大约几秒。 智能电表可以容忍长延迟和低带宽,但可能需要高水平的最终可靠性(如果不是及时的话),以便记录所有的能源使用情况。
系统的设计和架构要足够灵活和适应性以满足下一阶段“数字化”的需求,就需要一种机制,使构成数字体验交付的众多组件能够轻松地分散并在需要时迁移到应用交付路径中的各个位置。 这些应用组件的分布需要根据用户体验要求驱动的交付需求(延迟、带宽、可靠性)进行定制,并且系统需要随着环境和负载的变化而不断适应。 最后,但并非最不重要的一点是,应用的安全问题(身份管理、恶意软件防护、漏洞检测)需要无缝跟随应用组件在应用交付路径中的转变。
那么更具体地说,相对于我们现在的状况,这意味着什么? 它的意思是这样的:
最后三个主题将成为本系列下一篇文章的重点,我们将在其中讨论“边缘”及其发展方向,以及此后真正与位置无关的安全视图是什么样的。