25 | 为什么蘑菇街会选择上云？是被动选择还是主动出击？
我们所面临的问题
- 成本闲置问题
大促，需要业务系统有足够的容量支持，浪费机柜成本和人工投入。 - 基础设施维护问题
IDC机房选址，IDC机房的扩展问题，资源利用率问题 - 底层技术投入和人才的问题
越是底层的技术，技术门槛就越高、更复杂，也越离不开高端人才的投入。
以业务发展为生命线的公司，我们更期望能够在业务上取得创新和发展，而不是在技术上取得多么非凡的成就（这一点和公司的发展诉求是不一致的）。所以这就从根本上决定了，我们不会无限度地投入，或投入非常大的成本在这些基础技术的研究上。
纵观技术发展趋势
-
从软件架构发展的趋势上看
软件架构：单体结构——分层架构——微服务
资源粒度：物理机——虚拟机——容器
开发模式：瀑布模式——敏捷模式——DevOps
发布部署：停机变更——热部署——持续交付如果想要技术为业务带来更多的可能性，拥抱云计算是最好的选择。
-
人工智能对云计算能力的释放
未来人工智能的发展和应用，必然会依托于云计算
没有银弹
软件工程中，我们一直在讲，没有银弹。虽然公有云解决了很多问题，但是，就目前这个阶段来讲，如果想要获得较高的客户满意度，仍又很长的路要走，比如不同形态业务的差异化支持和服务问题。
26 | 为什么混合云是未来云计算的主流形态？
关于混合云
在选择上云的过程中，就需要有个过渡过程，这个过程就是混合云需求存在的应用场景。
我们所经历的几个基础设施建设阶段
- 第一个阶段，完全托管IDC模式
- 第二个阶段，资源短期租赁模式
- 第三个阶段，同城混合云模式
- 第四个阶段，公有云体系内混合云模式
27 | Spring Cloud: 面向应用层的云架构解决方案。
Spring Cloud框架中云的影子
Spring Cloud不仅仅是微服务治理解决方案，它同时还是面向应用层的云架构解决方案。
CNCF
云原生
可以预见的技术发展趋势
跟业务无直接关系且相对通用的技术在不断被标准化，而且标准化层面越来越高。
技术每被标准化一层，原来繁琐低效的工作就少一些，技术标准化的层面越高，技术门槛就会变得越低。我们可以作个大胆的预想：或许未来真的只会有业务解决方案和业务代码。
对于我们技术人来说：未来更多更迫切的能力需求将会是：如何利用好业界已有的丰富的技术产品和平台，在面对更加丰富多样且复杂的业务领域需求时，能够更加专注于寻求业界解决方案，以更好地将业务和技术连接起来。找到适合业务解决方案的技术并落地实现，而不再只是专注于技术层面的造轮子。
对于运维来说，我们同样要了解技术发展趋势。虽然我们不会直接参与具体的业务解决方案和代码的开发，但是，如果架构师是业务架构的设计者，那么我们应该成为技术架构的管理者，从效率、成本、稳定性这几个方面来检验架构是否合理，并为架构朝着更加健康的方向发展保驾护航。这也是运维职能转型和思路转变的一个重要方向。
摘自评论：从技术实现角度，解决方案和思路都是很多成熟的东西可借鉴的，但是落地具体业务时是需要做大量适配的，包括后期的技术运营，这个工作只会越来越多。
28 | 以绝对优势立足：从CDN和云存储来聊聊云生态的崛起
云生态的优势
随着公有云的深入发展，特别是公有云巨头的飞速进步，公有云形成了自由的、独特的生态体系。
这不仅仅体现在技术和产品层面，而且可以预见其最终还会形成商业层面的体系闭环。
所以，利用云计算的优势，拥抱变化，才能够为我们的业务发展和创新带来更多的可能性。
29 | 量体裁衣方得最优解：聊聊页面静态化架构和二级CDN建设
页面静态化架构
ATS开源解决方案
关键技术点：
动静态分离，动态数据获取，失效机制
公有云也好，云计算也好，都不能为我们提供完美的定制解决方案。正所谓具体问题具体分析，找出问题，优化解决路径，量体裁衣，才能得到最适合我们的“定制方案”。
30 | 云计算时代，我们所说的弹性伸缩，弹的到底是什么？
弹性伸缩的主体是谁？
弹性伸缩其实是一个运维场景，但是我们并没有定义这个场景的主题是谁。
- 服务器的弹性伸缩
- 应用的弹性伸缩
- 业务的弹性伸缩
我们在日常思考和工作开展中应该注意以下两点：
第一，一定是从实际问题出发，找到问题的主体，然后才是针对问题的解决方案。
第二，如果问题处于初期，且是发散状态时，主体可能表现出很多个，这时我们一定要找到最本质的那一个，往往这个主体所涉及的运维场景就包括了其他主体的场景。
独立思考和分析的能力很重要，意识也很重要，切忌不可人云亦云随大流，反而迷失了工作的方向。