（昨天看球，再加上自己一直在思考一个问题，根本停不下来，所以今天暂停更新「途客们的旅行梦」）
周三Juniper新CEO Shaygan访问sale office，问了大家一个问题：如何double我们的revenue...这是个天马行空的，CEO专属的高大上问题，在憋了半个多小时后，程序君一时没有抑制住，就blabla回答开来：
Let's ask ourselves - how others perceive Juniper? ...
我当时提了几个点：
(1) 现在是互联网时代，过去两波浪潮：web2.0/mobile internet，现在正在开始的第三波intelligent hardware，Juniper的位置在哪？
(2) 三波浪潮产生的「新经济」，从网络设备商的角度看，和运营商主导的「旧经济」有何不同？
(3) 我们可以怎么做？
后来回家又仔细想了想，觉得这作为一个思维训练，纸上谈兵一下也不错。
没能很好地从互联网公司火爆增长带来的新经济中获得同等规模的利益恐怕是所有网络设备厂商之痛 —— 否则你无法解释为何NASDAQ的互联网股票火得一塌糊涂，但cisco/juniper等vendor的股票在过去五年甚至更长的时间里没有太大起色（新IPO的PAN暂且不谈）。本来，互联网公司的兴起给广大的设备上一个新的，巨大的增长点 —— 大量的服务器之间需要互通互联，协同工作，所以需要成比例的网络设备 —— 无论是路由，交换，还是安全产品。但是，我们更多地看到一些本来该大量购买juniper设备的巨无霸，如google，amazon和facebook们更多地转向了OEM网络设备，自己写软件，来支撑他们的infrastructure。这不啻于狠狠扇了设备厂商一个大耳光：「你们的系统做得又烂又贵，我们只好自己动手哩」。
如果想获得新的利润增长点，达到两倍，甚至N倍的收益，设备厂商需要理解和追逐引领新经济的互联网公司 —— 由此，需要放低身段，重新学习。
无论你认可与否，互联网公司正在以一种前所未有的速度冲击各个行业，首当其冲的就是IT产业。过去那种一年多一个产品迭代，顾客被动地等待产品出炉的时代已经过去了，很多公司以月，甚至以周为单位更新他们的产品。这种速度让传统的IT公司，像Juniper很不舒服，因为无论从组织结构，go-to-market方式，员工心态等都无法与互联网公司保持基调。所以，当我们把紧盯着AT&T，美林银行这样的金牌顾客身上的目光稍稍收回，投向一个更广阔的市场时，我们发现，一切都那么地不一样，让人手足无措。
我觉得，这种不一样包括（但不限于）以下方面：
(1) 更快捷地响应变化 —— 产品更新的频次
(2) 更「智能」的产品 —— 可以定制化的programmable network
(3) 更直接的生意 —— Developer to developer来达成销售
抛开第一点不说，我谈谈后面两点。
产品
设备厂商首先面临的问题是自己对网络的理解已经落后于一些大型的互联网公司了 —— 这是个不得不承认的，悲哀的事实。类似于google这样的公司，已经使用其无与伦比的人才资源，开发满足他们自己要求的网络系统多时了。Youtube上大概一两年前有个视频，google做SDN的VP说，他们有50%的网络流量已经跑在了自己构建的SDN系统之上。我想现在这一数字恐怕只会更高。由于 "scratch your own itch"，他们在这个过程中应该掌握了大量的与互联网生产环境直接相关的网络知识。在这一点上，我们不得不承认自己的全面落后。虽然目前这样的公司研发网络产品仅为满足自己的需求，但有朝一日，他们将其独立成一个事业部，把自己内部的需求泛化成一个business，就像现在Amazon AWS或Google Domain所为，那么，即使不是对设备厂商的全盘颠覆，恐怕也是极其巨大的冲击。
那么，互联网公司究竟需要什么样的网络设备？
过去两年，人们一直在谈论openflow和SDN —— 对设备厂商来说，硬件被弱化，成为哑终端，集中式的软件成为网络的主导。跟随也罢，不跟随也罢，但朝着这个方向发展，设备厂商，尤其像Juniper这样竞争优势在硬件（或者说system）上的公司最终只会隔了自己的命：要么被芯片厂商直接替代，要么沦为一家提供廉价硬件的无足轻重的公司。
但幸好到目前为止，SDN还处在嚷嚷的阶段，短期内看不出能够颠覆行业格局的能力。如果我们抛开SDN的概念，抛开openflow的实现不谈，光看背后的产品需求，那么我觉得至少从互联网公司的诉求来看，他们需要的是一个programmable network device —— 这包含两个要素：1) 基于API而不是基于手工配置 2) 有能力深度控制网络。
第一点如果从devops的角度应该很好理解。对于互联网公司，海量的服务器不再需要专门的IT人员来维护，而是开发人员来管理。管理的方式不是手工配置，而是通过puppet，ansible等等工具通过撰写各式各样的脚本来完成。所以，网络设备通过类似的方式管理理所当然。
然而，所有设备厂商的设备都不具备通过脚本进行大规模管理的能力 —— 一来设备厂商的系统一般不开放，无法像对付服务器那样直接在其之上进行开发；二来这些系统也没有真正的API/SDK，供二次开发之用。Juniper虽然有自己的SDK，也提供netconf API，可以通过python进行自动化配置，但我们将其和twitter的API/SDK对比一下，就会发现诸多问题：
1) SDK/API文档不能让开发者快速掌握。twitter的API一个工程师边看文档边试用，半个小时就能大致掌握，但juniper的SDK可远没这么容易上手。这大大限制了使用的人群。
2) SDK/API简直不是给程序员设计的。这个不解释。
3) SDK/API的可用性远达不到「真正」的API的需求 —— 比如说threshold，performance等。使用netconf API 访问某些配置，不管你访问一次还是一万次，速度永远恒定在初始的速度 —— 对于这样一段时间内容不会变化的api，连个起码的cache都没有。这样的API其实还没有脱离让人执行，而不是让机器执行的范畴。
如果说第一点还有挽救的余地 —— 无需根本的改变就能做到，那么第二点「深度控制网络」则需要从系统的基石其开始考虑。比如说对于防火墙，「深度控制」可能是这些内容（不限于）：
a. 是否可以通过api注入路由
b. 是否可以通过api访问session table，甚至对session table进行微调
c. 是否可以通过api快速更新policy（防火墙策略） - 一小时变化数百次，甚至数万次
...
有些东西，看上去像天方夜谭，似乎没什么大用，比如c —— 有什么变态的业务会一小时成千上万次改变policy？但互联网告诉我们，如果你足够稳定，简单，大规模地提供了某项能力，则这能力最终提供的结果可能大大超出你的预期。
programmable network就如programmable internet一样，会从根上改变很多行为。现在internet的协同性越来越好，很多原来一个个小团队无法完成的项目，由于有了programmable internet，如雨后春笋一样冒了出来。这极大地丰富了互联网的体验，反过来促进了整个行业的进一步发展。对于network行业来说，有理由相信programmable network的巨大潜力。
当然，由于我们自身思维的僵化，靠现有的人做这样的产品是不够的，所以在会上我提了一个观点：三五年前google，facebook从juniper挖了些人过去 —— 他们需要了解如何做网络；现在是我们从他们的网络部门挖人的时候了 —— 我们需要了解互联网公司如何做网络，需要什么样的网络。其实当时我特别想举IBM做PC的例子 —— 如果你想做一个完全不同的市场，那么需要使用了解那个市场的人。但是我忍住了。
生意
和互联网公司做生意的方式应该和传统IT公司不同，我猜。我们把产品卖给AT&T，或者工商银行，销售人员需要连接的对象一般是IT部门及其下属的网络部门，系统工程师和网络工程师（JNCIE，CCIE们）会在其中参与决策。但是卖同样的产品给互联网公司，参与决策的可能是开发部门，devops会参与决策。这两类人完全不同，需求也完全不一样。
我们看如今IT人员角色的变迁 —— 首先是QA在往SDET（Software develop engineer for Test）上迁移；随后是IT admin往devops上迁移；不久的将来，也许会是Network admin往devops上迁移。devops替换IT admin在若干人需要管理成千上万的服务器，而传统的IT admin无法scale的背景下；那么devops替换network admin也很可能发生在类似的场景下。
今后要把设备卖给互联网公司，很可能sales打个前站，然后就是developer与developer（devops）间的交谈。这两类人之间交流没有障碍。甚至，随后的服务（售后），也会出现developer与developer的交流，因为对方需要了解api调用的细节，以及使用过程中出现的各种api调用问题。
