With the steady decline of the PC business, Intel clearly has to look elsewhere for its future growth. The cloud datacenter is not a bad place to start. Cloud server farms clearly consume lots of processors. Still, servers powering Web sites can operate fine without APIs, thank-you. But servers powering mobile is a different story. Mobile apps (whether HTML5, hybrid or native) get the data that makes them valuable from applications that reside in datacenters. And APIs are the key to letting cloud data be sharable with mobile apps.

Clearly, app-centric “smart” phones and tablets and TVs and cars and watches and glasses are changing the way we go about our daily business. And APIs will power these smart devices by giving enterprise and Internet companies a way to push their data to apps. That hope of bridging the cloud with mobile is probably why Intel has kept its current API product intact. Mashery broadens Intel’s API scope by providing a way to not only share data with mobile apps but now also the developers that build these apps. But will this plan succeed?

If it does, it will take quite a bit of time. The reality today remains that Intel – even despite the semi-recent McAfee acquisition – is not oriented to selling software or even cloud services into the enterprise. It’s missing the sales force. It’s missing the history. And in many ways, it’s missing the rest of the software stack it needs to power the networking, infrastructure and application parts that underpin data in the cloud. That will make selling an API platform comprising a legacy API Gateway and newfound API developer platform a harder proposition. It’s kind of out there alone.

Another obvious roadblock to making the Mashery acquisition successful is that Intel’s existing API Gateway and the Mashery API service are designed for two very different audiences inside the enterprise, with un-reconcilable needs. The API Gateway is designed for an IT department that wants to run its API Management layer in its own datacenter. The Mashery offering is designed for a non-IT buyer (a mobile program manager, say) who wants to run everything in someone else’s cloud.

One is technical, the other is not. One is on-premise, the other is SaaS. One sells traditional software licenses, the other pure subscription. The first aims to address internal and external API integration challenges. The latter is only really concerned with the challenge of acquiring external API developers (though Mashery would probably protest this point).

Will the two be a marriage made in heaven? Given that the Intel/Mashery partnership is already a year old and that Mashery was barely able to grow its revenues in that time, the likelihood seems remote. But who knows for sure? And anyway, Intel has probably not bought Mashery for its $12M in revenue but for its long-term potential as a pathway to mobile.

But do interfaces hosted on AWS and exposed to third-party developers contain significant vulnerabilities? Cloud services allow third-party access to applications and data through APIs. Failing to properly secure that access can put the data and applications at risk. So, how do you safely expose APIs in a cloud environment?

Understanding the cloud API model isn’t always easy. So, on January 29, we’re having a live discussion about publishing APIs in the AWS cloud, which may help answer questions surrounding exposing APIs in cloud environments. I’m excited to welcome Layer 7 Technologies Senior Software Developer Hirbod (Rod) Moshfeghi as our special guest for this API Tech Talk. This is a great opportunity to have your questions answered and to discuss the implications of publishing cloud-based APIs.

Here’s how to join the live discussion…

On the day of the event, click here to join:

• layer7.com/live

Submit your questions:

• Tweet using the tag #Layer7Live
• Email techtalk@layer7.com

Of course there will always be a place for a little more talking and I’ll be doing some of this myself as part of the CES panel Privacy & Security in the Cloud. This discussion will take place on Monday Jan 7, 11am-12pm, in LVCC, North Hall N259. The panel is chaired by my good friend Jeremy Geelan, founder of Cloud Computing Expo, who honed his considerable moderation skills at the BBC.

I’m planning on exploring the intersection between the cloud and our increasingly ubiquitous consumer devices. We will highlight the opportunities created by this technological convergence but we will also consider the implications this has for our personal privacy. I hope you can join us.

In order to optimize the performance of mobile apps or browsers, some computation-heavy functions have been offloaded to cloud-based resources, which in turn access backend resources and Web pages. This creates a middle ground in the cloud that is exploited in the attack, which the authors call “Browser Map Reduce (BMR)”. In reading the paper, it’s clear that this is a legitimate threat. The authors actually carried it out using free resources, although they limited the scope in order not to be abusive.

