As-a-service 正在重新定义开发人员

阅读数:1057 2019 年 10 月 30 日 15:38

As-a-service 正在重新定义开发人员

在我看来,目前的发展趋势可能会彻底消灭编写代码这一技能需求。

我还清楚得记得那一天,我们把公司的解决方案从一组广泛分布的数据中心处迁移到了云端。那天是 8 月 15 号,意大利的法定假日。我们本来应该放松一下,但却经历了人生中最艰难的 24 个小时。虽然已经进行了长达几个月的准备,并计划在当年年底之间完成云迁移,但那一天,某座数据中心的故障让我们不得不临时调整规划。实际上,驱使我们选择提前迁移的理由已经相当充分:多年来,我们已经无数次经历过这类与“系统”相关的故障状况,但我们的软件却一直非常可靠。这种不匹配性,让我们下决心尽快摆脱折磨。

那时候的 AWS 服务要比现在简单得多,但它已经能够利用分布式架构帮助用户摆脱托管带来的运营困扰,这也是最吸引我们的一点。对我们来说,这意味着技术人员可以专注于建立品牌文化、忽略大部分硬件与系统问题,同时充分发挥我们在软件开发方面的强大优势。换言之,什么交换机、路由器、刀片服务器、冗余光纤链路等等,从此以后一切与我无关!

我又找到了那种久违的放松感觉,上一次有这种感觉,还是在使用 C 语言代替 x86 ASM 的时候。当时我突然发现自己不用专注于系统的硬件实现,而可以专注于算法本身,这可真是太妙啦。

如果从我的个人角度出发,那么我认为 AWS 的发展转折点在于 AWS S3 的上线。是的,它确实拥有极高的可用性,也能实现无限扩展,同时提供高级接口(通过 HTTP);但对我来说,S3 最重要的优势在于它不属于传统存储方案。

As-a-service 正在重新定义开发人员

云块存储魔法:需要什么拿什么,怎么来的不用管。

这是一种范式的转变,让我们从系统领域真正转移到了应用领域。我们开始忽略系统的架构或者工作方式,也不需要面对可靠性或者优化问题;现在,我们只需要使用稳定的接口与 SLA,即可有效支持自己的软件方案。虽然云迁移需要一点信念来支撑(我们也曾怀疑云服务在压力下的表现如何?真的能够无缝扩展吗?我们该如何降低延迟?),但在体验到“足够令人满意”的结果后,我们承认自己再也离不开云服务了。而无数成功案例表明,我们绝不是唯一有这种感受的用户。

多年以来,随着产品的不断发展,云服务供应商也早已超越了最初的计算、存储以及数据库等基础服务。以 AWS 为例,他们引入了 SQS(可扩展队列)、数据流水线(在组件之间提供可视化管理通信流),并开始提供能够满足开发人员需求的更多补充性服务。这意味着云服务已经不再是简单对硬件或者软件组件进行“虚拟化”,而是越来越以客户为中心——这彻底颠覆了以往以产品为中心的基本思路。AWS Lambda(无服务器计算)甚至更进一步,强迫用户忘记与系统相关的一切细节,就连容器一类虚拟系统都不用在意。此外,AWS Athena(我们要感谢 Facebook 开发的 Presto,这正是 Athena 的设计前身)也让用户摆脱了规模伸缩与数据模式等难题,直接享受查询服务带来的便利。

通过云迁移,我们的生产力得到了显著提升,唯一的代价就是我们失去了对底层系统的控制权。具体来说,我们需要学习如何在无法染指底层硬件与软件堆栈的前提下充分发挥资源潜力以实现必需的性能与可靠性指标——毕竟所有组件均以完全托管的方式提供,我们在架构层面也因此受到严格限制。失去底层优化能力,换来的是可观的管理成本节约:当然,这对我们这样的企业与产品形式来说,其实是件好事。

最近,我在一段介绍公司业务架构的视频当中提到我们的架构选择,包括如何实时收集数据并分析事件中的信息。我们有一款名叫智能数字化资产管理的产品,其中的推荐、分析以及其他各种组件都属于数据密集型系统。其架构非常复杂,因为这套系统需要管理数据与模型变更(包括对新事件处理与事件分类),需要保证服务的持续可用性(即使在数据与模型更新期间,也必须能够提供查询建议),同时确保系统能够处理大规模数据。

这里顺带一提:我们采用了 Lambda 架构以及配合蓝绿部署的 ElasticSearch 集群。

这种设计选项在传统硬件或软件堆栈当中无疑将是一场噩梦,但现在我们可以利用高级组件管理事件流程,因此轻松构建起一套完整的、能够在短短七个工作日内上线的业务架构。

我们的工程师绝对是世界上最出色的技术人才(不开玩笑),但如果不依赖于 Lambda、Data Pipeline 以及 EMR 等构建单元,那么公司绝对不可能以同样的成本与开发周期实现这一成果。

在我看来,最近关于 AI 的炒作与云转型有着同样的根源:我认为神经网络(以及胶囊网络等其他变体)都源自这样一个事实——从“描述如何解决问题”转变为“描述我们想要的结果”。在使用神经网络时,我们不需要告诉机器具体该做什么,而是在馈送输入信息时向机器提供符合期望的数据……在大量示例的引导下,模型自己就会掌握其中的诀窍。

AutoML 系统就是个非常典型的示例:我们甚至不需要了解到底该使用哪种神经网络架构,只需要将数据放进系统并描述想要得到的结果,其他一切都将“魔术般地”变成现实。

神经网络的意义并不在于很多人幻想出来的所谓“超级智能”;它之所以有趣,是因为它为我们带来了一种能够让机器计算结果、无需告诉机器具体该如何操作,同时实现成本又比较低廉的全新技术方法。

近年来,随着基础设施在资源与规模方面的快速提升,神经网络的可行性得到有力保障,因此我相信第四代乃至第五代编程语言也将像云计算一样呈现出“即服务(As-a-service)”的新面貌:我们只需要向其描述想要的结果,而无需描述如何实现。

As-a-service 正在重新定义开发人员

神经网络是一种新语言,可用于描述我们需要的结果——而非具体实现方法。

想想看,我们使用第四代语言已经有数十年之久,而现在我们拥有的 graphQL 等工具已经能够完成数据关系设计、Step Functions 无服务器代码执行编排等一系列任务……换言之,基础工具集已经准备就绪。

我们等待的,就是第四代编程语言(或者说接下来的第五代)能够迎来自己的“云迁移”:描述想要实现的结果、约束条件,基础设施与代码都将由“编译器”自主解决,包括选定最适合的架构规模。此外,所有变更都随时间动态进行以匹配用户的具体需求。

我坚信十年之后的编程体验将大不相同,那时候的编程只需要涉及目标设定、要求描述与约束设置几项,而机器管理之类的破事都将由自主系统独力完成。我期待着各大云服务供应商能够在未来几年内拿出令人惊喜的相关解决方案。

我是非常期待啦,不知道各位朋友赞不赞成我的想法?

原文链接:
As-a-service offering is changing what a developer is

评论

发布