Backend as Service Baas

7/24/2019 Backend as Service Baas

1/13

E-Guide

MOBILE APP

DEVELOPMENT

LEAPS FORWARD

SearchSOA


2/13

P A G E 2 O F 1 3 S P O N S O R E D B Y

Home

Developers get intoBaaS, mobile APIs fornew opportunities

How to make designchoices as mobileand IoT applicationscollide

MOBILE APP DEVELOPMENT LEAPS FORWARD

ACKEND AS AService (BaaS) is making

waves in the mobile application develop-

ment space. In this e-guide, learn how youcan implement BaaS and how it functions

similarly to Platform as a Service (PaaS). Additionally, learn how

incorporating the Internet of Things (IoT) with mobile worker sup-

port can enhance business productivity.

B


3/13


Home




DEVELOPERS GET INTO BAAS, MOBILE APIS FOR NEWOPPORTUNITIES

Tom Nolle, CIMI Corporation

A new development in the application programming interface (API) market,

Backend as a Service (BaaS), offers developers a whole new dimension of op-

portunity: cloud services to build the mobile applications of the future.

Mobility, mobile broadband and mobile apps are transforming the Inter-

net and the way people communicate and use information. For developers, the

mobile app represents an enormous, lucrative new market. From a business

perspective, each of the mobile platforms has its own benefits and limitations.

Each also has its technical framework -- its own APIs. Mobile development

platform APIs generally fall into two categories: platform APIs related to the

mobile devices own operating system and middleware, and service APIs re-

lated to the access of Web-hosted material.

The new opportunity in APIs is Backend as a Service, an extension of the

service API model. The goal of BaaS is to convert common and useful elements

of mobile application logic -- storage, identity management, social network


4/13


Home




integration, photo enhancing -- into representational state transfer (REST)Web services that the application invokes as needed, making these services

back ends to mobile apps.

As a concept, BaaS is similar to Software as a Service (SaaS) and Platform

as a Service (PaaS): It offers functionality as a Web service. With SaaS, whats

offered is an application or application component. Salesforce.coms CRM is

a good example. PaaS offers a collection of services designed to present a com-

plete virtual operating system; Microsofts Windows Azure is the best-known

PaaS example. BaaS is somewhere in between; it offers PaaS-like features,

but not as a complete programming platform. Like SaaS, those features might

perform business functions oriented to vertical markets or functionalities

that can be used across industries. In all cases, though, BaaS aims to enhance

mobile development.

IMPLEMENTING BAAS

Success with BaaS requires a targeted business case and careful implementa-

tion to support mobile development practices. Most BaaS deployments today

are horizontal -- they cover a variety of markets -- and deal with well-known is-

sues such as social network integration. The problem with these types of BaaS


5/13


Home




implementations is that they are so obvious that competition is inevitable,and so basic that differentiation is difficult. For example, its likely that major

cloud providers will move into BaaS services related to storage and identity, and

social network companies will offer social network BaaS integration. Vertical

markets, where a developer already has skills, contacts and software products,

are useful places to look into for BaaS opportunity. In horizontal markets, data

analysis and reduction tools, or forecasting and projection tools, are good can-

didates for BaaS.

Technically, the key issue for BaaS is preserving the dominant RESTful

Web service model of interface. These interfaces appear as a simple PUT/GET

transactional model that doesnt remain in a processing state between calls.

Most of the major PUT/GET giants have exposed their own service APIs as

RESTful interfaces that receive and respond using XML data structures. XML

handling can be a chore, however, and its helpful to either accept a simpler data

structure or provide programming logic to use the interface as a reusable func-

tion in each of the target mobile devices.

Creating a BaaS service with the correct level of functional granularity is

also important. Mobile users typically expect a quick response to a request, and

there are interface timing issues that make it unadvisable to turn a complex


6/13


Home




function with a long execution time into a single service. Since RESTful inter-faces are expected to be stateless, care is required in turning a complex func-

tion into a series of elements that can be used independently, but can function

together when needed. Each request must stand on its own, and data from the

response to a given request, if needed later, must be stored in the device and

returned or maintained and updated by the service.

PASSING AS PAAS

Perhaps the most significant aspect of BaaS, from the developers perspective,

is the relationship with PaaS. Any developer who has reviewed the APIs for

search or social network giants, or for cloud management, knows that mul tiple

APIs typically form an ecosystem that, if it grows large enough, can approach

the functionality of a platform, as in PaaS. A few disconnected BaaS APIs are

less compelling than, for example, an entire BaaS ecosystem aimed at support-

ing mobile-social network collaboration for enterprises. Popular open source

blogging or chat room tools, for instance, could be built on unified communica-

tions and collaboration, augmented with APIs to create voice and video calls.

BaaS will lead to a systematized view of background services for mobile de-

velopment, which is for all practical purposes a mobile-driven PaaS platform.


7/13


Home




Developers, operators and enterprises need to think about this evolution -- be-cause a cooperative and symbiotic collection of BaaS tools are more valuable

to developers and consumers than individual APIs could ever be. The BaaS

movement could be a catalyst for moving developer focus from de vices to the

cloud -- and that means faster service and increased competition among hand-

set vendors. But BaaS, like any cloud trend, is in the early stages, and theres a

whole mobile world out there.


8/13


Home




HOW TO MAKE DESIGN CHOICES AS MOBILE AND IOTAPPLICATIONS COLLIDE

Tom Nolle, CIMI Corporation

The Internet of Things has been getting considerable coverage, causing com-

panies to explore ways IoT concepts can enhance productivity. Often, this

research leads to one specific IoT model that shows promise: combining IoT