Aside from questions of curiosity around the mechanics of the vulnerability, the obvious question is this: How can we mitigate this threat? Here are a few perspectives here as well as a method for each.

Apps – This “cloud offload” architecture has arisen because of the processing limitations of mobile devices. When a backend resource is requested by a mobile user, it makes sense to have the data returned in the most consumable format, in order to optimize user experience. Whenever possible, instead of doing this through “browser offload”, data should be returned as JSON objects. This API approach is a proven method that works for mobile devices and is not subject to the BMR threat.

Cloud Services – This threat should not be viewed as a dismissal of the “cloud offload” approach. Cloud-based resources are necessary for handling caching, data indexing and other key functions in the mobile paradigm. However, it serves as a warning that these dedicated cloud-based resources cannot be considered part of a walled garden that includes the associated mobile app. The resource’s entry point must be protected against attackers. Layer 7’s SecureSpan Mobile Access Gateway is an ideal choice for this access control, as it uses identity-based measures to ensure that only requests from legitimate sources are serviced.

Web-Based Resources – Although the backend Web resource was not exploited in this scenario, the study is a reminder that the topology of the mobile Web is changing and increasing in complexity. P2P app-to-API connections cannot be assumed and therefore inbound API calls cannot be implicitly trusted. API access must be controlled and the SecureSpan API Proxy is a leading solution for this purpose.

To sum up, this is a legitimate threat but not a reason to abandon the use of cloud-based resources for mobile app optimization. Be aware of the threats, employ the mitigations and then you can continue to enjoy the exciting growth of the mobile Web.

Building cloud- and API-driven mobile apps introduces complex challenges around syncing, caching and securing data. So, connect live with Layer 7 on Tuesday November 20, at 9am Pacific Time, when Alex will be answering your questions about how to address these challenges. Alex will also provide insight into a range of related best practices, including techniques for building cross-platform applications in HTML 5.

Click here to get the full event details and a reminder in your calendar. On the day of the event, join the event at layer7.com/live and tweet questions to #layer7live.

But let’s say you’re not a bad-ass consumer app developer. Imagine you’re a mild-mannered enterprise dev looking to make a solid app for your field sales organization. What does MBaaS do for you? Maybe the right question is what does MBaaS not do for you? Answer: it doesn’t get you access to the one thing you need as an enterprise developer – enterprise data.

Enterprise apps need data like plants need sunlight. It could be customer records, documentation, pricing information, inventory levels or a myriad other things. But that data is stuck in the enterprise, inside of SAP this and SharePoint that and database the other. No amount of simplifying interactions with AWS will get that information into your hands to build the super-compelling apps employees need access to.

Enter mobile middleware like Layer 7’s SecureSpan Mobile Access Gateway. Getting the stuff that’s locked inside the enterprise into the hands of devs is a middleware problem. It’s about information sharing. It’s about opening up but in a very targeted manner. MBaaS has some great ideas for making a mobile developer’s life easier. Enterprise devs want the same benefits but with the added benefit of access to enterprise data. I joined Layer 7 from a prior gig at RIM to help that happen. Stay tuned for details.

For the Layer 7 perspective on these service technology trends, come see our presentations throughout the week. On Monday, I’ll be speaking about how traditional SOA technologies such as the enterprise service bus (ESB) need to adapt to an evolving IT landscape. On Tuesday, our CTO Scott Morrison will be giving a closing keynote about “The New Governance”.  Wednesday brings an API Management Workshop at the Canadian High Commission, hosted by Layer 7 along with our customer MoneySupermarket.com and analyst firm RedMonk.

