这是去年年初的总结邮件；希望看到一些改变。
每年底我都会总结这一年，做了什么事情，是否有价值；技术是否解决实际问题，带来业务价值；是否能跟上现在的技术潮流。
下面是这一年我看到技术圈的变化，和我自己的技术经历；总结我看到和想到的一些变化和方向。
我擅长的技术一直都是基础设施领域，在这个领域经历过创业、小中型和大型公司；从物理机到虚拟机，再到云和k8s。
我理解的基础设施，不只是服务器管理；是各种云（AWS，阿里云，腾讯云等）背后的或者说业务层面以下的各种技术和服务。
基础设施领域是个高度开源和技术主导的领域；基础设施越强大，业务的扩展性和灵活性越强。越能跳出资源的限制，业务越能从摘取低垂果实去攀登更高的业务价值。基础设施领域任何创新可能会带来业务层的蝴蝶效应。
再说下专注的技术方向是容器和k8s；k8s被称为云操作系统，是基础设施的基础。之前在一家初创公司，公司花费将近半年时间的技术开发；构建一个商业管理平台，后来越做越像k8s，最后废弃这个项目，开发能力转向k8s。一家初创公司，花费大量人力尝试后转向k8s；到现在k8s开发维持着个庞大团队。k8s是未来，也是现在。
总结和归纳了几点。
对基础设施的认识需要更新
基础设施决定上层建筑。容器自docker从2013年开始，短短六年改变业界，进入容器时代；在基础设施领域，如果没有普适性，任何设施很难有这儿快的传导性。 微服务架构的流行无不因为k8s这样的基础设施存在。
容器实现资源的可定制性，k8s实现基础实施即代码；现在说的比较火的云原生，技术上就是所有的一切在云和k8s内完成，完全脱离具体的物理资源。Infrastructure as Code（基础设施即代码）。
在k8s之前，大部分公司不会围绕基础设施来开发；基础设施领域都是自己玩自己的，构建发布系统、发布流程管理系统、作业系统、配置管理系统、系统初始化管理系统、资源管理系统等各种系统；这些方式在容器时代不能满足高度自动化智能化微服务化的业务需求。
这两三年大部分互联网公司内部都在建设自己的技术平台（或者是技术中台）；都是利用k8s，实现业务和基础设施之间的耦合。
基础设施和开发框架融合
和开发框架结合是未来趋势；业务层专注在业务逻辑本身上，不再受限于基础设施。
基础设施来完成横向和纵向等各种个性化资源扩展。就是业务层不再感知基础设施层，基础设施层通过自身数据和框架数据来调度业务层。
我之前所在的腾讯互娱部门关于基础设施和框架层的变迁；腾讯互娱两个基础部门都是上千人；一个负责传统基础设施领域；一个负责框架层面；在2017年两个部门合并；业务层之下的能力进行统一。
Services Mesh和Serviceless是现在业界的方向。
Services Mesh，即服务网格；通过在容器内添加一个代理容器，把业务的网络调用从代码里面抽离出来，通过基础设施来完成。这个代理容器即可以看做基础设施，也可以看做框架。
Serviceless，即无服务架构；云函数（FaaS)等；业务的逻辑函数和框架分离，框架和基础设施融合；用户的请求先到框架层，框架统一来路由，分配资源。
基础设施的专业度越来越高
基础设施领域技术含量越来越高，技能越来越专业化。从云开始，基础设施不再单单管理服务器，单点问题不再是业务和资源的痛点。
对应的高可用、高并发、大数据、自动化、智能化、AI化的相关技术方案，都是在基础设施领域。围绕着这些技术方案的使用、开发和维护技能都是极度专业化。
基础设施的完善度越高，业务的花在基础设施的时间越短，自由度越高。
云化，集中化；规模优势
云开始之后，集中化才能体现技术和规模优势。基础设施不是大力出奇迹的地方，只有不断迭代的结合业务特性才能做出适合公司不同时期需求的技术平台。
反面例子是腾讯；赛马机制的业务主导下，导致技术建设严重滞后。
开源
开源才是未来；尤其是云和容器时代，大部分的解决方案都需要配套设施，而依赖的配套设施，一般是另外的开源方案。大部分的开源软件版本迭代快。版本和功能大部分采用逐步迭代支持，而不是之前的买断性方式。依托在开源生态的商业软件大多采用锁定支持版本，更新一般不及时。
现在有些激进的开源基础组件，不再提供部署包，只提供容器部署和使用方式。
k8s的技术圈子是高度开源和开放的；每家公司会在各种技术大会上分享自家的技术方案，但是每家的业务形态不一样，建设思路不一样。业界已经形成技术循环，分享==》借鉴==》引进开发==》再分享。
招聘
k8s在2017年才成为容器编排的事实标准。围绕k8s建设技术中台的大部分公司的相关部门，一般是建设阶段，人员都是扩编状态；对这个领域的人才渴求都是非常强烈。
大部分公司对人才的要求大都只是本科，无学校和名企要求；招人难度大。
Ps，从侧面说下，如果招聘时说我们是微服务，敏捷开发；业务都在容器里面跑，面试者会对公司加分。
