如今微服务已经成为最流行的一种软件架构，人们通过自己对业务的理解，和科学方法（比如领域驱动设计的理论）的加持将组织对外提供的产品拆分为一个个微服务，同时按照微服务的架构调整组织架构（逆康威定律）来开展业务的迭代。
以往组织习惯于自建数据中心来部署自家的产品，这些数据中心可能构建在买断或者是租赁的机房中，组织需要对机房的设备进行复杂的管理，包括交换机、服务器、磁盘、机柜等这些硬件设施，以及应对因为机房掉电、机柜温度过高、服务器崩溃等带来的故障。应对这些要问题往往会花费大量的人力财力，同时达不到很好的效果，使得自己产品的 SLA（服务等级约定）往往无法达到对客户的承诺，从而造成赔偿。
随着云的兴起，人们越来越习惯于将自己的业务部署到公有云之上，公有云帮助用户屏蔽了硬件的细节，工程师再也不用关心基础设施的搭建和维护问题，而是可以把自己的精力尽可能得放到业务的部署、维护和开发之上。然而，除了享受云带来的便利以外，云的兴起和使用也给用户带来了其他的一些问题：
“多云”指的是同时使用多种公有云，将业务镜像地、或者异构地部署到这些云上，同时尽可能采用标准服务（避免厂商锁定）。因为使用了多种云，当某个云出现不可用的情况下，它对业务的影响能够被缩小，甚至通过 DNS 修改解析等方式，启用备份的云，从而确保业务的连续性。“混合云”指的是组织除了使用了一个或者多个公有云以外，还拥有自建的私有云（或者数据中心），在此场景下，部分业务可能部署在私有云，其他的可能都已经上公有云，或者所有业务都在云上，而私有云负责管理和监控。总之，在采用了“多云”或者“混合云”这样的模式后，在提升服务可用性的同时，软件部署方式的灵活性也大大提升。
然而，在应用“多云”和“混合云”后，如何高效、简单的管理云上的微服务，则变得更加棘手。这当中比较经典的要属 API 的管理了，如今大量的微服务都选择使用 API 这一方式来进行交互，当微服务部署之后，它们提供的 API 需要能够被暴露到外部，以便和外部的调用方连接，从而提供服务。
我们知道对于管理微服务 API 而言，一款好的 API 网关是必不可少的，API 网关能够安全、高效地将微服务 API 暴露出去，然而，采用“多云“，“混合云”这样的模式后，对于 API 网关的需求不仅仅局限在 API 网关自身的功能是否满足业务的需求了，具体来说，我们需要考虑：
正如前文所述，在采用“多云”或者“混合云”，后，每个云或者私有数据中心所部署的业务可能存在着比较大的差异，因此用户需要在这些云上分别部署一套套的 API 网关集群，且可想而知这些网关集群的配置、证书、API 密钥等可能不尽相同。如果用户选择使用的网关不支持多集群的管理，可能会对 API 的管理造成很大的麻烦，尤其是在业务扩张期，API 网关集群规模越来越大，数量越来越多的时候。
在这种情况下，一款支持多集群管理的 API 网关产品 便能极大地降低管理员的管理成本。
由于业务的快速发展，少数几个 API 网关管理员可能无法承担起维护全部 API 网关集群的重担，同时考虑到大部分的网关配置，比如添加路由、为路由配置插件等，可以由开发者自行处理，不需要全部由管理员经手。因此，是否支持“协作”对于管理来说，也变得重要起来。具体来说，管理员可以邀请组织内的其他成员加入到该 API 网关集群的管理中，同时使用 RBAC 之类的策略为大家分配不同的权限，比如为管理员设置 Organization Admin 的角色（可以执行任意操作），为普通开发者设置为 Service Admin 的角色（仅可维护少数几个服务和路由），进而在实现协作的基础上确保操作安全，并且在员工离职或者出现岗位变动时，及时回收账号或者修改权限。
试想如果不支持协作，那么大概率一个组织内的成员会共享一个账号，这种用法在初期可能具备一定的便利性，但是时间一长它的潜在危害就会暴露出来，比如某员工在离职后可能依然可以登录并进行配置，甚至一些不怀好意的员工可能会选择删除全部数据，这对于组织对外的产品和服务来说是灾难性的。而且在进行复盘时，管理员甚至无法将具体的操作和具体某个成员关联起来，因为大家共享同一账号（即便是保有审计日志的情况下）。
随着容器化和容器编排的技术越来越成熟，以往很多运行在虚拟机之上的微服务都纷纷转投了 Kubernetes 的怀抱，这就意味着，用户可能会选择使用 Kubernetes、传统的虚拟机、甚至是物理机（比如在自己的私有数据中心里）。如果用户选择的 API 网关产品在功能上非常丰富，能够满足业务需求，但是又受限于底层基础设施，或者缺乏成熟的安装工具，这样会让用户处于两难的境地，要么放弃使用，要么自行进行二次开发从而使得该 API 网关获得运行在某个基础设施之上的能力。无论如何，这都会带来使用上的成本。