我们将关注这些趋势，以及在未来一年围绕这些趋势开展业务的公司。你看到了什么趋势?在下面的评论让我们知道我们遗漏了什么，或者如果你同意/不同意我们在这里概述的观点。
1.服务网格很流行！
服务网格是一个专用的基础设施层，用于改善服务到服务的通信，是目前最热门的关于云的本地类别。随着容器变得越来越流行，服务拓扑变得越来越动态，需要改进的网络功能。服务网格可以通过服务发现，路由，负载平衡，运行状况检查和可观察性来帮助管理流量。服务网格试图驯服不守规矩的容器复杂性。
很明显，服务网络越来越受欢迎，因为像HAProxy，traefik和NGINX这样的负载均衡器已经开始将自己重新定位为数据平面。我们还没有看到广泛的部署，但我们知道在生产中运行服务网格的企业。此外，服务网格不是微服务或Kubernetes环境专有的，也可以应用于VM和无服务器环境。例如，国家生物技术信息中心没有运行容器，但它正在使用Linkerd。
服务网格也可以用于混沌工程，“在分布式系统上进行实验的学科，以建立对系统承受湍流条件的能力的信心。”而不是安装在每个主机上运行的守护进程，服务网格可以注入延迟和进入环境的失败。Istio和Buoyant 的 Linkerd 是该领域最引人注目的产品。请注意，Buoyant去年12月发布了针对Kubernetes的开源服务网络Conduit v0.1。

