前言今年是我毕业的第10个年头。中途成了前台，头衔一直是前台。你可以说我很敬业，有时候也有些遗憾。 一直以来，别人问你是做什么的，我说前台或者全店，别人说，哦，做页面的！心里难免有些失落。 前台是一个资源型的角色，由于在认知上对业务的理解不足，业务领域广泛，很难积累和沉淀。 如果你问一个毕业10年的JAVA老司机，他一定会和你聊大流量下的分布式架构，而前台可能昨天晚饭后还在讨论vue和反应，或者谁更好，有角？ 如何突围，如何提供更多的商业价值，前台一直在苦苦探索。 网上有很多激励人的文章，但是每个人面对的环境不同，负责的业务也不同，所以不同意适用于所有资本。 结合我这几年在阿里云前台的经历，做个总结。 今年是我在阿里云的第五个年头。我从来没有想过我会在一个公司呆这么久，我也从来没有想过我能在一个岗位上呆4、5年。 刚加入阿里云主机团队，主要负责云盾主机、drds主机等。在开发过程中，我发现大部分场景都是“形式”和“形式”。为了避免重复开发，我打包了simpleForm和console cli scaffold，可以一键敲定新的开发控制台(这个scaffold直到去年还在问怎么用...这也是持久的) 这个时候也萌发了做ide，在视觉上构建UI视图，但是受限于精力和当时团队的方向。那时候vscode还没有今天这么普及，所以我没有尝试，很遗憾。 但是，做一个WebIDE是种在心里的。 因为后期组织架构调整，我从主机团队独立出来，负责当时的网站管理方向，从0-1组件团队开始艰难的过程。 当时业务比较简单，主要是:阿里云官网，官网的Nodejs和云市场业务。 因为angularjs主要用在主机团队，感觉上手成本很高。当我组建了一个新团队，有了自己的选择，React就成了我的首选。 当时的vue并不成熟，其实唯一的选择就是react。 新的技术体系需要一个配套的工程体系。当时Def还在1.0的时期。为了稳定和降低开发成本，我们很自然的在xef上开发了插件，分包了响应模板，并根据自己的业务特点定制了开发周期。 xef1.0更新2.0后，我们的工具不稳定，变化很大，渐渐的我们的工程系统独立出来，也就导致了后来的DBL(当时称之为“牛逼”)。 我给老板做报告的时候，他觉得这个名字不雅观，只是憋了一个更有意义的名字——真的很难记，现在也记不住了。 这个阶段我们做了很多技术上的尝试，团队成员都很努力，很有激情。 我们一直在优化团队的基础装备建设。有了曙光基于中间件的流水线设计，可以说工程会更上一层楼。不管以后更新多少webpack或者出现新的打包工具，对我们的影响都不大。 面向未来的模式，姑且只修改内核，用户无感知。 新的工程方案也主动与阿里云的其余团队进行沟通和交流。此前与风驰、信实达成协议，将其作为阿里云的统一建设工具进行推广，但并没有很好的落地。 同时，新方案也完全遵循集团的标准，与淘宝Ada团队无缝对接。 另一个好处是，dawn不局限于react，可以使用任何框架；Dawn不局限于redux，你可以使用任何你喜欢的数据管理。其实我们有mota，mobx，graphql-apollo等等。 黎明连线:阿里巴巴/黎明做完工程后，其实要谈组件化，这是一个无法回避的问题，但对我们来说也是一个艰难的过程。 15年我们用了antd(开源)，但是在上层做了一层业务封装；后来，fusion开始流行。和ued沟通后，考虑到组统一，融合(开源)花了一些时间；最后我们选择自建组件库，这是很无奈的举动。 其中一个重要原因就是我们的前端业务需要“阿里云自己的设计元素”。经过长时间的团队建设，APS组件库一直作为团队建设库的基础，在其上搭建业务组件，搭建业务处理解决方案。 除了折腾传统的前台领域，我还尝试做了很多跨栈的事情。 在我负责的业务中，因为“端”业务是实实在在的，所以我们更倾向于“全栈” 前台同学做全栈，说实话还不够——大部分前台同学在架构、运维部署方面的经验还是比较少的，他们更关心的是展示层。 在全栈路径上，因为我们负责核心事务环节，所以没有使用大家熟悉的nodejs，而是选择了与后台相同的语言——Java。 这个决定其实挺难的，也有故事。 原价有一个系统，是前台同学用Nodejs写的。但是因为业务很复杂，而且前台一直是资源瓶颈，一个人做三个人的工作，所以这位同学最后处理不过来，离职了。 这样的系统就变成了后台想接却接不了，前台“无人力”接的情况，非常尴尬。 此后，业务系统决定直接使用Java。 在走向全栈的路上，我们主要有两种策略:Java，在大前台下自己写一些业务，通过代理的统一配置，使用serverless转移到大前台写Java。其实阿里云很多前台已经有这个能力了，我自己也有从0-1到线上独立开发几个系统，分布式部署，支持国际化的经验。 做了一段时间，发现效率其实不错，也不觉得nodejs比传说中的Java效率高多少。使用无服务器通过代理进行配置和改造，看到社区里有人提到Graphql有一段时间了，就产生了兴趣，顺便了解了一下。代理的方式可以把后台数据转换成前台要求的格式，很吸引人，于是我一头扎了进去。 同时做了Nodejs版本用于我团队的普及，做了demo的Java版本用于后台普及。 同时我了解到b2b的Mbox平台和我们想要的能力差不多，我就找他们做参考。但是因为整个业务系统都建立在他们的平台上，有一定的风险，所以我决定搭建自己的代理平台，这也是“云查询”平台的后台。 云查询主要由战争前线牵头，推广到地面，在团内获得了良好的影响力。很多BU部门都做了参考。 在业务上，通过云查询，实现应用的运营和部署，实现业务逻辑和接口的转换，自动扩容。 尤其是营销系统，在Yuance &与隐天、战锋的配合下，实现了比较大的效率提升，支持了去年阿里云的双十一。 具体的“云查询”文章详见我的另一篇文章。 经过长时间的发展，云查询逐渐成为一种基础能力，不同的“轻应用”在云查询的无服务器上生长，以支持不同的垂直业务场景。 比如:可视化构建领域“页面柜”、基于权限&角色的中后端处理方案“Flex”等。记得我之前说过，五年前我想做一个WebIde，但是没有开始；两年前看到其他云厂商有WebIDE，我们因为业务压力没有做出来。今年终于开始了一点，一直和appStudio的同学们一起搭建。基于appStudio，我们开放了我们的黎明和云查询，做了云集成和一站式的R&D体验。 通过以上的技术基础建设，为我们建立了良好的基础。 业务布局对应的是团队和组织的建设。 这几年团队从0-1到xx在职学员，形成了四个梯队，三个三个业务方向&一个技术框架方向，一路走来，感觉集团的管理很深。很多时候并不是说带的人越多越好。最近看了一本书，里面提到了一个词“情感成熟”，很重要。 一个技术好的专业人士不一定能管理好团队，他需要适应不同阶段不同角色的要求。最重要的是保持忧患意识，不断学习。 在团队建设中，需要区分管理者和领导者，尤其是业务团队。我们更愿意成为领导者，与他们一起做生意，而不仅仅是绩效管理。 2.0，也就是过去一年，在商业思维的指导下，我们拥有了一些业务，利用横向技术打通和横向商业思维，得到了少量的成果。接下来进入2.02.0商业思维——从横向角度推动商业赋能。我们通常把组织里的人分为:一字型、一字型、一字型、一T字型、一+字型。 前台只是一个工字型的团队，负责的业务范围很广，而且前台是一个非常稀缺的岗位，招聘起来非常困难，所以盘子越大，资源瓶颈越明显。 “线内”角色团队的典型问题是，它对业务的深度了解不够。单纯从技术层面来说，它做营销建设和中后端的可视化，效果并不理想。 这种情况下，你可能会觉得看不下去。天花板就在那里，如何突破可供参考的例子并不多。 我写这篇总结，就是因为一些这样的感悟，希望能给你一点输入，帮助你思考。 「一种字体」虽然我们在业务上深度不够，但是在专业技能上，我们是标准的“|字体”。 前台经过10年的发展，语言、框架、工具逐渐稳定，各种终端表现越来越流畅，生态非常活跃。我相信社区对你遇到的任何困难都有一个成熟的计划。 前台生态快速发展的10年也证明了我们这些人有非常强的学习能力。期望7天完成一个框架，3天完成一个数据库，并不是太难的事情(略显夸张，但确实是这个意思)。 前台直接对接用户，对用户体验的敏感，对流程数据的敏感，对业务逻辑流程的感知，是我们存在的根本，也是我们独有的能力，是我们不能失去的。 有一句话是这样说的:充满温情和情欲是不合适的。我们来对比一下。 在前台领域的深耕，让我们成为了“稀缺资源”。随着工具的改进，前台工作人员也希望利用技术为业务赋能。 如何赋能？站在我们面前的是“意识” 在营销中，“认知”是认知、需求、品牌、品类、价格五要素中最重要的。 比如阿里搞电子商务，腾讯搞社交，百度搞搜索。bat不断布局主营业务领域，构建庞大生态，做了很多尝试。不过，似乎最终围绕自身基因，生态投资的成功率会略高一些。 那么如果我们要商业赋能，瓶颈就在于“你切了页面”也要赋能？体验好，提高效率不好吗？我觉得“体验提升效率”是前台的核心能力，也是我们一生都在努力实现的目标。坦率地说，我们不能立即处理资源瓶颈。毕竟现在毕业生申请的都是算法，ai，人工智能。我们也无法制定一轮体验提升计划；这是一个漫长的过程。 但如果能从业务角度出发，找出问题所在，然后通过技术手段帮助处理，沉淀平台以满足未来不断变化的需求，可能会更实际一些。 TL作为一个团队，不仅在专业上给予学员“|”型的能力深度，更希望带着团队学员获得更多的商业感。 离开商业谈技术，谈中国台湾，都是空中楼阁；离开商务会谈的前台，注定是要反复造轮子的，而且这种低水平的重复正在发生，而且可能会持续很长时间。 长期以来，我试图将我们的“内联”业务范围进行概括和整合，希望将“点”变成“线”，进而形成整体的“面”解决方案。 我的业务主要有四个方向:官网&营销——针对长尾商业化流程后端——针对第二核心销售流程——核心能力层面销售、合作伙伴官网&营销:主要包括客户获取、激活、转化、留存几个节点，从而构建一个高效的“人”、“货”、“市场” 很长一段时间，阿里云的内容维护和营销推广都是基于集团的CMS。 传统的场地和卡牌推广方式，前台挖坑，管理编辑内容，和淘宝有很大区别。另外，我们没有一个招商选品的体系，导致这种简单的人肉推广操作方式存在很多弊端，比如效率低下、不可重用、无法个性化、对数据流监控不精确等。 另外“投放”能力建设不够，没有办法对精细化人群进行精准的营销内容投放。 为了解决这些问题，去年，前厅团队和pd共同努力，推动完善营销体系的构建:在原有商品的基础上，构建了“营销商品”的概念。 更一般的“货”，还有可视化的在线配置直接拉实时价格和库存。 通过我们1.0工具构建的曙光，开发流程打通，使得整个开发环节一致，成本更低。 一般商品可以搭配专门为商品打造的UI视图，形成场景能力的沉淀。 搭建ACE(阿里云体验)架构体系，打通建筑体系，通过技术降级打通各类“场”，更好的承载营销产品。 通过全链路场景的曝光、点击、转化，以及最终交易的商品信息等数据的积累，生成客户画像，提供内容场景方案(在不同场景下向客户精准展示商品或信息)，提升“人”的定位。 商品配置:上面提到“营销商品”的时候，就提到了“基础商品”。 目前，阿里云的基础商品主要分为“公有云商品”和“技术输出商品”。 过去很长一段时间，我们专注于公有云的能力建设，直到今年年初才逐渐融入专有云体系。 在商业化体系中，我们的二胎需要配置售卖规则和价格，定义商品型号；同时，复杂规范之间的约束极其复杂。 商业输入输出的强体验提升，我们还有很长的路要走。 结合今年专有云项目，从模板的方式出发，聚合一类产品，简化商品型号配置步骤，大幅提升配置效率和体验。 销售&合伙人:15年开始组建团队(这里指的都是前台团队，不是业务团队)。15-18.3年，大部分部门的核心kpi是营收，首次客户数，以中长尾用户为主，实现了非常高的市场增长。 后来，团队覆盖范围不断扩大，还负责销售&合作伙伴系统，围绕市场营销、商机培育、商机转化和合同履行建立了我们自己的销售crm系统。 ToC的业务通常比较好理解，毕竟我们也是c的一员。 这次toB经历，结合业务一号位的培训课程，让我们明白，销售体系的核心，除了工具，就是加工方案，这是产品能力的丰富性。 在详细描述了各个方向的业务后，让我们回到我们讨论的主题——借助横向优势和架构整合资源，提供业务授权 为了分析它们之间的共性，经过多次讨论，我们最终聚集起来，得到了我们业务流程的一个大图(外部脱敏后的意图):从这个大图来看，各分店最终需要依靠的是“销售能力”，具体体现在“弹窗购买”、购物车(多产品交叉购买、数据算法推荐)、套餐(多产品包装)的营销。CBM提供给大用户的产品配置清单、采购订单、CTO价格计算器体现在销售链条上，模板配置清单能力体现在商品商业化链条上。经过一段时间的资源消耗和耗时的烟囱开发，销售的核心支撑层——紫金阙被普遍认定。 这一层，定位为业务中台，在前台，也是大前台的领域范畴。 唯一需要指出的是，我们用的是Java而不是nodejs，没有其他区别。 最后架构如下(脱敏，忽略细节):在新的架构模式下，我们减少了很多前后台的沟通。比如“分销采购市场”用传统方式开发需要1-2个月，我们2周就完成了。 在可预见的未来，新的架构模型可以很好地支持各种新的营销方式，以及销售和合作伙伴的“解决方案”。 我想说的是，如果没有我们全方位业务的横向视角，我们的总体方案就不会这么通用，这是前台团队的优势。 没有大前台稳定的技术生态，我们是没有机会做业务赋能的。 这就是前台的未来。通过整合横向优势，结合某个领域，形成纵向深度，为业务提供价值，也让我们的技术解决方案“有的放矢”。 前台往往围绕一个点提出需求，得到工具，却因为没有业务属性而无法提供解决方案；只有结合业务特点，做好沉淀，把工具变成平台，才能释放更大的价值。 3.0探索用技术实力为业务增值。“云计算”的核心是处理企业成本问题，以低成本获得超强的计算和存储能力，获得高并发下的灵活扩展能力。 云计算提出了很多概念:IAAS、PAAS、SAAS。 与前台角色相比，身体感不是很强。 但是BAAS的出现让前台眼前一亮。 想想吧。原价需要大量后端开发的应用，逐渐沉淀成领域能力，提供baas服务给前台调用。前台不再需要考虑部署、运维，只关心业务代码。想想也是令人兴奋的。 目前市场上提供类似服务的公司有很多，如Leancloud、数据分析、消息推送等。 那么，Baas会是前台的春天吗？这个就拭目以待了。 扯理想，我们来说说现状。 目前阿里云大概是在阿里云买的。我们卖的是IAAS层的资源，客户的核心业务流程是基于自己的R&D系统。 在前台的深度领域，将基于云构建“基于云的一站式R&D流程”，企业前台将变成:在阿里云工作，或者在阿里云做Dev。 通过对企业前台生命周期的分解，整个流程通过WebIDE进行:1。拿代码2。dawn，阿里云前台搭建工具，与阿里云关联，作为基础搭建能力，定制中间件(webpack、lint、server、mock等。)和团队搭建的stage(init、dev、test、publish)；提供基于工程能力的统一规范，提供各种应用框架的初始化模板。 3.点击发布后，代码自动编译发布到cdn。 在这个基本流程的基础上，我们提供了无服务器相关的功能。通过调用BaaS域服务能力和FaaS网关触发能力，我们实际上可以成为一个完全一站式的应用开发，这是由前台主导的。 我还记得我之前提到过我们的无服务器应用“云查询”。在这个层面上，我们的能力逐渐下沉，成为无服务器的基础能力。 几乎每个公司都有一套营销体系。以前搭建的游戏玩法不够多样，主要是cms开发的。随着各种“端”能力的延伸和多样化，营销大楼变得越来越复杂。 我们基于“云查询”沉淀下来的“页面柜”搭建系统，借助“云一站式R&D流程”，可以提供很好的SAAS服务。 这是我们的优势，也只有我们适合这种“云前端处理解决方案”。这里只是一个场景，还有很多类似的机会。 我在前台领域做了几年，总结了一套前台学习的强化视频和学习路线。如果有对前台开发感兴趣的伙伴，不管你是想转行还是想做大学生或者想在工作中提升能力的web前台党，欢迎大家加入我的前台开发交流群:603985993。希望大家真诚交流！，与企业需求同步。 朋友在里面学习交流。大牛每天定时讲解前台技术！也可以关注我的微信微信官方账号:【前台学员】每天更新最新技术文章和干货。 总的来说，在无服务器前台的帮助下，云的春天已经到来。 抓住我们的核心竞争力，同时发现业务中的问题，并推动其向前跨越到底，才是最好的出路。 你要我做什么？我...我是阿里云CPO(首席Page Boy)