为什么采用按应用提供application服务的方法很重要

我不能读懂别人的心思（我的孩子可能会不同意，但这并不重要），但我可以读懂我们对application交付状况调查的回应。 当我从应用程序开发人员的角度来阅读这些文章时，我看到了一幅非常有趣的画面。

开发人员关心速度。 并且安全。 并扩大规模。 不一定按这个顺序，但他们关心这三个。 他们不仅关心，而且认识到应用服务的价值，以帮助他们实现这三个目标。

也就是说，开发人员不仅想要模糊的“加速”应用服务，他们还想要提供 TCP 优化和缓存的特定服务。 他们想要一个Web应用防火墙以及一些负载均衡功能。

问题是，大多数应用服务都是以共享基础设施模型提供的。 每个应用都有自己的“虚拟表示”，但它物理上驻留在共享的软件或硬件上。

这可能会导致真正的问题，并且在一定程度上成为 IT 和应用程序开发之间摩擦的根源。 正是这种系统的共享特性为我们带来了变更窗口和审查委员会以及周六晚上的部署（提供披萨，以安抚我们）——这些过程减慢了开发速度，并使部署成为所有参与者的令人沮丧的经历。 

我们不再部署庞大的单体应用程序。 即使我们还没有采用疯狂的微服务并将应用程序分解为数百个小服务，我们仍然有更多应用程序需要更频繁地部署。 这些应用程序是以一周为一个周期而不是一年为一个周期进行开发，并且需要更快、更频繁地推送更新。

从根本上来说，这也是公共云如此成功的原因。 因为这是我的应用程序和我的基础设施，所以我不需要等待 Bob、Alice 或 John 才推送更新。 因为这都是我的，所以如果出了问题，责任全在我身上。

同样的方法在本地也是可行的（而且我认为是更好的选择）。 必要的是，组成应用交付链的所有部分和部件都应支持云计算所要求的同一种每个应用程序的方法。

基本上，采用每个应用程序来提供所需的网络和应用服务的方法类似于为应用专用一个子网；如果你愿意的话，可以称之为应用程序交付 VLAN。 这一切都与一款应用程序有关，它提供专门的服务。

这种隔离不仅对部署计划有好处，而且对其他所有人也有好处。 故障时，您希望尽可能地限制影响半径。 每个应用程序的架构意味着严格限制故障影响，这使得所有“以防万一”值班的人都很高兴，因为他们没有接到那个电话。 我可以每周发布和部署一次，而不会与每月发布和部署一次的应用程序发生冲突。 我的应用程序、我的服务、我的部署计划。

每个应用程序的架构还可以轻松解决生产中出现的问题。 他们经常这样做。 事实上， 2017 年 Atlassian 的一项调查显示，50% 的开发人员在代码发布后报告了生产中的问题。 其他人不可能做出可能影响该应用的更改。 您可以直接了解所涉及的系统，而不必花费宝贵的时间来弄清楚可能涉及哪些系统。

每个应用程序的架构自然更适合云 - 无论是公共云还是私有云 - 因为这是模型做出的假设。 每个应用程序都有一组专用的应用服务来扩展、加速和保护它。

现实情况是，每个应用程序的架构是不可避免的。 这不是我第一次这么说。 应用的重要性不容忽视，而保证应用程序安全所需的特定于应用应用的安全性日益增加，这意味着迟早会出现一种针对每个应用程序的方法。

这是一件好事，因为开发人员想要的应用服务往往都是特定于应用程序的。 对一个人有用的东西不一定对另一个人也有用——事实上可能产生负面影响。 通过采用基于每个应用程序的架构方法进行应用交付，您可以确保开发人员不仅可以获得他们想要的以及扩展、保护和加速应用程序所需的一切，而且还可以更好地支持他们期望从云中获得的自助服务模式，无论是在本地还是在外部。