一、整体趋势
天下大势，分久必合合久必分。复杂有复杂的代价，简单有简单的代价。
看这些年的发展，也能看出一定的端倪：
单体应用【一统天下】-》业务复杂后，应用拆分【应用拆分】-》SOA、ESB【接口拆分聚合】-》微服务【服务拆分】-》中台【业务聚合】-》去中台【业务不要瞎聚合，再拆回去】
微服务的简单，其实是将服务功能单一化，确实降低了编码及编码维护难度，也是有很高的代价的。我们不仅要享受简单，也要知道其代价。最直观的几个代价有：
1、需要很高的代价去打造适合自己的微服务治理体系
2、由于需要解决单点问题，每个服务要部署多个实例即使用量达不到也要备着
3、运维复杂度上升，需要工具支持，对人员要求也更高；
4、微服务的调用链，比单体应用的调用链，复杂，效率低，排错难；
使用微服务，对运维能力是有一定要求的，而且非所有软件都应该走微服务的路子。盲目的微服务化，服务拆分过细的结果，往往是又合了回来。
究其原因，人对复杂事务的掌握是很有局限性的，所以我们倾向于将复杂问题分解为简单问题，将问题标准化，然后解决问题。整个人类社会都是这样，才会有社会专业分工。但分工又不能太细，这样才能恰到好处的发挥人的创造力。最终都是多种因素折中的结果。
无论是软件开发，还是CPU制造，还是工厂制造商品，还是粮食的生产，原理是相似的。
二、单体程序还是微服务
个人认为，以后的发展趋势是单体系统、微服务架构，会相互学习相互补足。
很多典型的单体系统如操作系统、数据库、中间件如MQ等，在内部设计时也会根据功能进行拆分模块，并不会全部放到一起实现，会尽力降低某一部分出错后导致的后果；同时在分布式环境下，也会给出自己不错的答案。
而微服务正相反，其本身确实是降低了开放的难度，提升了开放效率，隔离做的很好。但同时要看到，微服务将不少工作扔给了运维，没有强力的运维，微服务拆的越细，最后死的也是越难看。所以在微服务化的过程中，很多项目都是拆细了又合并回来，接受了单体组建的风险，避免了运维工作的指数型增长。
单体程序的问题在于，单体应用如果太复杂了，人是很难考虑到各个环节的，需要用更复杂的手段，来进行保证，如火箭、飞机、航母，这些复杂的软硬件一体的开放工作，需要额外的系统及理论及代价去确保系统的可靠性。而且单体系统最长见的一个问题就是，单体系统的稳定性，小于单体系统中最差部分的稳定性，在很多没有良好管控的软件项目上，单体系统的稳定性，其实就是最差的那段代码决定的。人员水平不足，项目经验不足，人力不足，时间不足，是不是和你的项目很像？这种情况下，复杂的单体系统难以高效稳定的发展。
微服务，通过各种拆分隔离解决的这个问题，但同时在运维的维度引入了新的复杂度。每个项目都应该在单体服务稳定性与运维复杂度、资源耗费之间，取得一个平衡。孰优孰劣，应该按项目来确定，而不是一棍子打死。
此外，单片机给人的感觉是单体吧，但加个设备网关，搞个IoT不香么？
同样，各种复杂的操作，云平台给你封装好了，应用只需要找平台要这要那，对于应用来说，平台把内部实现封成了黑盒子，一定意义上说不是单体么？
三、SOA为何衰败
SOA的想做的事情，方向是对的，到今天，很多思想都在落地。
但那种“干这种改变世界的事情，老子要发明一套让所有人看起来都高大上的技术才行”的想法，让SOA过于复杂。
反而不如务实，用尽了少的代价让想法落地。
不应该为了解决简单的问题，一开始就弄一巨复杂的规范，SOA如此，EJB也是如此。
重点没有去解决问题，而是为了规范而去制定规范。甚至为了制定规范，还要发明一堆名词，发明一种语言。
比如说，SOA什么都要管理，就需要发明WSDL来框定业务。WSDL根本就不是人类容易看懂的，而且十分严格。如果通讯双方namespace有个字母大小写不一致，通讯就失败，报错根本看不懂。查几个小时，发现就一个字母大小写问题。问题是你只想发个字符串过去啊。
成功的规范，往往是先落地用起来，然后一点一点长大的；先出一套巨复杂的规范，然后回去套业务，得到的不是惊喜，往往是惊吓。
四、微服务和DevOPS
一个微服务团队，从头到尾完全管理好自己的服务，其实是很难的一件事情。实际中，不少团队，微服务的技术用了不少，但DevOPS其实都没算做起来，仍然十分的依赖运维团队来完成很多工作，自建的微服务平台也不够好用，有了问题人仰马翻的。
感觉这个阶段，不如直接花钱买云厂商的服务，规避部分技术风险，重点发展业务，会更好一些。等有些技术积累了，再做适合自己的技术解决方案。
五、今天的云原生还有哪些主要矛盾，下一次软件架构的进化将会主要解决什么问题？
个人认为，当前的架构，还远远没有达到最优状态。真正最优的时候，绝大多数开发人员，是不需要知道K8S、ISTIO、Spring、数据库、缓存及各类中间件的存在的。
之前的状态是，硬件按硬件的思路发展，系统及虚拟化按其思路发展，应用架构也是按自己的思路发展。之所以当前需要发明很多新技术，是硬件、系统及虚拟化、应用架构彼此之间都有一条鸿沟，那大家就都需要自己造轮子搭梯子解决问题，统一问题必然有N中解法。后面相互磨合久了，鸿沟会进一步变窄，直至平滑过渡。
应用层开发人员，会在很大的技术视野内专注于业务层，其他层的需求只需要简单调用服务即可。
但不久的将来，一定会面临新的巨坑，需要填。
六、FAAS趋势
个人对FAAS有种直觉上的偏见，感觉有些走向了另一个极端：
1、如果保持F很简单，那平台确实可以直接将功能封装为通用服务，但就算加上DSL，F可以施展的空间感觉也不大
2、如果让F变复杂，支持复杂业务，那FAAS其实就退化成为了功能十分单一的微服务，还不如直接微服务来的爽快
整体感觉就是有些鸡肋，一边有纯图形化工具或标准服务，一边是正常程度的编码，夹在中间。
这个真的很像当年ESB的思维方式，给了一堆的标准组件，给人一看感觉封装的真好，不用编程也能做好多事情啊。但用过就知道，稍微复杂的业务就要自己去扩展组件了，不会编程什么都做不了。最后就是换了一个技术平台写代码而已。