现在做云计算的出路到底在哪？

小弟不才。勿以为代码就是为了求生而已。
我现在做云计算。主要是golang和kubernetes。也有两个kubernetes commit，但是现在这种paas层的云计算真的有出路吗？我看到跳槽几乎没有啥公司也是做这个的（以前是做java的）。但又不太想回去做java。那么问题就来了：
1.所谓的风口到底是啥。
2.这个方向薪资能到怎样的水平。
3.为啥我总觉得我还没我家楼下卖烧烤的人赚得多。还比他们累。
4.iaas层需要去了解多少

看了你的问题你把golang和k8s并列在一起说，作为你云计算的主要工作，基本可以确定你没有在做云计算。或者你对云计算的理解是不正确的。云计算的前世今生，云计算要怎么学？和计算机专业有什么关系？
云计算和传统数据中心的需求没什么区别。主要区别在于传统数据中心因为啥都是手工的，所以所有手工的工作已经都忙不过来了，所以先进技术采用的少一些。云计算上因为大多数东西都自动化了，所以先进技术采用的多一些。但总需求没什么太大的变化，基本理论参照ITIL。

• IAAS/PAAS云计算的风口已经过了，没什么新玩儿家了，后面就是这些已经存在的玩儿家竞争。SaaS从来就不是什么云计算，就是在线软件换个马甲而已。对于个人来说，懂云计算可以成为Infra Architect，这种人市场上永远需要，不管你是搞数据中心的还是搞IAAS的。
  
• 薪资方面还是挺高的。不同地区不同市场不一样，看你在哪儿。另外今年国内的形势比较严峻，很难说能找到啥薪资。等市场好一些再说。海外市场形势也不太好，但只要能找到相关工作，薪资并没有降。
  
• 卖烧烤卖的好的真的比搞云计算的赚的多。中国人这些年的工作分层方式基本上让白领工作者歧视蓝领工作者。这个在发达国家不怎么存在，很多蓝领工作者比白领工作者收入高。做生意的人收入几乎一定比打工的多。
  
• 你问出这个问题说明你对K8s了解甚少。虽然你有两个commit，但估计都是解决具体问题的，而你对K8s的总体架构还不是特别理解。基本上你要是能玩儿转K8s的话，你玩儿云计算应该问题不大了，触类旁通。至于需要了解多少，看工种。我见过只懂操作系统管理的云计算工程师，这种人天天干云计算，但实际上就是个系统管理员。想做云计算架构师的话和传统数据中心架构师没啥太大区别。
  

1、编程只是技能的基本手段，假如需要往高级方向发展，那么要跳出写代码这个境界，要熟知架构（特别是使用架构、体系架构），而 PaaS 表面上是解决什么主动运维问题、开发问题，其实践背后，解决的是架构问题、工程问题，假如你到 PaaS 有满足的了解，那么 PaaS 会触及技能的方方面面，对个人在技能领域提高是很大的。
2、云计算的根底层都是在企图解决大规模资源管理，数据中心（网络、存储、计算..）都是为最理想的基建形式，假如有幸深入了解或这些细节，那么运维能力在业界也是排在前列的。


3.云计算的使用层一应俱全，需要承载不同的使用在平台上运行，开发者也有机会接触到使用层，乃至能够深入场景，深入事务帮助客户更好地去上云，只需经历了几个客户使用的迁移上云，那么在使用层的整体了解，SaaS 层的了解也会上一台阶。
4、参考 《Gartner：2018 年十大战略科技发展趋势》（不明白Gartner的自己脑补），几乎一切未来科技趋势都和云计算有关，乃至都要依托云计算。


我很难找出云计算这个行业不好的原因，而对于题主的建议是，跳出编程的视野，多站在架构和事务的调度看问题，否则就算让你研发航母你也一样困惑，越是大工程大项目分工越细，仅仅把自己定义在编程的视界里，都是很难找到成就感的，同样的建议合适任何岗位的人，格局决议成就。
楼主如果想要学习云计算运维这方面的知识的话可以点击下方的卡片领取一份免费的学习资料哦！
ICT网工_云计算学习认证资料（免费）

