MBaaS服务特性和部署策略

简介:

移动应用需要保持7x24小时在线,这一特点使得移动后端即服务(MBaaS)成为运行业务逻辑和进行数据分析的天然选择。本文中,作者对云后端服务进行了全面介绍。

任何一家企业,都需要明确的移动战略来保持竞争优势。当你还在通过智能手机构建通讯和计算平台、客户与员工应用时,你的竞争对手们可能已经开始用应用提供新服务、实现业务流程流水化了。

IT在企业的数字化战略开发和实施中占据关键性的地位。CIO必须理解真正理解移动战略的诉求,并积极采取措施克服企业的惰性、技术及文化的挑战:由于缺乏相应的技能、预算吃紧、对新的开发语言不熟悉、没有敏捷实践经验以及难以同时支持多种设备上的操作系统等原因,IT部门在构建和部署移动应用时效率较低。实际上,Gartner公司在2015年的一份调查报告显示,企业平均已开发完毕的移动应用数目低于10个,不但无法支撑外部服务的需求,更无法满足巨大的内部应用需求。如果IT在管理层没有话语权,其团队就会缺乏创新精神和进取心,从而在构建移动应用上落后于其他部门。

为了避免过度的金钱和人力投入,软件自动化、服务以及Gartner所称的“轻型Web和移动应用集成”是跨越技术泥潭的唯一路径。

幸运的是,移动应用与云服务的搭配是天作之合。一方面,原生客户应用主要负责数据采集和界面提升,比如用户界面、信息展示和采集设备(GPS设备、加速计和摄像头等)。另一方面,业务逻辑、数据访问,分析挖掘,信息同步以及安全等,则由MBaaS服务(移动后端即服务)负责。这种设计在应用开发中日渐流行,我们估计其在移动应用开发中项目中所占的比重已经超过了2013年Gartner的预计(40%)。

移动云服务特性

与其他云服务一样,MBaaS的对外接口是REST API,通常包括以下特性:

数据存储、管理和同步。由于移动设备自带的存储空间有限,很多移动应用所需的数据驻留在企业数据库或第三方数据提供商处,移动设备被黑的可能性(失窃或参照FBI和苹果公司的纠纷),以及用户需要能够从多台设备上获取一致数据的需求,导致需要有安全可靠的后台服务来支撑数据的永久化存储。在统一的后台系统中,基于性能强大的服务器或虚拟机,较容易实现数据的整合、清洗和分析。MBaaS还为数据加密传输、永久存储和客户端同步提供了方便的应用接口。

用户识别和访问控制。用户都痛恨多个用户名和密码,因此一致性的登录接口对于企业应用来说是必选项。MBaaS能够与企业目录(比如Active Directory、LDAP、VMware Identity Manager以及诸如Salesforce或Google APPs等提供的用户认证和授权服务)集成。比如,Kinvey公司(移动应用开发后台服务商)为应用开发者提供简洁的登录机制,让后者免于学习SAML或Active Directory API的语法。

移动通知推送。基于两个不同的客户端通知API来完成与多个移动应用的交互,是一件事倍功半的事情。对此,MBaaS提供了集中式的通知队列机制,能够平滑地连接后台通知推送者和应用订阅者。比如,AWS的Mobile Push服务提供了单一的API接口,允许后台拥有将消息推送给特定设备或任何订阅了Simple Notification Service(SNS)主题的用户。而且,由于SNS是AWS的消息传送标准,因此Mobile Push服务也允许应用接收来自于任何AWS服务的通知。

系统集成。企业应用所用到的信息通常来自于现有的后端系统,比如客户管理系统、企业资源管理系统、财务系统以及人力系统。同时,也会需要从第三方数据提供商或者SaaS服务商处获取信息。对此,MBaaS提供了存储和API网关,能够确保对必要信息的访问,并在将数据推送到移动客户端之前在云中完成所需处理工作。API网关还意味着更易实现移动应用的可扩展性,比如,

