Friday, October 9, 2015

API Management as Hotel Receptionist

Metaphors are often used in API Management. Perhaps you're familiar with the airport metaphor (thinking of OAuth Access Tokens like boarding passes, thinking of an API Gateway like a security checkpoint), or traffic cop metaphors (for managing API traffic).

This neat API Management YouTube video has one I hadn't seen before - API Management as being like a hotel receptionist, issuing keys to the appropriate clients. 

Catch the full video here:

Friday, October 2, 2015

Slides from "Test & Protect your API" webinar with Axway and Smartbear now online

The slides from the recent webinar with Axway and Smartbear, on the topic of API Security, are now online.

It's noteworthy that while 56% of the attendees said that API Security was "very important", only 12% reported that they are doing extensive security testing of their APIs.

Tuesday, September 22, 2015

The Unbundling of Banking - Will banks be "Twilio-ed" ?

This week is API Days Open Banking and Fintech, appropriately taking place in London which is fast establishing itself as the financial technology capital of the world.

I'm privileged to be speaking on the keynote on Weds 23 on the topic of "Innovating at the Speed of Customer Expectation – Laying the Digital Foundation for Financial Services", and then taking part in a panel with Lloyds, Erste Bank, and BBVA about Banking API Strategies. 

One thing I'm sure which will be discussed at the conference is the so-called “unbundling of banking”. Banks are now competing with specialized fintech companies who generally do one thing, and do it well - e.g. rick analysis, or bitcoin blockchain services. Often they have an API into that service and operate as an "API First" company. 

Where has this happened before? The answer is telecoms. In the telecoms world, there is the example of Twilio, a classic "API First" company whose SMS API is very widely used. Just look at apps created at any hackathon, and you'll see how popular the Twilio API is (you'll often also see someone from Twilio there, which shows their investment in the API community). Telecoms operators have thus been disrupted by Twilio, and indeed some have launched their own SMS APIs in response.

Is there a danger that banks will also be "Twilio-ed"? Or is this a opportunity for banks to move, in the words of an architect I spoke to at a US bank recently, from a “Banking Products and Assets focus” to being a “Micro-service aggregator and networked value creator”. Can banks embrace these pure-play fintech services by aggregating and using them in their own "full-stack banking"? We see some brand new banks doing this - e.g. how Fidor includes now Bitcoin support through using the Kraken API.

In, Ron Shevlin argues for this, suggesting that the real value for banks is to create a “full stack”, which can include this aggregation of “single-stack” API-First fintech services. He makes the point that aggregating these services into a full-stack is easier than before:
Consumers need a full stack solution. But up until now, the only way to deliver that full stack was with proprietary service offerings and formal relationships between firms that determined who was or wasn’t in the service stack. Revenue-share agreements will make it easier for fintech startups to participate in full stack banks’ solutions, enabling a more open banking environment.
This echoes the Harvard Business Review piece by Bala Iyer and Mohan Subramaniam that "Corporate Alliances Matter Less Thanks to APIs", that APIs make it much more easy for these types of business relationships to happen (and indeed the HBR piece uses Twilio as a key example).

With banks bringing dedicated fintech services into their "full stack", through APIs, it leads to the question: Is the value in the aggregation, or in the service? Are banks at risk of becoming just “dumb pipes” (echoing what Martin Fowler describes in his Microservices vision: the real “smarts” are in the services). Are banks at risk of being Twilio-ed? Will there be specialists (e.g. for payments) and then aggregators can create a “virtual bank” by aggregating these specialists? Is Fidor leading the way?

I look forward to discussing all of these questions, and more, at API Days Banking and Fintech this week.

Thursday, September 17, 2015

Solving the Digital Business Puzzle Using APIs and Microservices - Axway and Forrester

When organizations make the choice to put a digital platform in place, a discussion on MicroServices is never far behind. By putting a MicroServices layer in place, an organization creates the springboard to launch into the digital future, whether that involves apps, rich Web clients, or IoT devices such as in-store beacons. Individual MicroServices, or orchestrated groups of MicroServices, serve as the foundation for this innovation. The data being passed to and from MicroServices also serves as the basis for behavioral analytics and Big Data, allowing organizations to tailor their digital services based on their users. But what are MicroServices and how are they used?

To answer this question, I'm pleased to say that next week we're running a webinar with Randy Heffner from Forrester, who is an expert on how APIs and MicroServices are used to deliver digital business.
Randy Heffner is VP & Principal Analyst at Forrester Research. He's a leading expert on designing business applications and software architectures that are secure and resilient in the face of continuous business and technology change, Randy has for the past 30-plus years, and across multiple industry sectors, led solution architects in using technology to delight customers and to continuously improve business outcomes. He is the author of some excellent papers on API Design and usage.

