Mobile Middleware for the Enterprise (part 1)

Introduction

With the trends of consumerization and bring-your-own-device (BYOD) acceptance, enterprises are increasingly seeking to securely integrate tablets and smartphones into their environments.  Meanwhile, external customers and partners desire mobile apps that provide on-demand, self-service alternatives to traditional consumer web portals.  Mobile middleware can ease this integration, providing a consistent framework and set of interfaces for a wide range of applications and data sources.  This is the first in a series of posts intended to help the enterprise IT buyer to better understand the benefits of mobile middleware, as well as to make an informed decision when choosing among the many products in this space.

Use case 1:  Employee productivity

Mobile devices bring the potential for ubiquitous access to corporate resources, providing employees with an “always-on” connection to the enterprise.  Email, calendar, and contacts are no longer sufficient for many enterprises – Line-of-Business applications with secure access to corporate data will further improve worker productivity.

While the first stage of mobile access was delivered using off-the-shelf software packages, the next wave will include much more custom code.  According to a November 2011 Forrester study, over 50% of enterprises rely on custom applications developed either in house or by externally-contracted developers.  These applications will require access to a mix of back-end services, from existing SOAP applications to newly-developed RESTful APIs, as well as cloud-hosted services such as salesforce.com.

app-sourcing

An established enterprise may already have an ESB for internal services, or they may be using loosely-coupled, point-to-point connections between apps and services.  Either way,the ESB likely was not designed with wide-scale or external connectivity in mind.  Mobile middleware can help to bridge this gap, providing a RESTful interface to legacy services and data sources.  It can also provide enterprise mobile application developers with a catalog of available APIs and documentation on how to consume them, speeding development and increasing consistency across applications.

Use case 2:  External access

Many enterprises have offered their customers a self-service web engagement portal for some time.  Whether it is used for commerce, basic account management, or other purposes, this portal ultimately connects back into enterprise services.  With mobile browsers taking an increasing share of page views, portals that deliver substandard user experience are being reimplemented as native enterprise mobile applications.

Mobile vs. desktop browser share, 2011-2012
Source: StatCounter

While the scope of services to be accessed by external users is typically much narrower than in the employee productivity use case, the scale and security considerations are much greater.  Also, digital natives expect integration with external identity providers, social networking, and other external cloud services.  As with internal-facing applications, mobile middleware can act as a glue layer for these customer apps, providing integration with external services while securing access to internal data.

The Case for Mobile Middleware

Regardless of which use case is the primary motivator for adopting a mobilization strategy, it’s clear that legacy web and data services are not readily consumable by mobile devices.  An enterprise, then, has two options:  remediate each service independently, or adopt a mobile middleware layer that can bridge the gaps to mobile access.  Development cost savings from the mobile middleware approach will depend on the number of services to be addressed and level of integration effort required.  However, by abstracting away these integration functions, enterprises can be assured that security policies are being uniformly implemented, enforced, and updated — no easy task if custom code is added to a large number of applications.

A mobile middleware strategy can address the issues shared by both of these use cases:  providing security and broad integration capabilities while delivering the performance necessary for a responsive user experience.

Other Resources

Over the next few weeks I will explore how mobile middleware can help an enterprise to integrate its own REST and SOAP services with 3rd-party APIs.  I’ll also describe some of the security and performance considerations that go along with different approaches.  Finally I will look at the options for application development that can benefit from the a consistent, RESTful back end.

In the meantime, here are some links to other material that should be useful when building a strategy for enterprise mobile applications:

Advertisements

API strategy & practice conference in NYC – Are you going?

