软件科技工业的十年回顾和展望 - Cindy Sridharan


随着2019年的临近,我想写下一些关于过去十年中一些最重要的技术采用和技术创新的想法。我还展望了未来,列举了未来十年可以解决的痛点和机遇。
本文不涉及数据科学,人工智能,前端工程等领域的发展,因为我个人在这些领域没有太多经验。

类型反击
2010年代最受欢迎的趋势之一是类型语言的兴起。诚然,类型化语言从未完全消失(C ++和Java在2010年仍然占主导地位),但是自从Ruby on Rails运动于2005年出现以来,动态语言的使用量急剧上升。 2009年,随着Node.js的开源,使crescendo变得越来越激烈,这使得服务器上的Javascript成为现实。
随着十年的发展,动态语言在构建服务器端软件时失去了一些思想。在Docker和容器革命的推动下流行的Go编程语言似乎更适合于构建高性能,并发,资源高效的服务器(node.js的创建者对此表示赞同)。
Rust编程语言于2010年推出,它在类型理论方面取得了进步,可提供一种安全的类型化语言。尽管Rust在本十年的前半段在工业中的采用程度不高,但在下半年的十年中却出现了显着增长。在行业中使用Rust的著名例子包括Dropbox在Rust中将Rust用于Magic PocketAWS的Firecracker,Fastly(现在为bytecodealliance)的Web前端编译器Lucet等等。微软探索使用Rust重写Windows操作系统的部分,我肯定地说,Rust在21世纪20年代有一个光明的未来。
甚至动态语言也获得了可选类型等功能。Typescript引入了可选类型,这使得编写编写为Javascript的类型化代码成为可能。PHP,Ruby和Python获得了逐渐用于生产的渐变类型系统(mypyHack)。

将SQL放回NoSQL中
NoSQL是另一种技术,在本世纪初比在末期更受欢迎。我认为发生这种情况的原因有两个方面。
首先,由于NoSQL模型缺乏模式,事务和较弱的一致性保证,因此难以对照该SQL模型进行编程。Google 在标题为“为什么要尽可能选择强一致性” 的博客文章中指出:

我们在Google上了解到的一件事是,当开发人员可以依靠基础数据存储来处理复杂的事务处理并保持数据有序时,应用程序代码更简单,开发计划也更短。引用Spanner的原始论文,“我们认为最好是让应用程序程序员处理由于出现瓶颈而过度使用事务而导致的性能问题,而不是总是围绕缺乏事务进行编码。”

第二个原因是由于公共云中诸如Cloud SpannerAWS Aurora之类的“可扩展”分布式SQL数据库的兴起以及诸如CockroachDB之类的开源替代方案的出现,这些解决了传统SQL数据库“没有规模”。甚至是“ NoSQL”运动的发源MongoDB现在也提供分布式事务:

对于需要原子性地读写多个文档(在单个或多个集合中)的情况,MongoDB支持多文档事务。使用分布式事务,可以跨多个操作,集合,数据库,文档和分片使用事务。

流化所有东西
毫无疑问,Apache Kafka是2010年代最重要的创新之一。Kafka于2011年1月开源,彻底改变了企业处理数据的方式。从初创公司到大型公司,Kafka一直在我工作过的所有公司中使用。它提供的保证和启用的用例(发布,订阅,流,事件驱动的体系结构)已用于实现跨企业(财务,医疗保健,政府)的所有数据,从数据仓库到监视到流分析的一切。 ,零售等)。

持续集成(在较小程度上,持续部署)
持续集成(CI)不是在2010年代的发明,但它是在这十年成为普遍到成为默认的工作流(所有引入请求运行测试)的一部分点。GitHub成为代码托管和开发平台的兴起,更重要的是GitHub 工作流的兴起,意味着在将拉取请求合并到主干之前运行所有测试是许多在这十年中开始职业生涯的工程师所熟悉的唯一开发工作流。
持续部署(部署每一个承诺的,当它停靠于躯干)是不是很为普遍的做法是持续集成(传言说),但与无数的云API进行部署,像Kubernetes平台日益普及,它提供一个标准化的API对于部署以及诸如在上述标准化API上构建的Spinnaker之类的多平台,多云工具的出现,总体而言,部署实践变得更加自动化,精简,并且从总体上讲更加安全。

容器
容器可能是最受炒作,谈论,营销和误解的容器,但它也是在2010年代获得采用的最重要的技术之一。发出刺耳声音的部分原因是混合消息,我们似乎从各个角落遭到轰炸。如今,这种骚动已经微弱地平息了,某些事情更加明显地脱颖而出。
容器是为更广泛的开发人员社区运行应用程序的最佳方法。容器之所以受欢迎,是因为它成为解决一种完全不同的问题的工具的市场呼声。事实证明,Docker是出色的开发人员工具,它解决了“在我的机器上工作”这一非常实际的问题。
更准确地说,Docker镜像是革命性的,因为它解决了环境之间的奇偶性以及不仅应用程序二进制文件而且还包括所有软件和OS依赖项的真正可移植性的问题。它也最终以某种方式最终普及了“容器”这一事实,这实际上是一个非常低级的实现细节,这可能是我十年来最令人困惑的事情之一。