2.事件驱动架构的崛起。
随着对业务敏捷性的需求的增加，我们开始看到向“推送”或基于事件的架构的转变，其中一个服务发送一个事件，一个或多个观察该事件的观察器容器通过异步运行逻辑来响应而没有事件生产者意识到。与请求 – 响应体系结构不同，在事件驱动系统中，启动容器中的功能流程和事务负载不依赖于下游容器中远程进程的可用性和完成。这样做的另一个优点是开发人员在设计各自的服务时可以更加独立。
虽然开发人员可以将容器环境设计为事件驱动，但函数即服务（FaaS）本质上体现了这种质量。在FaaS体系结构中，函数作为文本存储在数据库中，并由事件触发。调用该函数后，API控制器接收消息并通过负载均衡器将其发送到消息总线，消息总线将其排队等待调度并配置到调用程序容器。执行后，结果存储在数据库中，用户将被发送结果，并且该函数将被解除，直到再次触发为止。
FaaS的好处包括：1）缩短从编写代码到运行服务的时间，因为没有工件可以创建或超越源代码，2）由于函数由AWS Lambda等FaaS平台管理和扩展，所以开销减少。然而，FaaS并非没有挑战。由于FaaS需要将每个服务分离，因此可能存在大量函数，这些函数很难发现，管理，协调和监控。最后，如果没有包括依赖关系在内的全面可见性，很难调试FaaS系统，并且可能会出现无限循环。
目前，FaaS不适合需要更长调用，大量数据加载到内存以及一致性能的进程。虽然开发人员将FaaS用于后台作业和时间事件，但我们相信随着存储层的加速和平台性能的提高，用例将随着时间的推移而扩展。
2017年秋季，云原生计算基金会（CNCF）调查了550人，其中31％使用无服务器技术，28％计划在未来18个月内使用无服务器。调查随后询问正在使用哪个特定的无服务器平台。在使用无服务器技术的169个中，77％表示他们使用AWS Lambda。虽然Lambda可能是领先的无服务器平台，但我们相信可能会有一些有趣的机会。Edgecompute对于物联网和AR / VR使用场景尤为强大。
3.安全需求正在发生变化。
由于内核访问，默认情况下，打包在容器中的应用程序基本上更安全。在VM环境中，唯一的可见性点是虚拟设备驱动程序。现在转移到容器环境，操作系统具有系统调用和语义含义。这是一个更丰富的信号。以前，运营商可以通过将代理放入虚拟机来实现这一信号，但这很复杂且需要管理很多。容器提供更清晰的可见性，与VM环境相比，容器环境中的集成是微不足道的。
考虑到这一点，451 Research调查显示，安全性是容器采用的最大障碍 – 挑战仍然存在！最初，漏洞是容器环境中的主要安全问题。随着公共注册表中即用型容器图像的数量成倍增加，确保它们也没有漏洞变得非常重要。超时，图像扫描和身份验证已经成为一种商品。
与虚拟机管理程序作为访问和控制点的虚拟化环境不同，任何可访问内核根目录的容器最终都可以访问内核上的所有容器。反过来，组织必须保护容器与主机的交互方式，以及哪些容器可以执行某些操作或系统调用。强化主机以确保正确配置组和命名空间对于维护安全性也很重要。
最后，传统防火墙依靠IP地址规则来允许网络流量。此技术无法扩展到容器环境，因为动态协调器会重用IP。运行时威胁检测和响应对于生产环境至关重要，并通过对容器环境进行指纹识别并为行为基线构建详细图片来实现，因此很容易检测到异常行为并对攻击者进行沙箱处理。451研究报告指出，52％接受调查的公司正在生产集装箱，这表明企业采用容器本地运行时威胁检测解决方案的速度加快。
4.从REST迁移到GraphQL。
GraphQL于2012年由Facebook创建，于2015年开源，是一种API规范，它是一种查询语言和用于完成查询的运行时。GraphQL类型系统允许开发人员定义数据模式。可以添加新字段，并且可以在不影响现有查询或重构客户端应用程序的情况下老化字段。GraphQL功能强大，因为它不依赖于特定的数据库或存储引擎。
GraphQL服务器作为单个HTTP端点运行，表示服务的全部功能。通过在类型和字段（而不是像REST这样的端点）方面定义资源之间的关系，GraphQL可以遵循属性之间的引用，因此服务可以使用单个查询从多个资源接收数据。或者，REST API需要为单个请求加载多个URL，从而增加网络跃点，从而减慢查询速度。通过减少往返次数，GraphQL减少了每个数据请求所需的资源数量。返回的数据通常格式为JSON。
使用GraphQL而不是REST还有其他好处。首先，客户端和服务器是分离的，因此可以单独维护它们。与REST不同，GraphQL使用类似的语言在客户端和服务器之间进行通信，因此调试更容易。查询的形状完全匹配从服务器获取的数据的形状，与其他语言（如SQL或Gremlin）相比，使GraphQL高效且有效。查询反映其响应的形状，因此可以检测到偏差，并且可以识别未正确解析的字段。由于查询更简单，因此整个过程更加稳定。众所周知，该规范支持外部API，但我们发现它也被用于内部API。
GraphQL用户包括Amplitude，Credit Karma，KLM，NY Times，Twitch，Yelp等。11月，亚马逊通过推出包含GraphQL支持的AWS AppSync验证了GraphQL的流行程度。看看GraphQL如何在诸如Twitch的Twirp RPC框架之类的gRPC和替代方案中发展，将会很有趣。
5.Chaos工程变得越来越出名。
最初由Netflix推广，后来由亚马逊(Amazon)、谷歌、微软(Microsoft)和Facebook进行实践，Chaos工程在一个系统上进行实验，以提高其抵御生产问题的能力。Chaos工程在过去十年中不断发展。它从关闭生产环境中的服务的Chaos monkey开始，并通过故障注入测试(FIT)和用于更大环境的Chaos Kong扩展了其规模。
从表面上看，Chaos工程只不过是注入混乱。虽然破坏系统可能很有趣，但它可能并不总是富有成效或提供有用的信息。Chaos engineering包含更广泛的范围，不仅包括注入失败，还包括其他一些症状，如交通阻塞、不寻常的请求组合等，以发现存在的问题。除了验证假设，它还应该揭示系统的新特性。通过挖掘系统弱点，团队可以帮助提高弹性，防止客户体验差。
像神经网络和深度学习这样的新技术是如此的复杂，以至于决定某物如何工作可能变得不如证明它是否正常运作那么重要。Chaos工程通过对系统进行整体测试来识别不稳定性，从而帮助解决这一难题。随着工程师们努力使他们日益复杂的系统更加健壮，这可能会成为一种更为普遍接受的做法。
随着chaos工程变得更加主流，它可以采用现有的开源项目、商业产品，或者如上所述，通过服务网格实现。