云计算的就业前途，某种意义上也可以理解为云计算为我们提供的服务，存在一定的必然性，也就是说云计算对于社会、云计算使用者有哪些优势，也同时可以理解为，云计算的优势就是云计算的就业优势。
关于“云计算”带给我们生活的改变已经深深植入到我们生活中的点点滴滴，每一天我们浏览的手机APP或着网站，基本都已经离不开“云计算”作为背后的强大服务支持，像很多购物网站和社交软件一样，改变着我们的生活。这种改变不仅仅改变的是平常百姓生活，越来越多的企业开始使用基于云的企业服务，生活因“云计算”正在发生着革命性的变革和改变！
另外云计算的工资并不低，你可以参考下我学生的薪资看看，都是最近就业的：

本文转载自世民谈云计算，观点出自世民老师，以做参考。
0.被讨论的场景
一个传统企业，之前养过一个研发团队搞基于开源项目的云平台（比如OpenStack，Kubernetes 和Ceph），或者从一家小公司采购进来一个云平台。不巧，因为各种原因，自己的研发团队没了，或者外部的小公司倒闭了。那么，现在这个云平台该怎么处理呢？如果时光倒流，允许从头来过，这种结局有办法能够避免吗？
1.关于这个问题的讨论和结论

1.1 怎么处理？

处理方式不外乎以下几种：

• 重新搞研发团队。这办法说起来简单做起来很难。
  
  
  
  • 一来团队散了再要重建的话，所付出的代价比当初养团队要高很多。
    
  • 二来要养一个搞定这三个或其中一两个开源项目的开发团队，估计至少得5个人。光人力成本，一年估计得200万。另外小团队的稳定性一贯是个大问题，少了一个人，那就缺了一块，然后又很难招进来合适的人补上。
    
  
  
• 自己搞运维团队，如果代码有问题搞不定则找外面能提供服务的供应商。其实这就是自己组建L1团队，花钱从外面买L2和L3团队的服务。这应该是比较靠谱的做法。毕竟运维人员一般要比研发人员成本低不少，而且随着开源项目越来越稳定，并没有那么多的代码上的问题。但是这有几个前提条件：
  
  
  
  • 运维团队具有一定的能力，运维问题都能搞定。如果搞不定，甚至还要买L1运维服务。
    
  • 如果运维团队里面有一两个人有一定的代码能力（如果出现bug，能定位到代码位置，并能从社区找到fix，然后更新平台），那基本上从外面找L3服务就差不多了。
    
  • 如果平台源代码是私有的，或者供应商基于开源项目做了大量定制，那么从外面找 L2 和 L3 服务供应商都非常难。此时得考虑迁移。
    
  
  
• 将平台迁移到新平台。这里面有很多问题需要考虑：
  
  
  
  • 选择什么样的新平台？这个问题就又回到了下面 1.2 部分。
    
  • 迁移成本多高？之前听说过有客户是这么干的。基于一个小供应商的某平台经常出故障，小供应商后来没了，不得不迁移到一家大厂的产品。这过程非常折腾，代价很大。
    
  
  

1.2 怎么避免？

如果时光倒回去，假设你是做决策的人，要怎么避免这个结局呢？也许可从以下几个方向进行考虑：

• 对于基础架构（iaas平台、paas平台、分布式存储、数据库等），采用偏保守策略，找大厂的成熟产品。一来产品成熟，运维压力不会太大；二来出现了代码级问题，由大厂来解决；三来出了问题可以找大厂背锅。这种产品其实可以分为两大类：
  
  
  
  • 大厂的私有云平台。此时企业需要有自己的平台运维团队，同时需要大厂提供代码级支持。当然了，有钱的单位可以直接购买驻场运维，但也会带来很多问题。
    
  • 大厂的公有云平台。其实企业只需要应用运维，云平台由公有云厂商搞定。　　
    
  
  
• 对于非关键业务环境（比如开发测试环境）或者管理平台（比如CMP），以及辅助系统（比如监控和日志系统），可以自己团队基于开源项目搞定。一来这些东西不处于核心的数据平面上，因此即使出了问题也影响不会太大；二来可以锻炼团队；三来可以根据自己的需求进行适当的定制。
  
• 如果不想或者不能或没钱找大厂供应商，那最好能做到以下几点：
  
  
  
  • 供应商的产品的核心代码是基于开源项目的，或者只有少量定制。
    
  • 拿到源代码，指不定关键时候有人能看懂还能改改。
    
  • 借助供应商，培养出自己的运维团队，其中有几个人具有一定的代码能力。
    
  
  

2. 传统企业如何决策基础架构平台？

决策过程要考虑很多因素，其中一个关键步骤是区分业务环境：

• 运行核心业务系统的生产环境：建议找大厂的成熟产品。对于这部分，稳定，有支持团队，成本应该是三个主要的考量角度。
  
