低代码到底是不是行业毒瘤?一线大厂怎么做的?戳此了解>>> 了解详情
写点什么

开发者到底想从技术(最主要还是云)中得到什么

2016 年 7 月 27 日

由种类各异的工具,尤其是开源工具组成的美丽新世界使得开发者开始取代端坐在城堡里针对技术和软件栈发号施令的人成为新的决策者。在我原本打算发布本文前一分钟,Lightspeed Ventures 公司的 John Vrionis 撰写了一篇文章其实开源软件正在蚕食整个世界,这篇文章完美地论证了我的观点,如果还没读过,强烈建议阅读本文。

我最近发布的博客文章循环的瓦解中也提到过类似的概念,文中提到了一种趋势:当最新最好用的工具开始在市场上立足后,将开始出现更新更热门的技术。如今不同工具间的差异变得越来越微不足道和浅显,主要是用户个人首选项的差异,这些差异的侧重点已不再是核心功能和底层技术本身,更多地体现在开发者所能遇到的第一印象和体验上。因此开发者采纳工具的方式已经不再像接受各种新潮装置或时尚产品那样存在太大的差异。当今的公司恰恰需要向时尚或消费者行业好好学学。

图片来源:Venturebeat,其实开源软件正在蚕食整个世界

虽然很多公司认为自己知道如何以开发者为目标,并清楚开发者想要什么,但具体执行情况和最终的使用率数据通常会证明结果恰恰相反。

目前我们用于向开发者介绍各种功能和特性的说辞已经落伍了,因为我们采用的说辞并不符合他们选择工具的方法,我们只是在按照想当然的方法自说自话。移动应用使用率也体现了类似的问题。

这方面有个很好的证明:在NoSQL 数据库刚问世时,MongoDB 和Cassandra 是当时的领先选手,这两个产品在规格上都是非常出色的数据库产品,但由于在功能和特性方面有更好的扩展性和集群能力,天平本已开始朝向Cassandra 倾斜…后来Mongo 开始领先并一直处于统治地位。从数字来看,Cassandra 从来没能迎头赶上。仔细考虑这种结果的原因会发现,仅仅是因为Mongo 提供了非常简单的API,可以让开发者快速地卷起袖子投入工作。虽然功能更完善强大,但Cassandra 的接口和API 是那么的笨重复杂…

这几乎造成了一种滚雪球效应,一旦围绕某种新工具或技术开始产生各种喧嚣和炒作,每个人都会想要体验一下更好的新玩具。很多情况下开发者选择某种工具仅仅因为这个工具很流行,很时髦,口口相传,或者出于开发者的个人偏好,基本上和工具本身的深层特质无关。

请给我自由…那我想要的到底是啥?

有趣的是,虽然我不太确定,但如果你问一般开发者是否知道该怎样改进API 才能满足他们的需求,他们很可能会说以功能集的形式提供就可以了。《Blink》和《The Tipping Point》两本书的作者Malcolm Gladwell 在2004 年做了一场经典的 Ted Talk ,其中的观点现在也不过时,最主要的结论为:

[为意大利面酱汁提供多样化的选择 - ~NS]…从根本上改变了食品行业取悦顾客的方式。假设多年来食品行业为了设法弄清楚人们想吃啥,怎样才能让大家吃的高兴的头号方法是直接问大家…甚至组建焦点小组,他们会问:“你喜欢啥味的意面酱汁?”二三十年来在所有的焦点小组讨论中,从没有人说过自己喜欢极度浓稠的酱汁,哪怕其中至少有 1/3 的人内心身处是喜欢这种酱汁的。

我还是孩子时可选的牛仔裤只有 Levis 或 Lee 这两个牌子,风格几乎也都是相同的。同样的,当我还是一名羽翼未丰的开发者时,可选的工具和堆栈也没多少,似乎到处都在用 Oracle 和 IBM。企业在面临全面锁定的情况下制定自己的整个市场战略,甚至在金额高达六位数的合同里提供“闲置软件(Shelfware)”,而这样做仅仅为了在需要提供更多工具时能够有“应变计划”。当时没有选择,没有多样化,当然也就很少需要迎合开发者的需求,毕竟开发者的需求不是业务需要考虑的要素。但风水会轮流转。

虽然我们愿意相信所有开发者基本都是相同的,会受到相同动机的驱动:他们只想安静地写代码,但实际上这对不同开发者有不同的含义。取决于开发工作的类型,前端、后端、大数据,以及全栈和 DevOps 等备受关注的流行概念,每个开发者对框架和堆栈都有自己的喜好,很多时候别人并不知道他们的想法。