Alright, I am sure you have heard this again and again but it’s worth saying it one more time. The first ever API strategy & practice conference is going be in NYC on Feb 21, 22 (http://www.apistrategyconference.com/). If you are just finding this out, it might be way too late for you to get in (But I will tweet anything interesting happening from inside 🙂 ).  There are 72 companies that are confirmed to participate and sending their API whiz kids, gurus, learners, teachers, procrastinators there to make a difference. Intel is proud to be a Gold sponsor to this event.

Yes, Intel. Not only does Intel do software, but they do it really well too. We have an outstanding API Manager that we released recently which will be showcased there. If you happen to attend this, please stop by my 2 speaking sessions/ panels.

Day 1: 2:20-3:30 – Track 3: API Security and Scalability

As APIs gain adoption they become ever more critical gateways to a company’s core business – ensuring access is secure and scalable are mission critical for your business. Presentations include:

  1. Paul Madsen (@PingIdentity) of  Ping Identity
  2. Mark O’Neil (@TheMarkONeill) of Vordel
  3. Travis Reeder (@treeder) of Iron.io
  4. Andy Thurai (@AndyThurai) of Intel
  5. Discussion panel on the challenges and solutions for API Security and Scalability

Day 2: 11.00-12.10 – Track 1: Mobile

APIs and Mobile are symbiotic – each driving the other with a good API strategy arguably key to a good Mobile Strategy. Presentations include:

  1. Andy Thurai (@AndyThurai) of Intel
  2. Max Katz (@maxkatz) of Tiggzi
  3. Marc Weil (@marcweil) of Cloudmine
  4. Miko Matasumura (@mikojava) of Kii
  5. Discussion Panel on the evolution of API / App Ecosystems and platforms

3Scale and Kin Lane did an amazing job of putting this together again (first time was cancelled thanks to hurricane Sandy). Hope to see you all there. Don’t forget to stop by our booth. You will get a chance to see me :), and win some goodies if you stop by and make your presence known, but more importantly you will get to learn about Intel API Manager.

Looking forward to seeing you all there.

-Andy Thurai (Twitter: @AndyThurai)

Enterprise Mobile Applications at Apps World

Apps World Focus on Enterprise Mobile Applications

My team attended Apps World in San Francisco last week.  The show almost could have been called “Mobile Middleware World”.  It was clear that we’re not the only ones who think 2013 will be the year of the Enterprise Mobile App.  While the conference had plenty of independent developers and consumer-oriented tools, many of the folks stopping by our booth were focused on the enterprise.  We received several questions about our solutions for enterprise mobile applications and API management.  API providers were also bridging the gap between consumer- and enterprise-grade services, with talks and demos both days from StackMob, eBay, Box, and SendGrid.

Intel is a Software Company?

We received a number of questions related to our API management products.  Once we got past the initial question of “Intel is a software company?“, it was clear that our vision for mobile middleware is well-aligned with what developers of enterprise mobile applications are seeking.  We received positive feedback on the end-to-end capability we offer:

  • Secure and robust API management on the back end
  • Best-in-class API discovery and developer onboarding through our connection to the Mashery portal
  • HTML5 and Appcelerator provide flexible app development on virtually any device.

Digital Payments and Enterprise Mobile Applications

One of the bigger trends I saw had to do with digital payment systems.  This is a rapidly-evolving area, with virtual currency moving from games into other apps, potentially expanding into enterprise mobile applications.  Other payment systems, such as digital wallets and P2P, seemed to be top-of-mind as well.  It’s clear that mobile application and API security will be critical for success, regardless of which standards win out in these areas.

Building the Enterprise Mobile Application Factory

Also in our booth, Kin Lane gave a very popular talk on Building the Enterprise Mobile Application Factory.  If you missed his talk, it is available online.  Our HTML5 development talk was also very well-received, with many participants signing up right away for our cloud-based HTML5 developer tools.

It is shaping up to be an exciting year for us in the enterprise mobile applications and API management space.  Apps world was just the beginning.  For more information, stay tuned to this blog, follow us on twitter at @IntelAPIGateway, download our whitepaper on API Patterns for Cloud & Mobile, or check out some of our mobile middleware tutorials.

Who's a SOAsaurus?

Image of a dead dinosaur

I told you I was ill.

The phrase “Don’t be a SOAsaurus” is being bandied about on twitter and the like and it got me thinking about using that particular analogy to describe SOA Web Services practises and contrast them with the clever little RESTful API Service mammals that maybe saw off the big, ugly lizards.