with mobile worker support. Architects and planners charged with design-

ing for this model must understand what the mobile/IoT model really means,

address how adding IoT changes the equation in mobile empowerment, and

define their own design pattern to represent how mobile/IoT applications will

be handled going forward.

Most legitimate IoT applications involve interaction between users and

what could be called a sensor and control network (SCN). In process control

applications, the SCN is a machine-to-machine, or M2M, network that uses

sensor information to drive changes in material handling or processing. These

applications might use mobile technology as a means of communicating with

sensors, but they dont force major changes in application design as normal


9/13


Home




industrial control applications would.Mobile and IoT applications collide in applications where a worker is vi-

sualized as moving through a sensor and control space and interacting with

elements. If their full potential is to be realized, these applications require very

different design concepts than normal mobile or IoT applications do.

TAKING THE FIRST STEP

The first step in designing mobile/IoT applications is to ensure enterprise ar-

chitecture process models are up to date and reflect the business information

flows and activity sequences the mobile/IoT application will generate. Many

early attempts at harnessing the benefits of mobile/IoT failed because those

benefits werent linked to specific enterprise processes and flows, and so nei-

ther could be validated or supported.

The second step in mobile/IoT application design is understanding whats

in the SCN space. Is the application one where a worker gets information from

sensors, one where a worker activates networked control elements to perform a

specific task, or both? The answer will determine the best starting point for new

application design -- is it contextual in nature or registration and activation?

When mobile workers get sensor information from an IoT application,


10/13

P A G E 1 0 O F 1 3 S P O N S O R E D B Y

Home




that information can be viewed as enhancing the notion of context that formsthe underpinning of all mobile empowerment applications. This approach

embodies two broad alternative models: the extended-senses model and the

sensor-driven model.

Extended-senses models use IoT sensors to augment what a worker can

know about the current context -- the point of activity. Generally, a workers

location establishes what IoT sensor information is available nearby, and that

information is collected automatically into the workers contextual inventory,

to be processed as any context data would be. This is an easy model to imple-

ment because it extends, but doesnt change, the application model for mobile

empowerment.

In a sensor-driven model, the application identifies a situation that needs

handling based on sensor information, and then alerts and perhaps dispatches

the worker to the right spot. This model differs sharply from normal mobility

applications because the worker is driven by the application rather than driving

it. The context of the job is set by the conditions at the point where the worker

is expected to be active, and the goal is getting the worker there.


11/13


Home




A KEY INGREDIENTThe key ingredient in this sensor-driven model is identifying an alert condi-

tion in the first place. If a sensor and control network is already being used for

process control, facilities monitoring and so on, it might be possible to gener-

ate a trigger for IoT/mobile activity from the current process or monitoring

application. Taking that approach is wise because it reduces the risk of loading

down sensors or sensor networks with additional traffic. If its not possible to

piggyback on current process or monitoring applications, sensor information

will need to be analyzed.

If possible, avoid reading sensors from a new application. Most sensor and

control applications store sensor data in a database regularly. By running ana-

lytics processes on stored data, it might be easier to spot unusual conditions.

For example, temperature and humidity changes are easier to view as a trend

line because any sudden change would be unusual and likely warrant a visit

from a technician. Using DBMS-based analytics as the source of IoT context

also will reduce the complexity of finding and reading relevant sensors.

The final point is the importance of consistency. Virtually every user

who has looked at the mobile/IoT combination will admit that many applica-

tions would fit that description, but few represent the low-hanging fruit that


12/13


Home




typically drive projects in a new technology area. A major risk is that each ap-plication could produce its own software based on a unique approach, and that

would compromise application agility and component reuse. It could also cre-

ate operational problems if the worker empowerment element varied between

applications.

Software architects and developers know the accepted way to address these

risks is the creation of a design pattern, a template-like approach to a problem

that can be implemented as needed. For applications blending mobility and

IoT, a design pattern would likely be needed for both the extended-senses and

sensor-driven models. Its possible to conceptualize a design pattern that ac-

cepted a condition set that represents testable sensor conditions and an op-

tional worker location, and returned a set of values representing sensor results.

It can be tempting to jump in to API design too quickly. Be sure to have

enough exposure to the complete range of mobile/IoT applications, at least at

the business process level, before committing to specific componentization

and API design. Taking the intermediate step of developing one or more formal

design patterns will ensure the API transition is made with a broad knowledge

of the needs and opportunities the union of mobility and IoT can bring.


13/13


Home




FREE RESOURCES FOR TECHNOLOGY PROFESSIONALSTechTarget publishes targeted technology media that address

your need for information and resources for researching prod-

ucts, developing strategy and making cost-effective purchase

decisions. Our network of technology-specific Web sites gives

you access to industry experts, independent content and analy-

sis and the Webs largest library of vendor-provided white pa-

pers, webcasts, podcasts, videos, virtual trade shows, research

reports and more drawing on the rich R&D resources of technology providers to addressmarket trends, challenges and solutions. Our live events and virtual seminars give you ac-

cess to vendor neutral, expert commentary and advice on the issues and challenges you

face daily. Our social community IT Knowledge Exchange allows you to share real world

information in real time with peers and experts.

WHAT MAKES TECHTARGET UNIQUE?

TechTarget is squarely focused on the enterprise IT space. Our team of editors and net-work of industry experts provide the richest, most relevant content to IT professionals and

management. We leverage the immediacy of the Web, the networking and face-to-face op-

portunities of events and virtual events, and the ability to interact with peersall to create

compelling and actionable information for enterprise IT professionals across all industries

and markets.

Backend as Service Baas

Documents

Transcript of Backend as Service Baas