移动后端即服务（Mobile backend as a service，MBaaS）本质上是一系列预构建的针对移动特点做了优化的API，客户端开发人员可以使用它们而不需要理解服务器端是如何实现这些API的。Red Hat的移动副总裁，也是FeedHenry的创始人，Cathal McGloin说，这允许开发人员将一些功能构建成微服务架构下的可重用API，客户端开发人员可以在需要时发现并使用这些API。

但是虽然这样的方法有强大价值的支撑，但是调查结果显示MBaaS并没有在企业间势不可挡地普及。本文的问答中，McGloin会解释为什么他坚信开发人员还没有真正使用起来，并且给有兴趣在自己企业内部使用MBaaS的公司一些建议。

Red Hat的一次调查显示超过一半的公司仍然自己开发后台集成方案，而不是使用MBaaS。是因为他们正在使用某种类型的云服务，还是因为他们已经有了自己的内部后台系统？

Cathal McGloin：首先，这是市场成熟度的问题。如果回头看互联网刚开始发展的时候，每个人都在构建自己的网站服务器，最终，一系列标准出现了，大家都不再尝试构建自己的网站服务器，而是使用现成的网站服务器。该领域情况类似：MBaaS是一种相对新的技术。大家还不知道这是什么，还没有将其包含进架构里，因此，我们还处在移动架构的初级阶段，以后会越来越好。

另一个原因是当大家开始接触移动时，都想使用已有的Web API编写移动应用程序。因此，已经为Web构建了健壮的API，他们所做的是构建了称为RESTful API的移动应用，这是普遍的做法。因此，他们构建出了使用或者和Web应用有类似功能的应用程序。

使用这种方案的话，公司可能会遇到什么问题？

最好的应用是有关用户体验和用户接口的，有关重新发明流程的。

McGloin：问题只会在已经有健壮API的系统想要将这些API公开时，特别是想暴露到公开网络上时体现出来。记住所有应用运行在手机上，除非装了特别的VPN，都是运行在公开网络上。现在我想要从应用里访问的这些内部系统在服务架构上并没有得到500万美元的投资来健壮这些API，因为十年前不可能看到需要从防火墙外访问HR系统的需求。因此，一些API从安全性角度可能已经可以用于移动端了，但是可能从生成正确格式的JSON数据角度还无法用于移动端。

总体来说，没有正确架构的只是少数系统，大部分都能够通过应用程序从防火墙外访问。从现在开始大家才渐渐意识到，当从第一个应用到开发第二个应用的时候，需要在企业层面做一些事情，而不是总是针对每个应用程序开发一次性的方案。

在移动应用开发中遇到的哪些问题可以被移动后端即服务解决？

McGloin：我觉得大家在移动端会遇到这样的问题：他们认为使用混合工具是解决UI问题的最佳手段。我认为大部分初学者对于UI和UX有误解，认为这些是需要优秀设计人员做的事情，没有任何工具可以帮助很好得解决这些问题。最好的应用是关于用户体验和用户界面的，是关于重新发明流程的。

重新思考流程的确是让用户使用的核心原因。这些工具可以帮助开发保持业界水准的同时降低构建和支持这些应用程序的成本。但是这些工具本身无法创造出世界上最炫的应用。

对于评估MBaaS的企业而言有哪些核心标准？哪些是必须有的功能，他们的评估列表里必须要有哪些标准？

McGloin: 首先，必须能够支持多种开发人员工具集来构建原生，混合和HTML5的应用，需要支持所有这些不同的类型。

其次，必须有后台系统的集成库，因为这是真正困难的地方：从很多后台系统中的某一个那里得到数据。因此，必须有模块库，能够简化从这些后台系统得到数据的过程。公司一定会问，“是否有灵活的部署方式？我可以在云平台开始，然后如果确实在防火墙后需要再购买本地版本吗？”实际上，他们不应该被局限于一种部署方式。

对于要转型到移动后台即服务的开发人员有哪些建议？

McGloin：当开发人员建立到后台的链接时，或者实现某个MBaaS功能时，他们正在给自己节约时间，为下一个应用程序做好准备，因为他们已经完成了，比如，链接到LDAP系统的用户认证的实现。因此，一下子，他们不需要自己开发就有了很多关键功能。“这是上一个应用开发里大家构建的用户认证模块，现在我可以在这个应用里重用它。”

因此，我的建议是：因为可以作为服务购买，就不需要购买很多许可证，可以按需使用，也可以仅仅花一点钱就可以开始，应该去尝试看看适不适合自己。这是开始尝试的最好的方式，然后在实际使用中验证是否会加速手头的应用以及将来的应用的开发进程。

最终，需要提前考虑到很多方面。它是否使用容器化技术？是否使用了微服务架构？是否在未来四五年内仍然是领先技术？今天所选择的架构是否能够支撑扩展？这些都是开发人员需要考察的方面。