Connector-ess Cloud /v P }v - Akana...Language, such as WSDL, WADL, RAML or Swagger; A...

WHITE

Connector-Less Cloud Integration

© 2001 - 2015 Akana, All Rights Reserved | Contact Us | Privacy Policy

2page

WHITE


Abstract: As companies transform into digital business in response to changes in consumer habits and advances in technology, IT managers face increased pressure to integrate applications in the cloud. Traditional, connector-based integration solutions, such as the Enterprise Service Bus (ESB) cannot keep up. The proliferation of mobile apps and new, third-party cloud-based software simply overwhelms the development cycle for new ESB connectors. Now, it’s possible to achieve secure, reliable integration of applications using standards-based APIs: a connector-less approach. This paper looks at how APIs can replace or supplement traditional integration technologies and enable a higher level of flexibility in the digital enterprise.

3page

WHITE


A Decade of Digital Business EvolutionIf you compare business technology from 2005 to today, you will see many major leaps in the ways that businesses connect with customers and partners. One marker of change is that 70% of the US population now owns smartphones, a technology that hardly existed in 2005. Usage continues to increase. In addition to new mobile devices, there’s a surge in wearable technologies, sensors in cars, homes, industrial, aircraft, and so forth. Research projects that there will be 150 billion connected devices in the world by 2020. Software-as-a-Service (SaaS) adoption in the enterprises has leapt ahead from 13% in 2011 to 72% in 2014.

The numbers are impressive, but what they reveal is even more significant. Customers are interacting with brands with mobile apps, from new locations, in search of new kinds of information. Consider the following use case, then and now: A traveler arrives in a new city. He needs a hotel. Ten years ago, unless he looked on a PC before taking the trip, the process of searching for and booking the hotel would have been largely manual and done by phone.

Today, that traveler will assume that he can use an app to search, compare, and book a hotel, perhaps while walking through the airport. The app that he uses will likely connect with the backend reservation systems of each hotel chain. A hotel chain that does not participate in this choreography of integration will miss the chance for the booking. Our traveler might order a car through Uber instead of a traditional taxi service. The physical car is booked through a digital service.

From the business side of the equation, it’s a totally different way of working. The changes described in the travel scenario are true for all businesses today. Your business is on the other end of these new consumer assumptions. In some cases, whole industries are being disrupted by digital change. Companies that embrace these sweeping technological changes are known as digital enterprises. It’s a reality that’s having an impact behind the firewall.

IntroductionMany companies today are remaking themselves as digital businesses. For some, such as retailers, becoming a digital business means enhancing an e-commerce site and adding a mobile shopping app. For others, the transformation may be more comprehensive. But, it’s essentially unavoidable. Advances in web and mobile connectedness have led to changes in end user habits. Consumers, employees, and partners simply expect a higher level of interaction with previously hard-to-reach back end systems and data.

Digital transformation puts added pressure on IT managers to integrate applications in the cloud. However, traditional, connector-based integration solutions, such as the Enterprise Service Bus (ESB) cannot keep up. The proliferation of mobile apps and new, third-party cloud-based software simply overwhelms the development cycle for new ESB connectors. Innovations in cloud application integration have kept up, though, with new approaches making possible a new level of speed and efficiency in cloud integration.

It is now possible to achieve secure, reliable integration of applications without relying on connectors at all. Connector-less cloud integration uses open standards-based APIs for flexible connections between software components both inside and outside the firewall. Developer communities are creating new standards-based APIs at a regular pace. This paper looks at how APIs can replace or supplement traditional integration technologies and enable a higher level of flexibility in the digital enterprise. It also draws attention to important aspects of connector-less integration that need management, such as security and API performance monitoring.

4page

WHITE


Some estimate that an enterprise today is facing potential integrations with between 300 and 800 cloud services – at least ten times the number of application integration points required just a few years earlier.

