首先，让我简单介绍一下微服务、容器、SDN和一直存在的SDDC（软件定义的数据中心）意识高涨的原因：这是关于敏捷性，而不是速度。我一直是SDN（软件定义的网络）的支持者，也敏锐地意识到，由于额外的开销，SDN将天生地慢到非常小的程度。这不是一件坏事，因为它提供了一个敏捷的体系结构，该体系结构允许编程的、智能的工作负载管理，尽管包更改会带来名义上的开销。开销是如此之小，以至于不会以任何明显的方式影响消费者体验。新的敏捷功能所提供的优势来自于使用api来控制体系结构、版本控制来保持一致性以及增强对拓扑的可见性，这是许多工具都能够提供的。现在我已经谈到了这一点，让我们深入研究一下微服务和容器化，看看它们如何为组织提供敏捷性以帮助推动DevOps文化。微服务简史SOA（面向服务的体系结构）已经存在很长时间了。创建独立服务的概念，可以通过API访问来创建松散耦合的系统，这一概念长期以来被认为是一种更灵活、更具适应性的体系结构风格。"微服务"一词的出现表明，这种做法正变得越来越广泛地被使用和接受。现代软件和SaaS（software-as-a-Service）产品是基于SOA和微服务方法论的原则构建的。创建松散耦合的系统允许更好的开发和部署实践。将CI/CD（持续集成/持续部署）与microservices架构一起使用，可以让我们两全其美。微服务体系结构的真正优势是它为我们提供了横向扩展能力。松散耦合、API驱动的体系结构创建了一种自然的横向扩展能力，在这里我们可以为无状态应用程序集群服务。即使是有状态的应用程序也能够利用微服务体系结构，因此它不仅限于"新"应用程序设计。在这里，我们可以看到一个示例架构是什么样子的，它说明了作为SAP中的微服务向应用程序提供的不同服务：我们可以看到整个应用程序中功能的逻辑分离。这种风格提供了将每个微服务作为自己的应用程序环境来管理的灵活性，这种应用程序环境将服务彼此分离。在开发和构建阶段，传统的单片应用程序结构通常需要更严格的测试和维护。在操作上，这也创造了一个更易于管理的基础设施。如果微服务以任何方式失败或失败，它可能只影响整个应用程序的一个子集。对于开发和操作团队来说，这是一个更理想的情况，更不用说应用程序本身的使用者了。文化是一种微服务架构正如DevOps和Infrastructure as Code是开发应用程序基础设施的组织文化的转变一样，微服务体系结构是方法论上的一个变化，就像它是实际代码本身一样。我们完全有可能继续使用全新的工具来使用遗留的实践。这是一个不幸的结果，因为许多开发和操作团队都采用了新的产品和工具，而没有改变它们的使用方式。完全可以使用Go编写遗留样式的代码并部署Chef和Puppet，而无需真正利用产品所能提供的真正优势。微服务和容器作为使能技术容器技术在LXC（Linux容器）中也已经存在了一段时间，但是随着Docker的知名度的提高，以及CoreOS的火箭弹的迅速发展，我们显然看到了更多的关注。Microservices架构在这个行业已经有几十年的历史了，但是流行度的上升是由于最近的流行度和可见性。Netflix、LinkedIn、eBay等公司正在帮助将其软件开发实践引入主流。随着组织发展速度的提高，微服务和容器的价值正在得到实现。快速开发是由更灵活的基础设施实现的。所有这些技术的结合使业务的快速增长成为可能。联邦政府这可能还不是最广泛采用的实践，但微服务体系结构和应用程序的容器化正在成为组织所使用的现代应用程序开发的一个适当规模的部分。在相当长一段时间内，遗留开发将继续进行，因为应用程序基础设施已经到位，需要持续的维护和补充。在许多情况下，我们看到的是对遗留系统的抽象，以允许混合开发向前发展。这种转变肯定正在进行中。唯一的问题是接受率和变化率。