• 运行非关键系统的生产环境：可以找外面创业公司的产品。对于这部分，成本，新技术应该是主要的考量角度。一方面也支持创业公司和行业的发展；另一方面比自己搞时间和成本都要短一些。
  
• 非生产环境，比如开发测试环境：可以自己团队搞，一方面锻炼团队，另一方面也节省成本。对于这部分，成本，新技术，培养团队应该是主要的考量角度。
  

3. 其它一些讨论到的东西

3.1 对传统企业来说比较合适的云平台架构是啥样子？

下图也许是一个比较合适传统企业的架构：




3.2 对基于开源项目做产品化的公司说的几句话

1. 如果是创业公司，你要说服或者替客户想到避免厂商锁定问题，那么就要在核心组件上尽量和社区保持同步。要么直接使用社区的，如果自己有定制的话，那就同步到社区。
2. 看国外公司是如何基于开源项目做产品的，OpenShift 和 Rancher 是两个挺好的例子。国内很多客户也挺有意思，一定要看供应商在核心组件上做了多少改动，美其名曰优化，其实最后被坑的往往还是客户自己。
3. 让产品架构尽量保持简单，不是越复杂越好。因此，我们不太看好各种 『什么On什么』这种架构，比如 K8S on OpenStack，OpenStack on K8S 等。因为想着运维压力就头大。
4. 如果是大厂（比如华为华三这种），可以有定制，用户也能接受，因为客户相信大厂有能力给客户提供长期支持，厂商锁定就锁定吧。
3.3 MSP 会越来越显现出其价值和重要性

1. 随着公有云越来越广泛地被企业用户所接纳，那上云、架构设计、运维、安全等需求将会越来越多，这是MSP的业务范围。
2. 企业中会出现越来越多的没人管或没人能管得了的基础架构平台，MSP 有实力的话提供开源平台的 L2 甚至 L3 运维服务的话，将会有客户找上门。
3. 随着混合云的逐步推广，网络和安全将变得越来越复杂和重要，而这两个东西门槛又非常高，正好这是MSP的业务范围之一。
3.4 VMware vSphere 中短期内无法被替代

VMware这5年的股价变化还是能说明很多问题的：




VMware vSphere 真是功能丰富、强大、稳定、可靠，还能在购买许可证上想想办法打打折。
现在还有CMP，对外提供自服务界面和API，分分钟将虚拟化环境改造为（类似）云环境。
AWS都和VMware 合作得那么紧密了，其价值对于AWS 来说显而易见。对用户来说，本地VMware 环境连上云上VMware 环境，那用户体验还是相当爽的。
但是需求会逐步下降也是事实，毕竟非关键业务系统会被分流出去，新业务系统部分会才用公有云等。只是着在它的领地内，其价值短期内无法被替代。
3.5 对开源社区想说的几句话

1. 多关注企业用户的需求，不要只顾埋头写代码了。一直认为开源社区应该有产品经理。当然了，有人说开源社区做的是开源项目，不是做产品的。如果只是玩技术，那结果很可能就是自己玩得嗨，用户最多把你的东西放在边缘环境或政绩项目上。
2. 更加关注核心模块稳定性，一开始就提供稳定可靠的核心模块，从而减少二次定制的需求。不要只想着做大，做大和做强差别非常大，做大容易把自己做死。
3. 教育好利用你们的开源项目做产品的创业公司，他们该往什么方向做，该如何和社区分工与配合，如何帮助落地到用户的数据中心等。
4. 对多长时间后能进企业的核心生产环境要更加现实点。
3.6 对公有云供应商说的几句话

1. 多关注传统企业吧，他们才是你们未来客户的主力军，不要成天只宣传上亿并发和秒杀了，这些东西传统企业用不上估计也懂不了。他们更加关注的是稳定性、数据安全性、跟他们自己的数据中心打通、迁移成本、是否要改应用架构才能上云、现有运维人员能够做得了运维、成本、能否跟现有运营平台整合等问题。
2. AWS 把 VMware 拉在一起合作，把 VMware 环境搬到他们的公有云和私有云上，推出 Outposts，这些是真正关注传统企业的举措。AWS + VMware 其实也可以类比为 CMP + vSphere。
3. 真正的『以用户为中心』，是要时刻想着用户的需求，不管自己之前说过什么（AWS 之前说私有云不是云，只有公有云才是，言外之意VMware更不是云）。现在用户需要什么，那就提供什么。
3.7 对传统企业说的几句话

