QCon 演讲火热征集中,快来分享技术实践与洞见! 了解详情
写点什么

在架构方面,没有谁比亚马逊的 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:5711320

评论

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

如何进行数据挖掘?

郑州埃文科技

数据挖掘 数据库

Go HTTP Server 基于OpenTelemetry 使用Jaeger - 代码实操

非晓为骁

Go Docker Trace Jaeger OpenTelemetry

Gitlab-ci 替代 webhook 触发Jenkins job

网易云信

gitlab

APICloud平台使用融云模块实现音视频通话实践经验总结分享

YonBuilder低代码开发平台

前端开发 APP开发 APICloud 融云 跨端开发

低代码实现探索(三十七)业务的流程,开发的框架

零道云-混合式低代码平台

如何使用OKR管理团队?

优秀

云计算及国内主流云厂商概述

穿过生命散发芬芳

3月月更

盲盒风潮过后,中国收藏玩具市场该何去何从?

易观分析

盲盒 潮玩

企业知识管理的目标是什么?

小炮

向工程腐化开炮 | Java代码治理

阿里巴巴终端技术

Java android JVM 代码治理

hexo+github搭建个人博客前期部署工作

静Yu

Hexo

ICASSP 2022 | 前沿音视频成果分享:基于可变形卷积的压缩视频质量增强网络

阿里云CloudImagine

阿里云 计算机视觉 音视频 视频编码 视频云

大数据培训:Hadoop和MPP有什么区别

@零度

hadoop MPP 大数据开发

java培训:SpringBoot高频面试考点分享

@零度

JAVA开发 springboot

【51单片机】室友用一把王者时间,学会了去使用数码管

謓泽

3月月更

Jaeger docker部署实操

非晓为骁

Docker Jaeger Go 语言 http client

如何从头到脚彻底解决一个MySQL Bug?华为云数据库高级专家带你看

华为云数据库小助手

bug GaussDB 华为云数据库 GaussDB(for MySQL)

【直播回顾】OpenHarmony知识赋能第四期直播——标准系统HDF开发

OpenHarmony开发者

直播 HDF OpenHarmony

WebRTC 简单入门

ZEGO即构

WebRTC 动手实践 音视频开发 即构科技

移动域全链路可观测架构和关键技术

阿里巴巴终端技术

架构 App 移动端 体验优化

N个技巧,编写更高效 Dockerfile|云效工程师指北

阿里云云效

阿里云 云原生 Dockerfile 部署与维护 构建工具

TiDB 可观测性方案落地探索 | “我们这么菜评委不会生气吧”团队访谈

PingCAP

数字化时代下,智能运维全栈监控解决方案及案例盘点

云智慧AIOps社区

运维 解决方案 场景应用 自动化运维 运维安全

喜讯!openGauss社区入选2021年 “科创中国”榜单

openGauss

JavaScript深入理解之闭包

锋享前端

OceanBase 社区版 运维管控平台 OCP 功能解读

OceanBase 数据库

OCP oceanbase OceanBase 开源 OceanBase 社区版

【IT运维】多台海外主机运维用什么工具好?

行云管家

服务器 IT运维 服务器运维 海外主机

中国AI的下一站:从两会高地奔涌向产业河谷

脑极体

企业内PAAS建设的经验与教训

Crazy

中间件 PaaS 经验 云原生应用

打造优质的车联网体验,仍需注意数据安全保护

FinClip

实用机器学习笔记二十五:超参数优化

打工人!

学习笔记 超参数调优 机器学习算法 3月月更

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