写点什么

在架构方面,没有谁比亚马逊的 CTO 更能预见未来

  • 2024-12-06
    北京
  • 本文字数:4422 字

    阅读完需:约 15 分钟

大小:2.19M时长:12:44
在架构方面,没有谁比亚马逊的 CTO 更能预见未来

1984 年,Larry Tesler 提出了“复杂度守恒定律”:每个过程都具有其固有的复杂性,存在一个临界点,超过这个点后,过程就不能再被简化了,只能将固有的复杂性从一个部分转移到另一个部分。


这就要求软件工程师需要具备应对复杂性的能力——能够区分出哪些复杂性对于系统来说是必不可少的,而哪些则是冗余无用的。这也是实现软件系统简洁性的关键。


在 re:Invent 2024 的最后一场重磅主题演讲中,亚马逊副总裁兼 CTO Werner Vogels 博士分享了构建复杂系统的经验并提到,复杂性无处不在,随着系统规模的扩大,复杂度也在不断提高。普遍意义上讲,复杂性并不是坏事,它通常意味着系统中正在引入更多的功能。


真正的关键在于预见和管理这种复杂性。


而这种在架构方面的预见性和执行力,只是 Werner 最擅长的部分,不是全部。Werner 经常在年底做出技术趋势预测,此举已经持续了数年,准确率惊人。不熟悉他的人,可能将其视作某种超能力。


而熟悉 Werner 的人不会对这种分享和预测过分诧异——至少对复杂系统构建的关注,几乎贯穿了 Werner 在亚马逊的全部岁月。

为何是 Werner Vogels,为何是亚马逊?


在加入亚马逊以前,Werner 曾担任康奈尔大学分布式系统研究员职务。当亚马逊第一次向 Werner 伸出橄榄枝时,他已经是分布式系统领域的知名专家。而此时的亚马逊只有一个美国网站,专注于书籍销售。


面对亚马逊的邀约,Werner 第一反应是:图书网站为什么关心分布式系统?


当看到亚马逊员工的工作内容后,Werner 意识到,这并不是一家简单的书籍销售公司。


当时,亚马逊正想努力扩大基础设施规模,其中的关键就是建立分布式系统。与耗资数百万美元的大型主机路线相反,分布式系统就是现代云计算的前身,其专注于如何将计算工作负载分配到大量规模较小且成本更低的计算设备之上。


2004 年,Werner 辞去康奈尔大学分布式系统研究员职务并加入亚马逊,2005 年 1 月晋升为 CTO。作为公司的技术领航者,CTO 影响力贯穿于企业的技术战略、创新驱动、团队领导以及跨领域合作等关键领域,对推动公司的技术进步和业务成功至关重要。


Werner 曾在个人博客中专门对 CTO 角色的职能进行过解读:


基础设施管理者——在 CIO 角色高度分化的企业中,CTO 主要负责的是基础设施与 IT 运营方面的责任,包括数据中心运营、网络运营、应用程序开发与维护、安全及其他相关职能。CIO 则负责组织内的具体技术应用方式。这也是多数传统企业采取的模式,即 IT 部门仅扮演支持性角色。


技术前瞻者与运营管理者——这种模式往往出现在互联网公司及其他技术导向型企业当中,他们的共性就是普遍将信息技术作为实施业务战略的核心要素。CTO 负责确定如何使用技术来落实业务战略。这也是定义中“技术前瞻者”的指向所在。除此之外,CTO 还负责实际集成和运行技术,即“运营管理者”的部分。在这种模式下,CTO 通常是企业的联合创始人,或者至少是公司的元老之一。


面向外部的技术专家——这种模式大多出现在使用技术向客户和合作伙伴提供产品和服务的企业当中。CTO 作为客户和内部开发团队之间的中介,同时也是产品组合开发流程中的主要推动者。CTO 与关键客户保持紧密联系,且主要参与市场研究。不少大型软件公司都成功采用了这种模式,其中的 CTO 都是经验丰富的技术专家,主要任务是在公司与客户之间搭建桥梁。另外,中间件领域的不少软件开发公司也将 CTO 定位为重要的客户联络人。


大思想家——这种模式下的 CTO 主要花时间评估如何在内部使用技术来开发新的商业模式和业务产品线,同时考虑如何阻止竞争对手利用技术扰乱市场。这类 CTO 的职责大多包括技术研发、竞争分析、技术评估、原型实验室运营、拓展合作、制定规划、设计架构标准等。


更重要的是,Werner 本人,几乎就是过去二十年互联网技术极客的典型范本——他热衷于解决复杂问题,总是在寻找业务的最优解,以及更优雅的技术方案。成为 CTO 仅仅一个月后,在 2006 年,亚马逊云科技就成立了。Werner 提到,自从亚马逊云科技成立以来,其使命就一直是为客户承担起复杂性难题:亚马逊云科技希望为客户分担更多压力,并继续尽一切努力尽可能简化客户体验。


而  Werner 也真正贯彻了这一想法,在将平台从普通在线商店转变为面向服务的架构方面,发挥了举足轻重的作用,并成为业内公认的最优秀的 CTO 之一,美国知名 IT 杂志《信息周刊》曾将其评为 2008 年年度 CTO。


