Ronnie Mitra

Ronnie Mitra

Ronnie Mitra is an expert in enterprise development and integration who leads Layer 7’s API Architecture & Design Practice across Europe. In this role, Ronnie helps companies leverage their burgeoning API potential. Before joining Layer 7, he worked at IBM where he held the worldwide leadership role for WebSphere connectivity products.

October 15th, 2012

API Workshops in Europe

Paris API WorkshopI had a great time presenting on API design and management trends at our London API Workshop a few weeks back. James Governor from RedMonk delivered an exciting talk on APIs, the need for API Management and some stark truths, like the fact that Java is still at the top of the programming pile. All of the trend talk and analysis was followed by a great real-world example when MoneySupermarket.com’s Cornelius Burger described his organization’s journey implementing the MoneySupermarket API with a SecureSpan API Proxy. We had excellent feedback on the event, so I know I wasn’t the only one who learned a lot from our speakers.

I was particularly impressed by the range of industries and organizations that were represented in the audience. We had developers from large enterprise shops, specialized Internet-focused start-ups and even a few entrepreneurs just getting started. I think this range of interest is indicative of the value of Web APIs for all and bodes well for a continued investment in designing great APIs, rather than just chucking them out into the ether.

Next up on the tour is our Paris API Workshop taking place tomorrow (Tuesday, October 16).  As always, we have a great set of speakers lined up, with Martin Duval from bluenove talking about building developer outreach programs and Benoit Herard from Orange Labs discussing their API launch. France has a  great start-up culture and a reputation for enterprises like Orange driving innovation, so I’m expecting good conversation, some excellent API Management presentations and – if I’m lucky – some great wines.

September 17th, 2012

Web APIs are International

APIs are GlobalI had the great fortune of spending last week in India, helping a Layer 7 customer develop a Web API program from scratch. While it’s always exciting to walk into a greenfield situation and build something new, I was doubly excited to be doing this in India, where the concept of open APIs is still fairly new.

Over the last few years, we’ve seen explosive growth in open APIs across North America, lead of course by the avant garde Internet companies on the West Coast. The API Management industry has focused much of its attention on the US market but the Web API movement has definitely made its way to other markets and the push towards mobile and device-based applications is clearly having an influence on enterprise architectures.

Western Europe has had a strong influence on the API scene, with notable government and enterprise organizations diving wholeheartedly into the collaborative, developer-focused open API space. London, in particular, has developed a thriving technology scene with tons of hackathons, codeathons, meetups and start-up companies trying to change the world or at least get rich trying.

At the moment, the open API scene in India is still in its infancy and I’m looking forward to helping the concept blossom in whatever way that I can. As you may be aware, the number of mobile devices being used in India is mind-boggling and the ratio of mobile-use-to-desktop-computing is much higher than in North America or Western Europe.  This quantity of mobile client platforms, combined with the large number of motivated developers on the scene, makes this a very intriguing open API marketplace. I can’t disclose any details on the nature of the project yet… but I’m hoping to to have exciting news to share in the near future, so stay tuned.

I’ve spent most of the summer in North America, for a variety of reasons and I’m excited that I will finally be getting back home to the UK so I can re-engage with the European API and mobile scene. We have some great Layer 7 API workshops scheduled across Europe over the next few months and hopefully we will uncover a few new and noteworthy European API publishers while we are on tour.

August 7th, 2012

Using WebSockets – Part 1: Minding the Gates

HTML 5 and WebSocketOne of the most exciting features introduced with HTML5 was support for WebSockets. The WebSocket protocol has been through a lot of churn over the last two years, with browser vendors desperately trying to keep pace with changes in the specification. Thankfully, the standard has now become stable enough to be utilized in enterprise projects.

The beauty the WebSocket protocol is that it lets an application seamlessly move from an HTTP/Web-based flow into a socket-based conversation and then back to a Web-based flow. In this way, it allows Web- and mobile-based applications to easily move from the traditional request-reply HTTP world into new forms of full-duplex, bi-directional communication.

We’ve seen a similar evolution in the past within the message-oriented middleware world. With the emergence of SOA and API, enterprises realized they needed new ways of moving data around and middleware technologies emerged that facilitated the movement of data in ways that were not possible with existing request-reply synchronous messaging infrastructures.

Traditionally, Web and mobile applications had to work hard in order to send or receive real-time data. Now, developers can use WebSocket to move data up and down the communication channel quickly and efficiently. This is like moving from an email client that requires you to constantly check for new mail to one that instantly alerts you when a new email arrives.