Now, as shown above the red line, there are numerous new cloud platforms, SaaS applications, mobile apps, and Internet of Things (IoT). These include applications running in Infrastructure-as-a-Service (IaaS) platforms such as Amazon Web Services (AWS) or Google Cloud, cloud file storage systems such as Box, and SaaS platforms like Salesforce.com. IT managers are dealing with requests to integrate with rapidly evolving applications hosted in any number of places: the public cloud, private clouds, on-premises data centers, partner data centers, and so forth. Some estimate that an enterprise today is facing potential integrations with between 300 and 800 cloud services – at least ten times the number of application integration points required just a few years earlier. There’s simply no way for the connector-based approach to integration to keep up.

Difficulties with Traditional Integration ApproachesTraditional integration approaches were adequate, though usually far from optimal, for managing application integration in the pre-cloud era. These approaches are not suited to the demands of today’s breadth of integration needs and pace of change.

Enterprise Service Bus

The ESB is too heavy a technology for integration in the cloud. The development cycle for creating or updating a connector can be 3-6 months. Most businesses today

The New Enterprise is FragmentedWith the customer becoming increasingly wired, the IT department is being asked to start making data and enterprise apps available for consumption by new classes of users and developers, including those who are making new mobile apps. At the same time, business managers are expecting new levels of data access and analytics. This creates even more demand for flexible connectivity between applications, data, and users.

Cloud Platforms

Data Services Packaged Apps Custom Apps

SaaS Applications Mobile & IoT Apps

75

Digital transformation is a process that involves connecting large numbers of applications, APIs, and web services along with massive amounts of data and storage. There are many new third party relationships, such as with external app developers. It’s a challenging situation for architects and IT managers. Figure 1 shows the issue, depicting how fragmented the enterprise has become. Below the red dotted line in the figure are the standards IT assets that most enterprises have: databases, web services, major packaged apps, and some custom apps. A few years ago, application integration required connecting these types of systems. And that itself was not easy.

Figure 1 - The fragmented enterprise of today, with the traditional architectural components shown below the red line and newer, cloud-based elements that need to be integrated above the line.

5page

WHITE


APIs Instead of Proprietary Connectors?There is now an alternative to the ESB and its proprietary connectors. APIs can serve the integration role, enabling “Connector-less Integration.” The SaaS offerings shown in Figure 2 all come with standards-based APIs, such as SOAP or REST. They need these APIs to

interface with mobile apps. Back end systems and data sources can also connect with these APIs, even if they are not equipped with REST-based API themselves. Many different technologies can be adapted to integrate with REST-based APIs. SQL databases, SOAP web services, and so forth, can be connected with applications in the cloud using APIs. No connectors are required. Most enterprises today have already exposed their back end systems through SOAP web services. And, the majority of data sources and packaged applications have SOAP web services available. These SOAP services do not need to change in order to effect connector-less integration with the cloud. Rather, it is possible to expose the SOAP services and SQL databases with adapters that form loosely coupled connection with a standards-based API in the cloud.

want new integrations in a matter of weeks. For some of the newer cloud platforms, there are simply no connectors available. It can take more than a year for some of the ESB vendors to release connectors that are in demand, if they are developed at all.

Connector-Based Integration Solutions

Cloud integration solutions, which are essentially cloud-hosted ESBs, offer some flexibility in deployment, but they suffer from all the same limitations as on-premises ESBs. They are heavy and slow to change. And, there’s less monitoring and control because they are managed by third parties. Being in the cloud doesn’t necessarily make it better. You can be dependent on cloud provider for your proprietary connectors.

Custom Cloud Integration Solutions

It’s understandable that people may want to take matters into their own hands and create their own custom-coded cloud integration solutions. However, this is not ideal for an enterprise that is trying to connect broadly with the multiplicity of cloud applications out there. Such an approach will inevitably stall.

Cloud Platforms

Data ServicesPackaged Apps Custom Apps

SaaS Applications Mobile & IoT Apps

75

Data ServicesTechnology Adapters with APIs-SQL,

nosql, File, SOAP, FTP, etc

Figure 2 - Technology adapters with APIs, including SQL, NoSQL, SOAP, FTP, and so forth.