1. 云可以有多种形式，OpenStack 是云，VMware + CMP 也可以看做云，（私有云其实严格来说不是云，至少它缺乏云应有的规模性和弹性），公有云也是云。
2. 上云不只是资源上云，上云更是一种理念。如果只是把应用从物理机上迁移到虚拟机上，这并不叫上云。上云至少还包括开发上云（面向云开发，DevOps，CICD等）、应用云化（面向云制定应用的云上架构并进行部署）、数据上云（基于数据整合的大数据分析）等。
3. 在做云平台决策的时候，首先要做的是对自己的业务进行分级，多少核心业务系统，多少非关键生产系统，多少开发环境等，然后确定不同的需求。不要只是追求大而全。大，往往和重、复杂、变化难、问题定位难等毛病联系在一起。
4. 在做云平台决策的时候，想想做云平台的团队（自己的或第三方的）将来要是撂挑子不干了那要怎么办，谁来收拾局面。如果确定了做云的人，不管是自己人还是外面的厂商，就对他们好点，把他们当合作伙伴对待，因为他们是你出问题的时候救你命的人。
5. 算成本的时候，把养研发团队、运维团队、厂商支持服务的成本也一并算上。
6. 打算养研发团队自己做云平台的时候要想清楚，是在基础架构层定制呢还是在管控层面定制，是不是一定要私有云，是不是能上公有云，团队稳定性和成本如何，如果几年后团队不在了该怎么办。
3.8 对云开发和运维人员说几句话

1. 云底层开发将来更多的会存在于大厂那里。小的云团队更多依赖于开源社区，只有大厂才会有实力和业务需求养大的基础架构研发团队，这样的团队成员才有机会做真正的底层技术研发。
2. 每个云的用户都会需要运维人员，不管是什么样的客户，连公有云的用户也需求运维。将来能看懂开源项目代码并能修补一些简单bug的运维人员会更有市场需求。
3. 云运维人员要面向云运维，以云的理念做运维，能让自动化工具干的事情就不要人肉做。即使现在做的是传统运维，有时间的时候，去考个AWS云架构师和云运维专家认证，会很有价值。
4. 面向业务运维，而不是面向资源运维。时刻想着从业务出发，不要一直盯着那点资源。
3.9 容器云在传统企业落地任重道远

1. 要用容器云，要改动太多东西，应用架构、部署模式、研发流程、运维模式、惯性思维等等；
2. 传统企业的互联网应用最好先看看是否合适公有云。
3. 我们还是觉得容器云先让开发团队用起来，让CI/CD跑起来比较好。
4. 想想虚拟机替代物理机用了多长时间，容器云在传统企业落地时间可能会比预想的长得多。

本文只是记录这次聊天的内容，仅仅代表我们几个人的个人观点，不针对任何行业和公司。
周末晚上闲聊几个关于云的话题

如果是做技术，且能在云计算领域，那么应该是一件很幸运的事，甚至是最幸运的技术之一。

主要原因有几点：
1、编程只是技术的基本手段，如果需要往高级方向发展，那么要跳出写代码这个境界，要熟知架构（特别是应用架构、系统架构），而 PaaS 表面上是解决什么自动运维问题、开发问题，其实际背后，解决的是架构问题、工程问题，如果你到 PaaS 有足够的了解，那么 PaaS 会涉及技术的方方面面，对个人在技术领域提升是很大的。

2、云计算的基础层都是在试图解决大规模资源管理，数据中心（网络、存储、计算..）都是为最理想的基建模式，如果有幸深入了解或运维这些细节，那么运维能力在业界也是排在前列的。

3、云计算的应用层包罗万象，需要承载不同的应用在平台上运行，开发者也有机会接触到应用层，甚至可以深入场景，深入业务帮助客户更好地去上云，只要经历了几个客户应用的迁移上云，那么在应用层的整体了解，SaaS 层的了解也会上一台阶。

4、参考 《Gartner：2018 年十大战略科技发展趋势》（不懂Gartner的自己脑补），几乎所有未来科技趋势都和云计算有关，甚至都要依靠云计算。

我很难找出云计算这个行业不好的原因，而对于题主的建议是，跳出编程的视野，多站在架构和业务的调度看问题，否则就算让你研发航母你也一样困惑，越是大工程大项目分工越细，仅仅把自己定义在编程的视界里，都是很难找到成就感的，同样的建议适合任何岗位的人，格局决定成就。