更重要的是,开发者自己也会受到来自同行和技术趋势,以及用户体验的魅力和 API 等方面同等程度的影响,有时候甚至会因为美观的界面而采用某些最新工具(还记得 Docker 诞生前的世界吗?!)然而从开发者的角度来说 API 是最主要的交互点,API 对开发者的影响甚至与选择新工具时美观的界面等用户体验对普通用户的影响程度不相上下。新世界的这种秩序决定了如果以前产品发布的重点在于核心功能和界面,并需要牺牲 API 的可用性为代价(很多软件公司都会这样做),那么今天 API 很可能成为衡量您的产品能否被接受的最重要元素。

我现在就想要

也就是说,新的挑战已经变成如何为开发者提供尽可能多的框架和工具,而不是如同黑匣子般的体验。以前的想法认为,开发者想要的是麻烦少,省事的体验,这种想法导致 PaaS 前时代的框架即有限又教条。其实这根本站不住脚,虽然开发者希望麻烦少,但他们其实更需要“尽在掌握”的假象,他们希望在需要时至少能对框架进行最基本的调整,因此我们可以发现这样一种趋势:为了获得更灵活的选项,越来越多的开发者开始抛弃 PaaS 框架,更多地开始通过使用不同工具达成自己的目的。

但 AWS 采取了截然不同的方法,随着流行度与日俱增,他们持续不断地抛出新的服务,从这方面来看,这家公司确实值得敬重。他们在设法不断地引领潮流,或者至少保证只落后潮流一小步,并用无与伦比的速度通过新服务迎合当今开发者多样化的想法。

市场规模排名第二的 Microsoft Azure 数据足以说明一切,Microsoft Azure 采取了一种更全面的平台式方法,但在接受度方面已经落后了,新服务的推出速度也很慢。为了满足每个需求而提供混乱的大杂烩服务,AWS 已经被视作云计算市场的“杂货店”;Microsoft Azure 则被视作一个更有序的专业“商店”,会花费时间全面地思考如何将每个服务集成到平台中使其成为整体,但接受度方面处于劣势。

这无疑证明了创新的速度直接影响到被接受的速度。现在的标准已成为你能用多快的速度在自己的云中提供大家想要的新服务,而成功与否取决于你能否赢得开发者的青睐。

虽然 AWS 采取的模式让人印象深刻,很敏捷,很全面… 但完全由自己内部开发所有的这些服务和框架,似乎有些不太经得起考验,扩展性或可持续性也会遇到问题。

均码

这意味着实现这一切的过程中采取了一种通用的方法,这种方法可以适应各种类型的多样化框架,并一直沿用至今,用户可以混搭使用不同框架实现自己的目的。这是一种“均码”的模式。

大家的想法是为了快速采用最新最时髦的框架,将其与完全不可知的平台一起部署,对整体进行抽象并用于任何底层基础结构。大家不清楚到底用了什么平台,更不知道这个平台以后将如何发展。

随后就出现了“编排(Orchestration)”这个流行词汇。

“编排”可以为大量不同种类的框架和应用程序提供通用的自动化和管理机制,因此过去几年来这种技术日渐流行也就没什么稀奇的了。

编排技术也有多种类型,这里简单汇总了大部分最流行的编排工具,这些工具的用途和所采取的方法也各不相同。其中有以基础结构为中心的,例如在相应基础结构之上实现自动化机制的工具,也有以容器为中心的,甚至还有纯粹的编排框架,这种工具更像是一种集成平台,可以将不同类型的基础结构与你的 DevOps 工具链紧密连接在一起。

为不同任务选择恰当的工具

很明显,这个问题涉及的领域非常广泛,没有任何一个解决方案能对每种类型基础结构上运行的所有不同类型工作负载的整个部署过程实现彻底自动化。为了实现这一目标,通常要配合使用多个编排工具。

考虑到整个堆栈是如此复杂,还有那么多不同的基础结构和工作负载,所有这一切都需要使用不同工具加以管理…与此同时新的创新式工具层出不穷(开始晕头转向了吗?!)…必须通过某种方式让这一切变得统一,但也无需让用户明确“一切”都包含什么。

选择 + 速度 + 简化 = 采纳

软件行业需要向时尚产业或任何竞争激烈的面向消费者的行业学习很多东西,这些行业提供了丰富的选择,不同产品之间有极大的差异,虽然大部分差异都是微不足道的,但依然可以为用户提供截然不同的多种选择。这些选择的立足点与理论基础越来越不相关,但与直观的感受和同行口口相传关系越来越紧密。

为了在多样化的软件世界中紧跟技术脉动,我们都需要学习全新的游戏规则。重点不再是那些深入的功能和特性,而是多样化和选择本身。重点在于我们能用多快的速度将这些新功能融入自己的产品,同时确保一切都尽可能保持简单。