亚马逊云科技也凭借这种“帮助客户化繁为简”的技术理念,最终拿下云计算市场第一名的份额。

Werner 亲身经历了亚马逊发展壮大的 20 年,并将在此过程中积累的技术经验,带到了 re:Invent 2024 的舞台上进行分享。

繁简之道:浓缩二十年的底层架构经验


这次分享的核心源于一个概念:The Way of Simplexity,“繁简之道”。


这个概念最早出现于 2012 年,亚马逊云科技根据自身的实践经验,总结出了 21 世纪软件架构所追求的四大目标:可控、弹性、数据驱动和适应性。而在达成这些目标的过程中,软件工程师必须懂得如何应对软件日益增长的复杂性,同时尽可能追求简单性。


当时移动互联网蓬勃发展,作为基础设施服务商的亚马逊云科技第一时间注意到了行业的风向。移动互联网应用的典型特征,在于通过移动智能设备,对传统产业进行重构,导致移动终端的出货量连年陡峭增长,最终引起互联网流量的激增。且这种流量存在波峰、波谷,对基础设施的承载能力和资源利用率都提出了极大的挑战。


这是为什么 Werner 思考当时的软件架构目标时,始终围绕着计算资源供给的灵活度进行展开。


而随着近两年生成式 AI 快速发展。AI 开始打破 IT 技术的能力边界——现在 IT 技术不仅构建一个软件应用,服务于社交、娱乐、工作流,还能深度介入研发流程,帮助人们探究真相,预防灾难。


近日,Werner 在个人博客中分享了其对于 2025 年及之后的技术走势预测,其中就包括:


  1. 技术在探究事实中发挥着决定性作用。 随着虚假信息以前所未有的速度传播,新一波 AI 工具将帮助记者、研究人员和普通民众寻求真相。这场技术革命将推动调查能力的大众化普及,加速事实核查速度,大大降低揭穿虚假信息的门槛。

  2. 开放数据推动去中心化灾难预防。 灾难恢复能力正通过超本地化、来自社区的数据力量实现根本性的转变。这种转变将重新定义灾难管理,从自上而下的被动模式转化为主动、去中心化的社区驱动新模式。

……


这既是对整个人类社会的重大利好,同时也将未来的软件系统的复杂性,推向了史无前例的高度:单凭技术,已经不足以解决所有问题,组织的能力必须被考虑在内;当前时间的架构设计,也不再能适应未来,架构本身必须能够向前演化。


因此他将构建复杂系统的经验,总结为如下六条:


第一,将可演化性作为一项要求。


可演化性是应对复杂性的一种预判。区别于可维护性,可演化性是指应对长期复杂性的长效策略,而前者则只强调对系统短期内正常运行的保障。随着系统不断发展,需要重新审视当初做出的架构选择。Werner 以 Amazon Simple Storage S3 为例,在最初团队刚开始构建它的时候,大家都清楚一年之后同样的架构就将不再适用。为了能够轻松应对未来的变化,构建出能够以可控方式进化的架构至关重要。


第二,将复杂性拆解成多个部分。


随着系统逐步扩张,复杂性也上升到了新的水平,需要将庞大的服务分解为内聚性高且有明确定义 API 的构建模块。以 Amazon CloudWatch(一项负责监控亚马逊云科技应用程序、响应性能变化、优化资源使用并提供运营健康状况洞察的服务)为例,通过将其拆解成一系列低耦合、小体量的组件,各组件将具有高内聚性和经过良好定义的 API,由此轻松实现相互通信。


第三,让组织与架构相匹配。


随着构建的系统复杂度越来越高,组织结构与当前开发的软件架构变得一样复杂。建立成功团队的一大前提就是消除自满情绪。即使事情进展顺利,也仍须留意可能出错的地方,并不断提出新问题。在向团队提出问题的同时,也要给予他们解决问题的权限和空间。领导者的工作就是为团队赋权,并帮助他们保持住紧迫感,从而按时交付工作成果。


第四,组织成单元形式。


业务的成功也将促进客户体量不断增长,任何运营中的中断都可能带来严重后果。通过将服务拆解成基于单元的架构,能隔离问题并保证其不影响其他单元。在理想情况下,各个单元应该足够大,有能力承载所能想象的最大工作负载;但其又应该足够小,小到可以进行全面测试。这是一个寻求平衡的过程。但随着时间推移,这种追求将帮助大家保障客户服务的可靠性与安全性,并尽可能减少对客户业务的影响范围。


第五,设计可预测的系统。


通过构建高度可预测的系统,减少不确定性带来的影响。事件驱动架构在这方面就有着出色表现。Werner 以 Amazon Route 53 为例,它提供高度可用且可扩展的域名系统(DNS)、域名注册和健康检查云服务。无需不断重新配置 DNS 数据库,即可在收到请求后执行健康检查,使得整体处理拥有极高的可预测性。


第六,使复杂性自动化。