6page

WHITE


API Hooks can be used directly by applications or in conjunction with other API Hooks to create integrations exposed as APIs. Sets of API Hook Integrations templates are available for common integration scenarios between various API Hooks. API Hooks and Integrations are meant to be open and shared with the community, allowing you full access and control to change the API Hook as your systems require.

The advantage of the open, community approach is it gives you the ability to change and share API Hooks on your own schedule. You don’t have to wait for anyone else. The process of creating an integration using the API Hooks is shown in Figure 4. After selecting the API Hooks you want to connect, you then select a binding (protocol), such as REST. Next, you may need to configure a transform, for example from SOAP to REST/JSON. Finally the new integration you have now created should have some policies associated with it. For example, authentication and authorization might be needed to ensure secure access. You might be using OAuth for third party access to data sources, and so forth. Once configured, the API Hook integration can be saved, exported and shared. The Akana API Gateway enables you to perform these functions.

Connector-less Integration Open API HooksAkana’s approach to connector-less cloud integration involves what we call “Open API Hooks.” An API Hook is an assemblage of elements that enable applications to connect easily in the cloud. It’s important to remember that an API on its own conveys almost none of the information needed to use it for effective application integration. The Open API Hook makes up for this deficiency.

The Open API Hook consists of an API described in an API Description Language, such as WSDL, WADL, RAML or Swagger; A pre-configured security policy that is required to invoke the API;A set of operational, compliance, and quality of service policies; And, an example integration API which leverages the API Hook.

Figure 3 depicts the Open API Hook as a three-pronged “plug” that allows applications to plug into APIs. Akana provides a community catalog of API Hooks for commonly used application. You can create your own API Hooks for your own on-premise or cloud systems and share them through the Akana community.

INTERFACE DEF.

BINDINGS

POLICIES

Figure 3 - The Open API Hook is like a plug that connects applications in the cloud. It provides interface definitions, protocol bindings, and policies for security, monitoring and so forth.

Points to APIs Select Bindings Configure Polices Save & Use Export & Import

Figure 4 - The process of creating integration between two or more applications Open API Hooks.

7page

WHITE


In this example, we leverage four API Hooks: One each for Smartystreets, Mailgun, Salesforce, and MongoDB. An API Hook has security set for invocation, so you don’t need to worry about it. You just enter the appropriate configuration information it requests. In this example, we are creating a new integration API called TrialLead API. The TrialLead API is where we perform the orchestration of the workflow described in Figure 5. Akana has common patterns for processes and scripting templates that are available to be used to orchestrate your workflow using Open API Hooks. You can also create your own patterns for processes and scripting templates. They are not closed or proprietary. You can open them up and change them as needed without waiting for new connector releases. Or, you can use the same hooks and scripts but connect them in a different order. You do not have to do much coding to make it work. Figure 6 shows the architecture for this connector-less approach.

Example: Trial Sign-Up Lead Management Scenario

As an example of connector-less integration, consider the workflow required to capture “free trial” leads off a website. Once collected, the integration and orchestration needs to place the lead data into Salesforce.com, into an email campaign system like Mailgun, and on-premises proprietary lead gen database.

Before the lead data is sent to these systems, the workflow calls for validating the street address with an external service called Smartystreet and validating the email with Mailgun’s email validation service. Leads with invalid address or email data get put into a MongoDB data store. If the address and email data is valid, it goes into Salesforce.com, and so forth. Figure 5 shows the workflow example.

A variant on this workflow might be one where the lead data enters through a mobile app used by salespeople. The workflow is the same but the entry point is different. The integration needs to be able to handle multiple, varied inputs and thus needs to be exposed as an API. That way, the workflow is agile – it can accommodate new devices easily.

Free Trial

1 Verify Street Address

2 Validate Email

VALID NOT VALID

VALID NOT VALID

3 Post To

Figure 5 - Reference architecture for lead capture workflow.

Figure 6 - API Hooks in the Cloud Integration Gateway.