部署和产品选项

我们认为,移动应用设计的最佳实践路径是基于公有云实现与本地应用的连接。所有的主流IaaS服务商都提供了移动类服务:亚马逊的AWS Mobile Hub和Cognito、微软的Azure Mobile APP Service、Google的Firebase和APP Engine。同时,在细分的MBaaS市场,也呈现欣欣向荣的景象,比如AnyPresence、Appcelerator、Kinvey、Kony、Red Hat FeedHenry以及其他提供SaaS实施管理服务的公司。

对于那些对公有云心怀警惕却又有大量移动应用需要部署的企业来说,可以选择在管控较强的私有云中部署MBaaS产品。我们的观点是,出于安全顾虑而排斥公有云服务是站不住脚的。但是必须承认,对于那些有大量移动应用需求的企业来说,在自有环境中进行部署可能性价比更高 – 可以实现设计、开发、测试和项目管理等工作以及后台系统使用的集约化。不过,由于MBaaS市场仍充满不确定性,我们对通过自有环境部署应用的选择持保留态度 – 服务功能变化频繁,而诸如Feedhenry等小厂商则不断被大型云服务商收购合并。

对那些已经在使用主流IaaS平台的企业来说,应该首先考虑当前的平台;相对来说,主流服务商所提供的功能更加优质,而且会持续更新。
本文转自d1net(转载)

相关文章
|
3月前
|
Kubernetes 网络性能优化 调度
Koordinator v1.4 正式发布!为用户带来更多的计算负载类型和更灵活的资源管理机制
Koordinator v1.4 正式发布!为用户带来更多的计算负载类型和更灵活的资源管理机制
|
26天前
|
安全 编译器 测试技术
C++代码复用策略及与标准兼容性指南
C++代码复用策略及与标准兼容性指南
100 2
|
4月前
|
SQL XML JSON
Hasor【部署 04】Dataway接口配置服务扩展能力实例分享
Hasor【部署 04】Dataway接口配置服务扩展能力实例分享
53 0
|
4月前
|
Java 应用服务中间件 API
选择部署策略
选择部署策略
30 0
|
数据采集 缓存 运维
jpOwl一款高性能的后端业务监控,动态配置策略规则的工具包
jpOwl一款高性能的后端业务监控,动态配置策略规则的工具包
jpOwl一款高性能的后端业务监控,动态配置策略规则的工具包
|
canal Kubernetes 负载均衡
Kubernetes 网络概念及策略控制|学习笔记
快速学习 Kubernetes 网络概念及策略控制
115 0
Kubernetes 网络概念及策略控制|学习笔记
|
负载均衡 API 调度
语聊源码,任务分发系统需要具备的功能
语聊源码,任务分发系统需要具备的功能
|
存储 缓存 监控
如何为从 1 到 10 万用户的应用程序,设计不同的扩展方案?
对于创业公司来说,有用户注册是好事情,但是当用户从零扩展到成千上万之后,Web 应用程序又该如何支持呢?
|
弹性计算 Java
AutoScaling 成本优化模式升级--混合实例策略
伸缩组成本优化模式以成本为目标,始终创建最低价的实例,同时,通过多可用区,多实例规格分布,以此来提高服务稳定性。但是,对于成本优势最大化的竞价实例,伸缩组难以防范竞价实例大范围回收可能导致的服务雪崩,本次升级允许用户制定更详细的成本控制策略,在成本和稳定性之间进行调整和权衡。
13976 0
|
Kubernetes 网络协议 应用服务中间件
超适合小项目的 K8S 部署策略
Kubernetes 的稳健性、可靠性使它成为现阶段最流行的云原生技术之一,但也有不少用户反映, Kubernetes 技术学习起来十分复杂,只适用于大集群且成本较高。这篇文章将打破你的观念,教你在小型项目中部署 Kubernetes 集群。
3034 0