This style of communication will provide enormous benefits for applications that require messages to be passed quickly between the client and server.  Architects will have an easier time building applications with real-time messaging requirements, opening the door to some very intriguing solution designs.  Targeted notification systems, more-responsive UIs and even complex architectures such as massive grid networks built on top of the Web will be much easier to implement properly.

But, what’s missing from the WebSocket story is an effective way of minding the gates. The “black hat” guys already see WebSockets as representing a new attack surface, so organizations that are serious about providing reliable, scalable solutions will require some form of Gateway on the server side, to guard against security breaches.

To address WebSocket security, a Gateway must be able to enforce SSL handshakes, limit the number of connection requests, protect against payload injection attacks and enforce strong authentication methods – the same set of attack vectors that exist for SOAP/XML Web services and REST/JSON APIs.

That’s why I’m particularly excited about Layer 7′s recently-announced SecureSpan Mobile Access Gateway product. The Mobile Access Gateway extends Layer 7’s industry-leading technology for SOA and API in order to address mobile-specific concerns – and it includes a very secure WebSocket implementation.

In addition to the security benefits, the Gateway can be used to enrich or filter data in real-time. This opens the door to a new set of compelling use cases that includes data auditing, image watermarking and blacklist filtering – possibilities intriguing enough to stand on their own as justifications for implementing a WebSocket Gateway.

So, we’ve discussed what the WebSocket protocol is and why it’s so important to keep WebSockets secure. But how does all this fit into the exciting world of APIs that we’ve been focusing on in many of our recent blog posts? Our Principal API Architect Mike Admundsen will tackle this question next week, in our continuing series on this very important protocol.

July 12th, 2012

Are Open APIs Too Open for Big Business?

Written by
 

Twitter and Facebook APIsI’ll admit it.. I’m a “big enterprise” guy.  I’ve either worked for or worked with very large enterprise organizations for most of my career and I’ve seen these companies struggle with the challenge of  incorporating ideas that are spawned from the collective brain trust of the theorists, coders and entrepreneurs that exist in the chaos outside the enterprise’s doors.

It took time and some adaptation for concepts like open source software, social media integration and viral marketing to become part of the enterprise world and I believe that opening up Web APIs will require a similar shift in mindset to work on the enterprise stage. The biggest ships take the longest to turn but modern businesses (even the most risk-averse) must be open to leveraging new technologies and architectural philosophies in order to avoid being left behind.

The buzz around Web APIs has definitely piqued the interest of big business and large enterprises have dipped their toes into its waters with the release of a few compelling APIs over the last year.  But, along with the excitement generated from opening new consumer channels and new avenues for innovation, there is still a  prevailing sense of danger associated with the API movement.

For many enterprises,  there is a fear that publishing APIs means giving up control of their services and data to an army of anonymous 16 year-old mobile developers. After all, who wants their carefully crafted brands and products to end up at the mercy of the masses? We’ve seen marketing experiments with “crowd sourcing” produce some interesting results in the past, so there is reason to be cautious when opening up the doors for collaboration in any form.

Of course, the good news is that the challenge of controlling APIs can be elegantly addressed with a strong API Management system. At Layer 7, our SecureSpan API Proxy gives enterprise customers the tools they need to maintain control over how content and services are used, allowing publishers to lock down APIs as much as they want.

However, publishers will also need to ensure that they provide enough accessibility to their API libraries or they will run the risk of exposing wonderful APIs that sit unused, waiting for developers to utilize them. APIs are only useful when they are used and a closed-door policy will not encourage anyone to sign up. That’s why we also offer the Layer API Portal, which is designed to facilitate developer community outreach and secure developer onboarding.

Making APIs attractive to the developer community is the key to increasing usage and it is becoming clear that developers want stability and control in the APIs they use. For example, Twitter’s continued restrictions on API usage and Facebook’s closure of the face.com face recognition API have created a small wave of backlash amongst their developer communities. While it’s not enough of a storm to make much of a dent in the uptake of Twitter or Facebook APIs,  application developers are realizing that building their apps based on APIs from which they may lose access is ultimately a losing proposition.

This is good news for larger enterprises as it signals a growing level of maturity in the API market and the need for stable, fairly-priced APIs that can support apps in the longer term. A set of well-designed, secure APIs with a well thought out revenue model is exactly the right fit for the large enterprise world.

So, are open APIs too open for enterprises? Probably. But enterprises will need to adapt or risk being unable to reach their customers as the device revolution continues at its explosive pace. Conversely, launching a poorly-designed API library just to get it out there can be an equally devastating misstep. Organizations need to think carefully and plan their API strategies in order to find the perfect balance between control and accessibility.

It isn’t easy for enterprises to embrace open APIs but when the risks are managed properly with a well-built API Gateway, developer portal and API strategy, the rewards can be immense.