好的应用服务器要确保它所提供的API和具体实现之间的一致性。开发人员可以确信如果他的业务逻辑需要特定的功能，他所部署的逻辑是正常运行的，因为应用服务器开发人员（以及预先定义的标准）能够保证它们之间能够协同工作和协同演化。另外，好的应用服务器还要负责最大化吞吐量和可扩展性，因为它要处理来自用户的所有请求；减少延迟并提升负载能力，它有助于提升应用的可处置性；轻量级的资源占用，最小化硬件资源和成本；最后，还要足够安全，能够防范所有的安全漏洞。对于Java开发人员来说，Red Hat提供了Red Hat JBoss企业级应用平台，满足了现代、模块化应用服务器的所有需求。
结论容器镜像已经成为分发云原生应用的标准打包格式。尽管容器本身并没有为应用提供任何真正的业务优势，但是Kubernetes及其相关的项目，如OpenShift和Istio，提供了非功能性的需求，而这些需求过去曾是应用服务器的功能的一部分。
开发人员过去所使用的大多数非功能性需求，来源于应用服务器或者像Netflix OSS这样的库，这些需求是与特定语言绑定的，比如Java。但是，如果开发人员选择使用Kubernetes + OpenShift + Istio来满足这些需求的话，它们是与任何特定语言都没有关联的，这样的话就能鼓励开发人员针对每个使用场景选择最佳的技术/语言。
最后，在软件开发领域，应用服务器依然有它的位置。但是，它们变得更像是特定语言的框架，在开发应用的时候，这是很简便的，因为它们包含了大量已经编写就绪且经过测试的功能。
转移到容器、Kubernetes和微服务架构时，最棒的事情之一就是不必为应用选择单一的应用服务器、框架、架构风格甚至编程语言。你可以很容易地部署一个含有JBoss EAP的容器，让JBoss EAP运行已有的Java EE应用，其他的容器则可能会包含使用Wildfly Swarm编写的微服务或者使用Eclipse Vert.x编写的反应式程序。这些容器都可以通过Kubernetes进行管理。如果想了解这些概念如何实际运行，参考Red Hat OpenShift应用运行时。通过Launch服务在线构建和部署示例应用，这些应用可以使用WildFly Swarm、Vert.x、Spring Boot或Node.js。选择“Externalized Configuration”以便于学习如何使用Kubernetes ConfigMaps，这足以让你踏上学习云原生应用的征途。
你可以说Kubernetes/OpenShift是新的Linux，甚至可以说“Kubernetes是新的应用服务器”。但实际上，应用服务器/运行时+OpenShift/Kubernetes + Istio已经成为了云原生平台的事实标准。
关于作者Rafael Benevides是Red Hat的开发者体验（Developer Experience）总监，具有多年的各领域IT行业经验，他帮助世界范围内的开发人员和公司提升软件开发的效率。Rafael将自己定位为问题解决者，并乐于分享。他是Apache DeltaSpike PMC成员，该项目曾获得过Duke’s Choice Award，他还会在JavaOne、Devoxx、TDC、DevNexus等技术会议上发表演讲。
Linux公社的RSS地址：https://www.linuxidc.com/rssFeed.aspx