微服务、容器和DevOps的关系
- 微服务只是一种设计思路，或者说他给出了如何用正确的方法来进行SOA的实施。理论上来讲他的确和DevOps没什么关系，但是从如何实践DevOps的角度来讲，微服务是非常有意义的。此外，随着诸如Spring Cloud以及微软Fabric等SDK的完善，微服务开发模式也逐步完善，实现了概念的落地。
- Docker可谓是一种敏捷化的虚拟化技术（较之虚拟机而言）。其实微软Fabric或者CloudFoundry也都脱离开容器的概念提供了微服务开发的解决方案，所以这两者并不是强绑定的关系。但是容器用不可变配置架构实现了微服务从开发到运维的质量保真度，这恰好解决了粒度小，数量多的微服务所带来的运维难题。再加上K8S，Swarm等容器云的支持，docker容器已经形成了事实上的标准。
如何利用这个强大的运行环境帮助企业敏捷，推进业务数字化，并且加快业务的投产？ DevOps为上面所说的开发模式提供了软件生产线。
所以总结的来讲，企业业务敏捷是DevOps发展的直接推动力，容器云，以及微服务为DevOps提供了技术可行性。而敏捷帮助提高DevOps工作效能。
对于团队的拆分，这个问题真的要结合产品规模来看。团队的拆分有很多办法，贝索斯说的two pizza team，是建议一个团队中的人尽可能少，不要超过两个Pizza能吃饱的规模。用敏捷实践来讲，可以分为多个特性团队，以及维护团队，不同的团队各司其职，合理分工。在我以前的实践中，三个人可以做一个Feature，来交付一个月迭代的工作量。
当然将原有的巨石应用分割成更小的微服务是挑战很大的事情。因为理论上的微服务的设计对现有的团队组织结构，以及工程师设计能力都带来了一定的挑战。有些组织按照DDD（领域驱动的设计）的方式去实践微服务，会发现以前一个应用的复杂度变得很高，对项目管理来讲也是一件头疼的事情。现在有个比较新的看法就是，大家宣称做微服务（MicroService）的时候，实际上做的是迷你服务（MiniService）。迷你服务的粒度较之微服务的粒度更粗一些，关注度由一个域Domain，变成了能力。一个迷你服务提供一种能力，这种能力的提供也许是跨越多个域的。
最好的方法是以一个团队能承担的任务划定微服务的界限比较好，这样以来，不论是任务管理，代码构建，产品部署都会比较好做。
更关注服务的能力，这样也会减少因为跨域而带来的复杂事物处理。
