实际上我们在撰写技术雷达时所进行的讨论通常暗含了整个技术行业正在发生的重大变革。在这里,我将采用更宏观的视野来描述它们。
ThoughtWorks技术雷达在每期发布的时候都会产出几个主题,往往是一些非常具体的建议。实际上我们在确定这些建议背后所进行的讨论通常暗含了整个技术行业正在发生的重大变革。因此,在这里,我将采用更宏观的视野来描述它们。
你可能跟我一样已经疲于阅读跟这次新冠肺炎疫情相关的各种报道与评论。但是,必须承认的是它对技术行业的影响是巨大的,因此发生的某些变化将永久持续。下面是我认为最重要的事实和可能发生的变化。
我们软件行业从业者比较适合在家工作,但仍然不能免受学校封闭、无法获得托儿服务所带来的影响以及疫情引起的心理压力。这种情况下个人对生活环境的容忍度就显得尤其重要,特别是会对工作造成影响的部分,毕竟并非每个人都拥有一个设备齐全的家庭办公室或能够独立照顾自己的孩子。
在大规模实行远程办公的初期,出现了争夺基础设施、访问权限和工具的现象,但现在所有的基础资源都已经到位。远程协作正从“我们是否能做到?”的自我怀疑转变成“怎样做才正确?”的卓越追求,在这一点上我们目前有很多东西要去学习。许多人意识到,整天连接在视频会议是一种浪费,直接将面对面的协作技术生硬地移植到数字世界并不高效。相反,我们应该仔细考虑团队成员何时需要在线沟通,何时可以通过异步的方式进行协作,以及哪些数字化的工具最适合我们的工作场景。由于疫情的发生,我们通过远程协作的方式制作了这一期技术雷达,并在此过程中学到了很多东西;如果你想了解更多与此相关的信息,可以查看记录着我们工作实践的播客。
ThoughtWorks十分提倡结对编程的实践,我们在这一版的技术雷达中记录了“实用的远程结对”。
简而言之,结对编程完全可以在纯远程工作环境中实现,但是你必须要考虑工具、带宽和时区等因素带来的影响。
疫情的发生为每个公司的CIO揭露了其数字基础设施中的缺陷,无论是当客户迁移到线上时所面临的弹性和扩展性问题,还是快速响应变化的能力问题,亦或是添加新功能并快速上线的能力问题。大多数组织已经意识到了造成这些不便利因素的真实原因:他们远远落后于最新的技术体系,并且正在努力进行“数字化转型”(无论那意味着什么)来追赶。
作为一家咨询公司,我们在整个行业内拥有相对广泛的视野,我们发现其中一些变化能够产生非常积极的影响。之前坚持“您必须在办公室使用我们的硬件工作”的客户已经有所转变。现实中的面对面交流被虚拟的面对面视频会议所代替,在某些情况下,这是一个巨大的好处:我们的客户可以利用全球性的专属网络,而这个人位于何处都无所谓(当然,时区会有影响)。有趣的是,虽然从理论上讲在疫情之前,我们的客户可以与这些人直接接触,但事实证明,现在这种远程协作的做法障碍要少得多。由于大概率不会在现场展开工作,需要本身具有一些该领域的背景知识,因此我们不建议非领域专家来帮助客户。我希望在整个行业中,所有人将来都可以在远程工作上投入更多的时间,而不是将大量的时间浪费在乘坐飞机上。
汤姆·马龙(Tom Malone)教授(MIT)认为,当前的危机迫使我们提前十年接受远程办公,并且没有回头路可走。市区办公空间的价值会因为人们更愿意在家中或者小型的邻里办公室工作而不是在花费一个小时通勤而有所降低。一些科技公司期望即使在疫情结束后,仍有很大一部分员工保持远程工作,甚至有70%的员工将永久性地进行远程办公。
技术会议也已完全虚拟化,并以非常有趣的方式进行了创新。网络上有一个“荒岛DevOps大会”(Deserted Island DevOps)的例子:为期一天的会议完全在“集合啦!动物森友会”游戏内举行。演示者和与会者使用游戏中的化身来访问会议岛,并能够在其中进行一些小型的小组互动,这一点是我们在面对面会议中非常重视的部分。
每个人呆在家里和关闭产业的一个积极方面是:我们减少了污染,尽管这些是暂时性的。一些预测表明,2020年的碳排放量最多可以减少8%。可再生能源会继续增加其市场份额,并且其在美国发电领域的市场占有率将首次超过煤炭。我们的驾驶量减少了,城市交通流量就有了改善,同时发生的事故也变少了。自从就地庇护令开始以来,加利福尼亚州的交通事故减少了一半,每天为其节省了4000万美元,约合10亿美元。对抗看不见摸不着的病毒所需的集体智慧和对科学的信任也有可能帮助我们在未来应对气候变化方面产生更多价值。
尽管疫情下的生命和经济代价非常惨重,但我希望科技行业可以以此为契机,加速减少炭排放量巨大的差旅并提高包容性和创新性。
我觉得围绕技术雷达进行的最有趣的讨论是要标记为“Hold”的内容。世界各地的ThoughtWorkers提出他们认为存在问题的技术进行讨论,如果我们认为某些事情是跨行业的,我们会将其添加到技术雷达中标记为“Hold”的一环中。但是,当我们深入探讨几个拟议的“Hold”项目的原因和疑虑时,我们逐渐发现其中的一些问题并不是新问题,而是在新的(或更广泛的)环境中出现的老问题。在许多情况下,我们以前关于正确行事方式的建议—— 能够产生积极影响的实践就采纳(“Adopt”)它——这一点直到今天仍然适用。
一个很好的例子是“基础架构即代码”。这是一个非常古老的建议,最初于2011年添加到技术雷达中。我们的同事Kief Morris于2016年出版了有关该主题的书籍,并将于今年下半年发布新的版本。我们目前看到许多组织在进行云迁移时遇到了问题,部分原因是他们没有对云基础架构的定义、管理和自动化实行足够严格的要求。因此,我们没有选择把类似“手工制作的云模板”或“未能进行版本控制的云基础架构定义”这样的条目添加到技术雷达的“Hold”环中,而是利用这次机会更新并再次强调了有关此问题的建议。同样,我们也更新了“管道即代码”这一条目。
之所以会出现这种情况,是因为过去十年的主要故事情节之一是软件的兴起,云的兴起和一系列“xxx 即服务”的兴起。所有这些使我们能够使用易扩展的软件,而不是使用硬编码或物理实例化来描述事物,相较而言,后者响应变化的速度会比较缓慢。最终,我们学到的所有有关如何更好地创建软件的重要实践——模块化、版本控制、自动化测试——都可以并且应该应用于这些更广泛的“软件驱动”场景中。
世界上的每个组织都在迁移到某种类型的云托管,无论是私有云、公共云还是混合云,并且绝大多数都在“四大云服务商”中进行选择——AWS、Azure、GCP和阿里云(Alicloud)。但是,由于他们过于热衷于将系统从内部迁移出去并上云,将来许多应用可能会遇到困难,下面列出了几个可能的问题。
首先,对于云迁移,通常会有所谓“高度乐观”的成本节省和ROI预测。公司拥有和维护数据中心确实是非常昂贵的,但是使用云服务托管也并不便宜,而且也不太可能真正节省任何人力成本。同时,如果使用量的限制仅仅取决于团队成员点击“创建实例”按钮的速度的话,那么在整个环境中可能会演变成为一个庞大而昂贵的问题。
其次,“原样照搬”通常是对一种刻意的迁移策略的描述,而不是对不经思考就进行迁移的贬义评价。企业IT部门具有数百个甚至数千个需要在某个地方运行的独立系统。通过重新设计所有组件来正确理解它们并在云环境中运行的成本显然过于高昂。但是云并不像本地部署—— 服务器一旦出现故障,工作负载将会不断移动 。使传统工作负载在云中可靠运行通常也不是一项零成本的冒险。最佳实践实际上对于特定组织而言非常复杂,甚至对于每个应用程序或一组应用程序都各不相同,并且我们对云进行重新设计的次数越多,就越发能够提高系统可靠性并降低成本。
第三同样与之相关的是,关于在云中构建和运行系统的正确方法仍有很多知识要学习。许多组织发现“成功上云”并不能帮助他们应对由疫情和相关的封锁令引起的需求激增,也不能帮助他们更快地发布新功能。云架构是一个很复杂的新的专业领域,团队需要学习如何部署、扩展、维护和改进其基于云的系统。这比“只要把东西扔到亚马逊上”要花费时间和更多的思考。
我没有必要让自己听起来像个对云怨声载道的老家伙,但我必须指出,业内仍然在持续地滥用具有特定含义的术语。长期以来,我一直对开发人员使用“重构”来表示“修复某些问题”感到恼火,而现在我们还看到了“ CI / CD”(这是两个不同的东西!),“ DevOps”(请不要建立“ DevOps团队”),“微服务”(与SOA有何不同?)和“即代码”(即如何对待代码?)诸如此类。
当下最无意义的术语可能是“数字化(转型)”,具体取决于谁使用它,它可以表示以下任何一种:
最后一条是我对“数字化转型”最推荐的定义,也是我和两个同事共同撰写的一本书。狭义的定义并没有错,但是鉴于组织可能会在数字化转型方面投入大量资金,因此必须明确目标和定义成功,这一点很重要。尤其是使用流行的行业术语时,值得花一些时间来探索和验证对话中的每个人是否都对其持有相同的理解。
希望你喜欢科技行业的最新趋势,并平稳度过这次疫情。我要感谢Andy Yates,Fausto de la Torres,Gareth Morgan,Kief Morris和Rebecca Parsons对本文草案的建议。
原文:https://www.thoughtworks.com/cn/insights/blog/macro-trends-tech-industry-may-2020
领取专属 10元无门槛券
私享最新 技术干货