Before getting into computing I did spend some time in Geology so I’m coming at this argument from a slightly odd standpoint. For any Geologists reading I was structural, ophioites and terrain docking. We used to look down on this palaeontology stuff and everyone looked down on the geophysicists.

To recap the dinosaurs then. We know them from the fossil record. To become a fossil is a one in a bazillion chance so there have to be a lot of you about. By definition any fossil you find must have come from a wildly successful species. So SOAsaurus must be some form of compliment. On top of that, dinosaurs (as we commonly refer to them) lasted over one hundred million years, dominated the land, sea and sky AND gave birth to the mammals. By that analogy REST wouldn’t be here but for SOA. In the same way SOA has had it’s time in the press and still continues to have it’s time in enterprise. Fully half of the enquiries Gartner specialists like Paolo Malinverno get are from people working on SOA, installing service based architectures XML and developing new services.

The analogy extends to our RESTful mammals as well. At night they had the advantage of heat to go out scavenging dinosaurs and stealing eggs. In the same way I see technologies scavenged from SOA; sledgehammer to crack a nut UDDI re-emerges as API portal, WSDL starts to emerge as WADL. Vendors see that the wheel is being reinvented so technologies like service and security gateways extend their functionality to encompass both worlds.

When the dinosaurs did go it had taken the combined effects of millennia of climate change from the volcanic eruptions forming a decent portion of what is now India plus the impact of a meteorite big enough to form a 200km wide crater. That was big enough to wipe out two thirds of all species on the planet. It reminds me of a major UK banking group I’ve worked with whose mainframe still ran on token ring and used a protocol older than I am! Big, successful technologies are hard to kill off for several reasons, primarily they work for the frame of reference they were put in for. We’ll be living with SOA practices running organisations for many decades yet.

But maybe I got the analogy wrong. REST isn’t the mammal after all and the dinosaurs never died out. They survived by ditching the weight and becoming more agile with less in the way of teeth. In the same way its not hard to imagine why developers want to get rid of the stack of J2EE, XML, SOAP, WS-ReliableMessaging, WS-PolicyForSecureReliablePolicyIdentityFederationPolicy…. REST represents the birds and one’s about to crap on your shoulder sometime soon.

I think I agree with SOAsaurus, I like the term. SOA gets to live as Argentinosaurus, Compsognathus or Protoceratops. REST could be Albatross, Turkey or Penguin (okay, now I’m poking fun). As Archaeopteryx was no doubt fond of saying; there’s room for a bit of both.

Of course this is all fine discussing the mammals and the dinosaurs but its the bacteria that use us and let us live in the end. Any suggestion as to the computing equivalent?

Whether you’re a SOAsaurus seeking SOA governance, are looking to evolve using REST/SOA mediation, or are already walking upright with REST and need to manage APIs, we’ve got you covered.

Follow me @PeteL0gan uk.linkedin.com/in/petelogan/.

Are you building your APIs the right way?

I keep telling my customers, it is not about what you think is important but it is about what your customers (internal, external or partners) see as important when it comes to building APIs and mobile apps, or APIs for mobile apps. This article from Intel explains the facets of WHO, WHAT and HOW very nicely. We instituted a new practice called Intel API Manager which does all of the above and more. It includes a strategy session to identify the audience (WHO) that can benefit from this, WHAT are the channels that can drive additional revenue, and HOW we can help you achieve that.

http://software.intel.com/en-us/blogs/2013/01/28/taking-your-app-to-market-the-who-what-and-how-of-your-mobile-app-marketing

And, yes Intel does software!  – and very well too!

-Andy Thurai (Twitter: @AndyThurai)

Are you PCI DSS compliant yet? What is stopping you?