这意味着:

  • 更多工具和服务,而非复杂、全面的平台。
  • 有吸引力的 API,这一点甚至比 GUI 更重要,因为 API 已经变成开发者的“前端”。

一般来说,我们需要为开发者提供他们喜欢的 UX,并简化他们使用框架的方式。

基于目前的需求,最终我们都希望自己的公司和团队能被用户视作时尚的科技公司。无论是因为我们需要在开发者面前表现出足够的吸引力,以便让大家接受我们的技术,或者需要吸引最优秀的开发者…总之这些人只想使用最新最棒的工具。

当然,说易行难,现实世界中还需要进行大量实验和迭代,毕竟就算这样的目标也在经常改进和变化。因此最终将由你的创新速度决定什么能成为永恒的时尚,什么会被潮流所抛弃。

关于作者

Nati Shalom GigaSpaces 的创始人兼 CTO,同时也是云计算和大数据技术领域的思想领袖。Shalom 最近刚刚被 CIO Magazine 评为 Top Cloud Computing Blogger(顶尖云计算博主),他的博客也已被 Ycombinator 评为优秀博客。借助对OpenStack 社区所做的贡献,他还当选了 HP Helion MVP Award 。Shalom 是 OpenStack 以色列集团的创始人兼主要领导人之一。他会经常出席各种行业会议并发表演讲。

查看英文原文: What Developers Want From Their Technology (But Mostly Cloud)

2016 年 7 月 27 日 18:361316
用户头像

发布了 283 篇内容, 共 86.5 次阅读, 收获喜欢 38 次。

关注

评论

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

9. Python 学习过程的第一个山坡,99%的人都倒在了山坡下

梦想橡皮擦

Python 2月春节不断更 python入门 python学习

聊聊大公司创新的机制:饱和攻击

boshi

创新 七日更

盘点关于程序员的那些经典案例

孙叫兽

程序员 程序人生 话题讨论 薪水 计算机原理

并发编程系列:线上问题定位

程序员架构进阶

Java 并发 问题排查 七日更 2月春节不断更

理解「分布式系统」曾经发生的事情

读字节

分布式事务 分布式系统 分布式数据储存 TiDB EJB

Scrum Patterns:梳理产品待办列表(译)

Bruce Talk

敏捷开发 译文 Agile Scrum Patterns

书画装裱物料与选择参考

boshi

业余爱好 七日更

性能压测的时候,随着并发压力的增加,系统响应时间和吞吐量如何变化,为什么?

跳蚤

《我们脑中挥之不去的问题》 - 卓克科普(2)

石云升

读书笔记 科普 2月春节不断更

第十二周 数据应用一 作业 「架构师训练营 3 期」

feiyun123

第7周作业

cafebaby

浅谈性能优化

跳蚤

Java SE最佳实践

jiangling500

Java 最佳实践 Java SE

还傻傻分不清楚equals和==的区别吗?看完就明白了

codevald

Java 源码分析 string Object

深入浅出函数式编程:Stream流水线的实现原理

码农架构

Java 架构 微服务 Java 8

Tomcat速查手册

jiangling500

Java tomcat

【STM32】串口通信---用代码与芯片对话

AXYZdong

硬件 stm32 2月春节不断更

Elasticsearch Mapping Overview

escray

elastic 七日更 死磕Elasticsearch 60天通过Elastic认证考试 2月春节不断更

熬夜总结了 “HTML5画布” 的知识点(共10条)

魔王哪吒

学习 读书笔记 程序员 随笔杂谈 2月春节不断更

LeetCode 数据库刷题 - 1179. 重新格式化部门表

小马哥

七日更 二月春节不断更

写一个用例(总结)第四周

mas

机器学习·笔记之:

Nydia

写一个用例(第四周)

mas

gradle中的build script详解

程序那些事

maven Gradle 程序那些事 构建脚本 构建程序

【看动漫学编程】程序员在异世界生个娃 第一篇:太极村

1_bit

编程语言 编程之路 看漫画学编程

JDBC速查手册

jiangling500

Java JDBC

《我们脑中挥之不去的问题》- 卓克科普(1)

石云升

读书笔记 科普 2月春节不断更

Chrome浏览器多进程架构3个必会知识点

梁龙先森

前端 浏览器 面试题总结

杨明越:Kubernetes的下一仗可能是提升标准化程度

杨明越

日记 2021年2月13日(周六)

Changing Lin

2月春节不断更

我在极客时间录课的故事(三):课程录完了,服务才刚刚开始

李艺

我在极客时间录课的故事

2021 ThoughtWorks 技术雷达峰会

2021 ThoughtWorks 技术雷达峰会

开发者到底想从技术(最主要还是云)中得到什么-InfoQ