开发人员和工程师们常常面临完成高难度关键任务的挑战,这些任务过程可能枯燥乏味。正确的思路不是“我们该让什么自动化”,而是“哪些东西不需要自动化”。换言之,所有不需要高判断力事情,都应该转为自动化。


“繁简之道”浓缩了 Werner 在亚马逊 20 年构建底层架构的经验。在不断变化的技术环境中,这些有价值的经验和洞察不仅展现了他对架构设计的深刻理解,还涵盖了他在管理复杂系统和优化资源利用方面的独到见解。


作为拥有二十年平台构建经验的老兵,Werner 曾多次强调在架构设计中寻求效率和简洁性的重要性。在 re:Invent 2023 上,Werner 提出的“俭约架构师”与“繁简之道”相辅相成,前者侧重于成本控制和资源的高效利用,后者聚焦于在复杂性中寻找简单性,通过简化系统架构来提高可维护性和可扩展性。(延伸阅读:《亚马逊 CTO 20 年架构经验之道:俭约架构师的七大黄金法则!》


这些听起来很难,但好消息是,今天的开发者不再是孤军奋战。


此前在接受 InfoQ 采访时,Werner 专门提到生成式 AI 如何重塑开发流程和开发工具。


他认为,开发工作和成为开发者的过程是相辅相成的。任何人,即使专业不同,只要有良好的基础教育,都有机会掌握计算机技术。教育背景不是限制,关键在于学习能力、设定目标、信息整合、记忆、批判性思维等能力。技术的变化是持续的,对于那些管理大型技术项目的 CIO 和工程师来说,紧跟技术发展的脚步、保持终身学习至关重要。


随着技术的发展,现在有更多的高级工程师能够指导编程新人。然而,初级工程师往往会重复提出相同的问题,这可能会让经验丰富的前辈感到疲惫。但 AI 系统不会烦躁,愿意无数次回答相同的问题。它就像耐心极好的导师、助手和创造者,全心全意为培养优秀程序员而努力。在必要时,它甚至可以直接输出建议的代码。


但从本质上看,它们仍然只是预测机器,真正的决策还是要由人类自己通过思考来完成。人类的价值也正在于此,擅长获取大量不同信息并做出推理、解决问题。


在 Werner 眼里,善用技术既是一种道德要求,也构成了有利可图的重要事业。在未来几年,科技的应用将不仅仅为了产生积极影响,更将重塑我们对成功的定义。

2024-12-06 20:5715877

评论

发布
暂无评论
发现更多内容

【极客大学】【架构师训练营】【第四周】典型大型互联网应用系统的技术方案和手段

NieXY

极客大学架构师训练营

云计算 “拍了拍” Serverless

零度

云计算 Serverless 互联网 计算机

架构师训练营 week03 总结

尔东雨田

极客大学架构师训练营

深入浅出Shiro系列——权限认证

程序员的时光

权限系统

通俗易懂的 Deno 入门教程

阿宝哥

typescript 大前端 deno

大型互联网应用系统技术方案和手段总结

CATTY

互联网

用100行代码手写一个Hystrix

小眼睛聊技术

Java 架构 高可用 设计 后端

架构师训练营第四周作业

一剑

小师妹学JVM之:逃逸分析和TLAB

程序那些事

Java JVM TLAB 逃逸分析 签约计划第二季

架构师第四周作业

傻傻的帅

架构师第四周学习总结

傻傻的帅

从不可描述的服务雪崩到初探Hystrix

老胡爱分享

高可用 灾备

week4总结---系统架构

Geek_z9dmvw

架构师训练营 week03 作业

尔东雨田

极客大学架构师训练营

Week4 作业

Shawn

架构师训练营」第 4 周作业

edd

Week04 作业

极客大学架构师训练营

大型系统常用的技术方案和技术手段

imicode

中国未来需要什么样的人才?机遇与挑战!

CECBC

CECBC 中国人才 中国脊梁 数字经济

架构师训练营第四周-系统架构综述

草原上的奔跑

重学 Java 设计模式:实战观察者模式「模拟类似小客车指标摇号过程,监听消息通知用户中签场景」

小傅哥

Java 设计模式 小傅哥 代码优化 观察者模式

DevOps研发模式下「产品质量度量」方案实践

狂师

DevOps 研发管理 研发效能 开发流程

互联网系统架构总结

周冬辉

week04 互联网架构发展学习总结

李锦

浅谈互联网系统架构

鲁米

【微信聊天】5张图帮你看懂二分查找

Java小咖秀

Java 算法 漫画 二分查找

做产品少走弯路:你需要懂点高阶的知识

我是IT民工

产品 管理 知识体系

第四周课程总结

考尔菲德

一个典型的大型互联网应用系统使用哪些技术方案和手段

李锦

极客大学架构师训练营

维基百科(Wikipedia)网站架构设计分析

架构5班杨娟Jessie

极客大学架构师训练营

大型互联网应用系统的技术方案和手段(训练营第四课)

看山是山

分布式 微服务 极客大学架构师训练营

在架构方面,没有谁比亚马逊的 CTO 更能预见未来_架构_凌敏_InfoQ精选文章