The PCI tokenization solution show case at NRF was a grand success. I never would have believed the traffic through our booth and the interest. First of all, the show was huge!!! I am not kidding. Last year the attendance was 25,500 (http://www.nrf.com/modules.php?name=News&op=viewlive&sp_id=1302) and I am pretty sure this year they surpassed that. (Last count puts it at 27,600)NRF show

Intel had a big booth there and predominantly displayed was our PCI tokenization solution. The reason why our solution gained much visibility is, as one customer put it, you provide compliance and risk mitigation in one place.

The most effective PCI tokenization solution MUST have:

  1. Have the ability to create a security story NOT just a compliance story (I will blog about this later). In other words, not only reduce PCI scope but helps you protect card holder data
  2. High speed, high performing tokenization solution that is a capable of producing 10s thousands of tokens in a second, if needed
  3. A hardware based true random token generator
  4. Capable of producing upwards of 2 B tokens to scale up
  5. Proxy tokenization method without a need to touch any of your existing systems
  6. Not only the solution should be able to “automagically” detect PAN numbers but also allows you  to preserve certain digits for routing, identification purposes on needs basis
  7. Allow you to use tokens as a surrogate for the original credit cards every time – “multi-use” tokens
  8. Allow you to either BYOD (Bring your own Database) or use an extra hardened, highly secure database provided for you
  9. Can handle data in any format and in any incoming channel
  10. Secure enough to do the tokenization in DMZ if needed
  11. Can work anywhere within enterprise, extended enterprise, including partner locations or virtual environments such as in the cloud

Checkout Intel’s Tokenization Buyers’ guide on how to do this the effective way.

Elastic Scaling of APIs in the Cloud

As an Enterprise Architect for Intel IT, I worked with IT Engineering and our Software and Services group on the elastic scaling of the APIs that power the Intel AppUp® center. Our goal was to scale our APIs to at least 10x our baseline capacity (measured in transactions per second) by moving them to our private cloud, and ultimately to be able to connect to a public cloud provider for additional availability and scalability. Here’s a quick set of practices we used to achieve our goal:

  1. Virtualize everything.  This may seem obvious and is probably a no-op for new APIs, but in our case we were using a bare-metal installs at our gateway and database layers (the API servers themselves were already running as VMs). While our gateway hardware appliance had very good scalability, we knew we were ultimately targeting the public cloud and that our need for dynamic scaling could exceed our ability to add new physical servers.  Using a gateway that scales in pure software virtual machines without the need for special purpose-built hardware helped us achieve our goal here.
  2. Instrument everything.  We needed to be able to correlate leading indicators like transactions per second to system load at each layer so we could begin to identify bottlenecks. We also needed to characterize our workload for testing – understanding a real-world sequence of API methods and mix/ordering of reads and writes. This allowed us to create a viable set of load tests.
  3. Identify bottlenecks.  We used Apache jmeter to generate load and identify points where latency became an issue, correlating that against system loads to find out where we had reached saturation and needed to scale.
  4. Define a scaling unit.  In our case, we were using dedicated DB instances rather than database-as-a-service, so we decided to scale all three layers together. We identified how many API servers would saturate the DB layer, and how many gateways we would need to manage the traffic. We then defined a collection of VMs that would provision all of these VMs together. We might have scaled each layer independently had our API been architected differently, or if we were building from scratch on database-as-a-service.

    Example collection for elastic scaling

  5. Repeat. The above let us scale from 1x to about 5x or 6x without any problem. However, when we hit 6x scaling we discovered that a new bottleneck: the overhead of replicating commits across the database instances. We went back to the drawing board and redesigned the back end for eventual consistency so we could reduce database load.
  6. Automate everything.  We use Nagios and Puppetto monitor and respond to health changes. A new scaling unit is provisioned when we hit predefined performance thresholds.

    Automation/Orchestration workflow

  7. Don’t forget to test scaling down.  If you set a threshold for removing capacity, it’s important to make sure that your workflow allows for a graceful shutdown and doesn’t impact calls that are in progress.

The above approach got us to 10x our initial capacity in a single data center. Because of some of our architecture decisions (coarse-grained scaling units and eventual consistency) we were then able to add a GLB and scale out to multiple data centers – first to another internal private cloud and then to a public cloud provider.