You can catch the webinar next Tuesday, September 22, at 11am Pacific, 2pm Eastern by registering here. We already have a large number of people signed up, and it promises to be a lively session with a lot of Q&A.

For people in Europe and the Asia-Pacific region, we're re-running the session on Thursday October 8 at 9am UK/Ireland, 10am Paris/Madrid/Berlin, 4pm Singapore & Chinese Standard Time. You can sign up for this October 8 session here.

What's old is new again

In many ways, MicroServices are not new, since they bring established principles to bear on integration. Martin Fowler has written extensively on Microservices, including componentization and services – topics which will be familiar to any architect deploying infrastructure over the last 15+ years. He writes about the centrality of events in a Microservices architecture, where MicroServices can subscribe to events from other Microservices. This event model brings to mind established best practice integration patterns. At Axway, we’ve also seen this trend with our customers, who leverage the inbuilt message queue in our API Gateway for such a publish/subscribe pattern between their services.

MicroServices also borrow from the worlds of SOA, DevOps, and Operations. Martin Fowler famously speculated that MicroServices may be “service orientation done right”. We see how MicroServices leverage SOA principles of separation of concerns, encapsulation, and loose coupling. From the world of DevOps they bring agility advantages including distributed development, automated testing, and continuous delivery. From the Operations world they bring the advantages of independently deployable components, load distribution, and parallel processing.

MicroService Aggregation

One way in which MicroServices diverge from SOA is in their implementation technologies. SOA was associated with a raft of WS-* standards. There was also, in the words of Martin Fowler, “the tendency to hide complexity away in ESB's”. Digital platforms are designed to avoid these pitfalls, by using REST and MicroService aggregation instead of an ESB. This is often described as "smart endpoints and dumb pipes"

Another aspect of MicroServices management is Operational Intelligence. The data flowing to MicrosSrvices, and being produced and consumed by their event model, can provide valuable behavioral analytics. This Operational Intelligence allows organizations to anticipate future trends and be agile to their customers’ needs. The data also allows bottlenecks to be detected and addressed.

I look forward to some great insight from Randy Heffner on the webinar - sign up and see you then!

Wednesday, September 16, 2015

Taking API Firewalling to the Next Level

One of the chief functions of an API Gateway is to act as an API Firewall. Many people are familiar with a Web Application Firewall (WAF), but may not be familiar with the concept of the API Firewall. You can think of an API Firewall as a "WAF++", because as well as blocking Web Application attacks such as SQL Injection, it must also block API-level attacks such as API Key replay attacks, or (for older style XML Web Services) the infamous XML Bomb. When I wrote my Web Services Security book back in the early 2000s, I didn't now that, today, attacks such as the XML Bomb would still be a concern.

In 2015, API Security is vital because APIs are the foundation of so much of the digital world. Randy Westergren has shown how APIs can be a weak link in Internet of Things (home automation systems in that case).  Troy Hunt has shown that APIs also are often the point of security weakness for mobile apps. Because API Security is an important topic, it's vital to drive awareness. With noted expert Gunnar Peterson, we've been publicizing API Security: you can view the Top 10 API Security Issues video, and read the associated White Paper on API Security here.  We're also pleased to announce new API Firewalling features in our API Gateway. We had a major announcement about these features this week. The new API Firewalling features include:
  • Built-in rules to implement best practices for protecting against common threats such as the OWASP Top 10 Attacks.
  • Support for ModSecurity-based rule sets to allow companies to leverage all free or commercial rules sets built by one of the largest communities of threat protection experts in the world. Companies can also implement their own ModSecurity-based rule sets.
  • Black- and white-listing rules to combine the best of both types of threat protection.
Adding support for ModSecurity is a big deal because it means that Axway customers can leverage the ecosystem of existing ModSecurity rules. As Alexei Balaganski of the analyst firm Kuppinger Cole notes in the release announcement, "By adding API Firewalling capabilities that can leverage existing rulesets from the Open Source ModSecurity project, Axway has further expanded the scope of API security and threat protection of their offering."

To further highlight the importance of API Firewalling, last week we did a joint webinar with Smartbear where we demonstrated API Firewalling in action (showing a vulnerable API being protected). You can view the recording of the webinar here.

We're also proud that Axway earned the distinction of “Leader” in KuppingerCole’s “Leadership Compass for API Security Management” analysis report (you can download a free copy of the report from the Axway Website). The report examined various vendors’ capabilities within the API security management market and Axway was positioned among the Leaders within all four API security management leadership categories.

There have been many API Security issues recently (including Buffer and the IRS). An API Firewall protects against these threats, which is so important in the new Digital age, when mobile apps and IoT depend on APIs. I look forward to more and more awareness of API Firewalling in the future.