Internal IP?

Y

N

N

Y

App Requires

2nd Factor

ValidateOne-timePassword

PermitAccess

DeniedAccess

Cloud Intergration Gateway

TrialLead API

8page

WHITE


ConclusionNew times call for new technologies. Today’s enterprise has become fragmented, with an overwhelming number of new devices and web platforms to connect with, all evolving at rapid speeds. The traditional ESB approach cannot keep up, both in terms of the development of adapters and the actual time and effort required to implement and modify the integrations. Using open standards-based APIs, it is now possible to execute highly complex cloud integrations of virtually any application – but no proprietary integration technology. The API, when used in tandem with integration gateways such as those provided by Akana, makes possible a new level of agility and rapid integration of diverse IT assets in multiple hosting environments: the cloud, on-premises, and hybrid. This kind of connector-less integration presents a new opportunity for enterprise agility. Using APIs, businesses can combine and recombine application elements at will, enabling them build and sustain lasting client relationships through technology.

Figure 7 shows an alternative data entry pattern that might be used in the business. If a user enters a lead directly into Salesforce.com, the data still needs to go to Mailgun and MongoDB. To make this happen, you can set up a “trigger” from Salesforce.com that calls a different workflow on the Trials Lead API. The workflow will leverage the same API Hooks and possibly reuse some of the same processing patterns and scripting templates, but just re-orchestrated.

Throughout this scenario, there are no proprietary connectors in use. The systems are connected using open APIs and an integration gateway that is based on open standards. The setup is infinitely more flexible and faster to change than an equivalent approach using an ESB or other proprietary application integration software. It can be extended in many new and different directions with relatively little work required.

Figure 7 - Alternative data entry path using connector-less integration. In this case, Salesforce.com triggers the “TrialLead” API.

Internal IP?

Y

N

N

Y

App Requires

2nd Factor

ValidateOne-timePassword

PermitAccess

DeniedAccess

Cloud Intergration Gateway

TrialLead API

Salesforce Trigger

Disclaimer: The information provided in this document is provided “AS IS” WITHOUT ANY WARRANTIES OF ANY KIND INCLUDING WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF INTELLECTUAL PROPERTY . Akana may make changes to this document at any time without notice . All comparisons, functionalities and measures as related to similar products and services offered by other vendors are based on Akana’s internal assessment and/or publicly available information of Akana and other vendor product features, unless otherwise specifically stated . Reliance by you on these assessments / comparative assessments are to be made solely on your own discretion and at your own risk . The content of this document may be out of date, and Akana makes no commitment to update this content . This document may refer to products, programs or services that are not available in your country . Consult your local Akana business contact for information regarding the products, programs and services that may be available to you . Applicable law may not allow the exclusion of implied warranties, so the above exclusion may not apply to you .


About Akana Akana is a leading provider of API Security and Management products that help businesses plan, build, run and share APIs, through comprehensive cloud and on-premise solutions that encompass API lifecycle, security, management and developer engagement. The world’s largest companies including Bank of America, Pfizer, and Verizon use Akana solutions to transform their business. For more information, please visit www.akana.com

Akana, API Gateway, Community Manager, Lifecycle Manager, Policy Manager, Portfolio Manager, Repository Manager, Service Manager, and SOLA are trademarks of Akana, Inc . All other product and company names herein may be trademarks and/or registered trademarks of their registered owners.

WHITE

Trademarks Akana, Policy Manager, Portfolio Manager, Lifecycle Manager, Service Manager, and Community Manager are trademarks of Akana, Inc. All other product and company names herein may be trademarks and/or registered trademarks of their registered owners.

Akana 12100 Wilshire Blvd, Suite 1800 Los Angeles, CA 90025 (866) 762-9876 | www.akana.com | [email protected]

Connector-ess Cloud /v P }v - Akana...Language, such as WSDL, WADL, RAML or Swagger; A...

Documents

Transcript of Connector-ess Cloud /v P }v - Akana...Language, such as WSDL, WADL, RAML or Swagger; A...