AI时代，还有什么是不能被取代的？
时至今日，AI已经深入我们生活的方方面面，AI服务机器人也部分取代了人类的工作，比如传统的保安、电话销售、客服等都有AI的介入。由此也就引发了整个社会的思考——有什么工作是AI无法取代的呢？对此，许多人都提出了自己的观点，李开复就曾经说过一个5秒钟理论，即——某项本来由人从事的工作，如果人可以在 5 秒钟以内对工作中需要思考和决策的问题做出相应的决定，那么这项工作就有非常大的可能被人工智能技术全部或部分取代。
比如上述我们提到那些工作，都是因为职业需要的仅仅是惯性操作和体力劳动，即使涉及思考也并不复杂，人工智能的数据分析做起来，反而更高效。而根据“五秒钟”准则来看，如果你的工作需要赋予极大情感、需要有丰富的创造力和想像力、需要不断的与人交流，那么就不会被取代。更直白的说，那些融合了技术与艺术的工作更难被替代，比如绘画、比如视频剪辑，再比如程序员。
很多人可能不理解——程序员难道不是更容易被AI取代吗？其实能够问出这样问题的大多是“外行”，因为在许多业内人看来，一段优质代码的诞生不仅仅是编程技术的应用，更重要的是融合了程序员对于技术的理解和艺术的加工。这就好比那些传世名画不仅仅是色彩和笔法的组成，也凝聚了绘画家们对生活的理解和感悟。也正因为如此，“代码之美”的话题才能够被行业所津津乐道，也更有人愿意从技术与艺术结合的角度来看待程序应用。
在日前举办的亚马逊云科技中国峰会上，就安排了一项名为“DevDay”的活动，从名字就能看出，这也是针对开发者们的一场技术与艺术的碰撞。会上，亚马逊云科技邀请了UCCA尤伦斯当代艺术中心副馆长、UCCA集团艺术总监尤洋作为嘉宾探讨艺术、抽象、美学等话题，同时亚马逊云科技大中华区解决方案架构部总监代闻也分享了亚马逊云科技开发云原生应用的理念和方法，帮助开发者最大化利用云技术之美，实现自由构建，简化开发和运维工作。
“谈到美，第一反应一般不会是技术，而是艺术。然而艺术和技术有很多相同之处。艺术之美往往需要通过抽象来呈现。抽象也呈现技术之美。”在当天的大会上，代闻如是说。其实这并非是代闻个人的观点，许多著名程序员都谈到过“代码之美”，即通过技术上的不断深耕，实现让代码变得更简洁、更抽象、更优雅。比如被业界称为“雷布斯”的雷军早年就是WPS的程序员，他也曾在公开场合表示他写的代码“像诗一样优雅”。
其实纵观计算机硬件软件的发展历程，就是通过抽象追求技术之美的历程。从控制通断的01开始，计算机软硬件的抽象，从二进制的机器语言，发展到支持语义的汇编语言，再到真正为开发者提供高效率构建基础的编程语言，再加上各类精妙的算法，才有了我们工作生活里的各类应用程序。这一个旅程是一个不断抽象的旅程，也是一个从繁到简、从笨重到轻巧实现技术之美的旅程。
从这个角度来说，从代码到云计算，都是对于客观世界的抽象与描述，而在这其中也凝聚了艺术的价值。就以亚马逊云科技为例，当2006年它横空出世的时候，只有是对象存储 Amazon S3、虚拟主机服务 Amazon EC2和消息队列服务Amazon SQS等三种应用，将传统的存储、计算和中间件抽象成网络服务，以API的方式提供给开发者。
而时至今日，亚马逊云科技已经引领云计算发展16年的时间，其服务内容也涵盖了IT应用的各个领域，可谓是五花八门。随着亚马逊云科技服务的不断丰富，云资源管理的抽象变成一个新的课题。针对云上计算环境的抽象和云上资源的抽象，亚马逊云科技推出了两类对应的代码（抽象）：一类应用代码(Application Code)，一类是管理代码（Infrastructure as Code）。
所谓应用代码，是大家比较熟悉的云服务应用相关内容，主要是从业务角度来说的，比如如何实现云原生的应用、如何让服务变得更具弹性和灵活性，如何最大限度降低成本、提升应用效率等等。这些服务包括了计算、存储、网络、安全等多个方面，也体现出了云原生的技术之美。
而管理代码则更多侧重于效率层面。比如过去16年间，亚马逊云科技陆续推出的200多种全功能的服务，而围绕这些服务衍生出了各个环节的自动化应用，这些应用就属于管理代码的范畴。2019年，亚马云科技的Cloud Development Kit（CDK）重磅发布，开发者不仅可以使用熟悉的编程语言，而且可以使用Imperative 命令式编程的方式编写管理代码。去年，亚马逊云科技更是推出Cloud Control API，可以让开发者采用自定义 API 的方式，灵活管理亚马逊云科技和合作伙伴的第三方服务，还发布了 Construct Hub，目标是建设一个开源社区，让大家可以自由交流云资源管理的代码。
也正是得益于这两种代码的抽象作用，亚马逊云科技将技术与艺术实现了完美融合，也打造出了属于自己的一个“代码帝国”。在这里，亚马逊云科技通过“架构典范之美”、“组件抽象之美”和“流程灵动之美”提供了一个更具艺术气息的氛围，也让开发者们更好的融入其中，称为了“代码艺术家”。
架构典范之美是亚马逊云科技的立足之本。早在20年前的2002年，亚马逊就着手为服务化改造，在设计技术、流程、组织等多个方面实现了微服务架构，截止2020年，亚马逊电商内部已经有10万多个微服务在运行。到了在亚马逊云科技2021 re:Invent全球大会上，亚马逊CTO Werner Vogels也对微服务和API设计有一个经典的总结——API永远存在、 永远不要破坏向后兼容性、从客户场景出发逆向工作 、创建具有显式有据可查故障模式的API、创建服务于明确目标的自描述 API以及不惜一切代价避免泄露实现细节。正是有了这样的价值观和方法论，也奠定了亚马逊云科技在架构层面的稳定、高效、安全，使得云计算的基石更为稳定和牢固。
组件抽象之美则赋予了亚马逊云科技服务的灵魂。随着云计算成为新常态，一个优良的架构在云上落地有多种选择。这时，云原生架构的理念开始兴起。云原生应用的架构充分利用按需交付、全球部署、弹性和更高级别的云服务。它们大大提高了开发人员的工作效率、业务敏捷性、可扩展性、可用性、资源利用率和成本优化。云原生是一个相对的概念，因为云服务本身就在不断演进中。在一个时间点上如何选用合适的组件，就是云原生架构落地最基础的一步。
这张图的纵轴是计算环境抽象的三个层次。如前所说，亚马逊云科技在基础设施服务的三个层面都有良好的服务支撑。经过多年的发展，亚马逊云科技已经让三个抽象层次的计算能力渗透到了各个服务类别中，各个服务自身的云原生已经完成，从而让开发者不仅可以选择自己的应用代码运行环境的抽象层次，而且可以根据业务场景选择需要调用的云资源的抽象层次。例如，开发一款游戏，决定使用无服务器的Amazon Lambda运行业务代码，可以调用无服务器数据库 Amazon DynamoDB 完成游戏任务属性存取的模块，也可以调用基于Amazon EMR on EKS容器化部署的大数据服务，这让开发者自由选择代码运行的抽象层级，并能够提供不同抽象层级的云资源，彼此调用没有阻碍，实现真正的自由构建。
如果说之前的架构和组件构成了亚马逊云科技的形神兼备的话，那么最后的流程灵动之美更具备了画龙点睛的意义。对于开发者，简洁而灵活的开发和运维流程是支撑应用持续迭代、保持生命力的基础。为此亚马逊云科技提供了一系列的服务和工具，让开发者从构建、治理、迭代三个阶段顺利实现云原生应用落地之旅。在构建阶段，可以快速搭建和验证架构，快速交付MVP；在治理阶段，可以保持良好的可观测性，方便地管理数据和应用安全策略；在应用落地、进入到持续迭代阶段，可以实现自动化部署，更多地实现组件服务化、运维自动化和智能化。
至此，亚马逊云科技让技术与艺术实现了深度融合，也让代码像绘画、音乐等艺术一样，用符号的方式传递出感性与理性的交融，在简洁优雅的数学真理和自我递归的完美重复中体现出代码之美。正如大自然的一滴水、一片树叶那样，随处可见却又姿态万千。
这或许就是老子说的，大道至简吧。