Layer 7 is a Founding Partner at the Symposium and we’re excited to welcome a who’s who of analysts, vendors and enterprises to join in the conversation. These illustrious attendees have helped to define the industry and revolutionize enterprise IT – and I’m looking forward to insightful speakers and great networking opportunities. For a more intimate conversation, stop by our booth (#110) to see a demo or discuss your SOA, cloud, API or mobile use cases.

London has shown an incredible amount of enthusiasm for sporting events this summer, from the Olympics and Paralympics to the Tour de France, which was won by a Brit for the first time in its history. Let’s keep that excitement going – see you at the Symposium!

The importance of APIs continues once the infrastructure is in place. Applications in the cloud can expose their own APIs, opening data access to partners, mobile devices or other cloud technologies. This raises questions around how enterprises can effectively leverage cloud APIs while addressing the security and management concerns that will inevitably arise.

I’ll be discussing some of these concerns when I take part in Layer 7’s latest Tech Talk on Tuesday September 4 at 9am PDT/12pm EDT/5pm BST. The subject matter will be Publishing Cloud APIs and – like all our Tech Talks – this interactive Q&A will be broadcast live on the Layer 7 Facebook page and via Livestream.

Here’s how you can join the conversation:

• Tweet using the hashtag #Layer7Live
• Email techtalk@layer7.com
• Check in & Chat through Facebook

Feel free to ask questions around:

• Securely exposing APIs from a cloud-based solution
• Orchestrating APIs for value-added interfaces
• Enforcing access control and threat protection across hybrid cloud environments

I’m looking forward to chatting with you. Don’t forget to add the Tech Talk to your calendar. See you on Tuesday!

Rapid deployment and onboarding has always been a key requirement for Layer 7 solutions, which is what initiated our strong partnership with VMware years ago. These announcements will showcase the next step in that evolution.

Layer 7 will be presenting at the VMworld Solutions Exchange and we’d love for you to stop by to talk about how we take advantage of the latest VMware technology. Come discuss your use case and find out how we can:

• Protect and manage vCloud APIs
• Securely expose APIs from a vCloud-based solution
• Govern infrastructures based on the vCloud Architecture Toolkit (vCAT)
• Orchestrate APIs for value-added interfaces
• Dynamically provision vApps from policy based on SLAs
• Enforce access control and threat protection across hybrid cloud environments

We’ll also be giving demonstrations of our VMware Ready certified products, including the SecureSpan Mobile Access Gateway and Layer 7 API Portal. In case you can’t catch us on the west coast, we’ll also be at the VMware Forum in Toronto on September 20.

Therefore, I had to do all the things an active developer regularly has to do (coding, debugging, testing etc.) from a device that has no appreciable hard-drive space and does not allow the installation of any customer software. In essence, I was on a strict diet of browser-based and plug-in based tools and services reachable via an Internet connection.

In relatively short order I was able to find browser-based editors (even ones that support line-by-line server-side debugging!), tools for managing data stores and code repositories. Furthermore, I was able to post test scripts for execution/review and even deploy my projects to a wide range of server providers – all from my browser.

Along the way, I discovered that I had an easier time collaborating online with colleagues in other locations and was better able to take advantage of the most recent releases of new services and tools (since there was no “install” or “update” I had to manage). And – of course – I was more mobile in the process.

Not all programming languages, runtime environments and server profiles are represented in the cloud. And there are still many details to work out in order to make assembling a full-featured “cloud tool chain” easy, reliable and cost effective. Nevertheless, I can see that it is a possibility and I have met people who are working to make that possibility a reality.

My advice to developers would be: Conduct your own experiments; try out your own “cloud-only diet” and see what you learn. Even if you decide that not all the pieces you need are available, you may still discover there are ways to leverage cloud-based tooling to reduce barriers, add flexibility and increase productivity in various aspects of your development efforts.

I’ll be exploring these issues in greater depth when I present a talk titled Programming with the OSS “Cloud Stack” at the CloudDevelop show in Columbus, OH on August 3.