Serverless
我认为“无服务器”计算的问世比容器更重要,因为它确实使“按需计算”的梦想成为现实。在过去的5年中,我看到无服务器计算通常会扩展其范围(通过增加对更多语言和运行时的支持)。推出诸如Azure持久功能之类的产品似乎是使有状态功能成为现实的正确步骤(同时解决有关FaaS局限性的一些问题)。有趣的是,这种新的计算范式在未来几年将如何发展。

自动化运维
运维工程界可能从这一趋势中受益最大,因为它使诸如“基础架构即代码”之类的发展成为现实。这也与“ SRE文化”的兴起步调一致,“ SRE文化”旨在对运营工程采取更加面向软件的方法。

物联网的API化
另一个有趣的发展是许多开发问题的API标准化。良好的,可破解的API使开发人员能够构建新颖的工作流和工具,从而有助于维护和可用性。
API规范化也是迈向功能或工具SaaS规范化的第一步。这也与微服务的兴起相吻合,因为SaaS工具现在已成为通过API与之对话的另一项服务。在监控,支付,负载平衡,持续集成,警报,功能标记,内容交付网络,流量工程(例如DNS)等领域,已经有很多SaaS和FOSS工具,并且在此十年中蓬勃发展。

可观察性
可以公平地说,我们现在拥有比监控和诊断应用程序行为更好的工具。Prometheus监控系统于2015年开源,也许是我使用过的最好的监控系统。虽然不是完美的,但它可以解决很多问题(尤其是在度量方面支持维数)。
由于采用了OpenTracing(及其后续产品OpenTelemetry)等计划,分布式跟踪是另一种在2010年代变得比以往更多的人意识到的技术。尽管仍然很难使用跟踪,但是跟踪的一些最新进展使我希望2020年代将释放跟踪数据的真正潜力。

展望未来
1. 尽管CI逐渐成为主流绝对是2010年代的杰出进步之一,但Jenkins仍然保持着CI的黄金标准,在以下领域,还迫切需要创新:

  • 用户界面(用于编码测试规范的DSL)
  • 实施细节,这将使其真正具有可扩展性和快速性
  • 与不同环境(阶段,产品等)的集成,以实现更高级的测试形式
  • 持续验证和部署

2.开发者工具,本地开发环境,特别是对于从事大规模面向服务架构的工程师而言,仍然是一个痛点。尽管有一些项目试图解决这个问题,但是探索这种用例最符合人体工程学的UX的外观将很有趣。
探索我们如何将“便携式环境”的概念带入其他开发领域,例如重现特定环境或设置中遇到的错误(或易碎测试),也将是一件很有趣的事情。
我希望看到更多创新的其他领域是:语义代码搜索,“特定于上下文”的代码搜索和工具,这些工具可以使生产事件与代码库的特定部分相关联,仅举几例。

3.计算(PaaS的未来),尽管容器和“无服务器”是在2010年代引起最大轰动的流行语,但最近几年,公共云中的计算范围已经扩大了很多。尽管Kubernetes无疑比Heroku具有更强大的功能,可编程性和可扩展性,但我确实想念起它开始和部署到Heroku时多么容易。如果知道如何使用git,则可以使用Heroku。这使我想到了下一个要点:我们需要更好的,更高级别的抽象(尤其是最高级别的抽象)来工作。

4.正确的最高级别的API,Kubernetes在许多方面都与Docker存在类似的问题,因为所有有关如何提供出色且可组合的抽象的讨论都没有很好地封装各种问题的层次。它的核心是容器编排器,它在一组机器上运行容器。这是一个较低级别的问题,仅适用于操作集群的工程师。Kubernetes也是最高级别的抽象,这是一个CLI工具,用户应该通过yaml与之交互。
Docker曾经(并且仍然)是一个出色的开发人员工具,无论其其他缺陷如何。尽管它尝试做很多事情,但它拥有最高级别的抽象权。“最高层次的抽象”是指目标受众(在这种情况下,他们将大部分时间花在本地开发环境上的开发人员)真正感兴趣的功能子集就是开箱即用。
Kubernetes有多个受众:

  • 集群管理员
  • 基础架构软件工程师扩展Kubernetes并在其之上构建平台
  • 与Kubernetes进行交互的最终用户 kubectl

Kubernetes的“一个适合所有人的API”方法带来了一大堆复杂性,这些复杂性没有得到很好的封装,没有指导如何缩放高度,从而导致学习曲线不必要地陡峭。
我认为当今许多基础设施技术水平太低(因此,很普遍,“太复杂”了)。Kubernetes是相当低的水平。今天实现的分布式跟踪(将一堆跨度缝合在一起以形成traceview)太低了。为开发人员量身定做“最高层次的抽象”的工具往往是最成功的。
现在,云原生生态系统有点低级财富的尴尬。作为一个行业,我们需要对正确的“最高级别的抽象”的外观进行创新,实验和教育。