The Well-Designed API

We have worked with many APIs here at Layer 7. And over time we’ve seen it all, ranging from the good to the bad. We even see the downright ugly. Now a good API is a beautiful thing; it encourages innovation, abstracts appropriately, and is designed with enough forethought that nobody needs to change it down the road. Resiliency is a good quality in an API. APIs are a little like cockroaches in that they will likely outlive the human race.

But what about the other ones? The ugly and bad ones? This is where developers could use some guidance.

Truth is, good API design isn’t really hard, but it’s not easy. One thing I point people to is Leonard Richardson’s Maturity Model for REST, which Martin Fowler explores in his blog. Now I’m not a REST purist by any means—truth is I’m as guilty of quick-and-dirty HTTP tunneling hacks as the next guy—but when you see the maturity phases laid out so succinctly, you can’t help but be inspired to move toward more “resourceful” thinking and maybe even learn to love HATEOS. Part of good API design is knowing what you should aspire to, and Richardson’s model is much more concise and accessible than Fielding’s thesis.

Another good source of advice is Joshua Bloch’s superb Google Tech Talk How to Design A Good API and Why it Matters. Bloch wrote what is arguably the most important book about Java ever written, and indeed his talk is about APIs using Java as the model. But don’t let that deter you; virtually everything Bloch discusses is as relevant to RESTful JSON-style APIs as it is to Java. Follow his advice, transpose it to you language of choice, and frame it with an understanding of where you want to land in the maturity model for REST, and you will end the day with great APIs.

Advertisements

Developers, Developers, Developers – Why API Management Should be Important To You Featuring RedMonk

It’s about developers again.

Everything in technology goes through cycles. If you stick around long enough, you begin to see patterns emerge with an almost predictable regularity. I actually find this comforting; it suggests we’re on a path of refinement of fundamental truths that date back in a continuous line though Alan Kay to Turing and beyond.

The wrong way to react to technology cycles is with the defensive-and-crusty “this is nothing new kid—we did it back in ’99 when you were stuck in the womb.” Thanks for nothing, Grandpa. A better approach is to recognize the importance of new energy and momentum to make great things happen.

The cycle that really excites me now is the new rise of the developer. Trying my best not to be crusty, there is a palatable excitement and energy out there that really does feel like it did in 1999. After years of outsourcing, after years of commoditization, developers matter again. A lot. It’s like the world has rediscovered the critical importance of this fundamentally creative endeavor.

This is a golden age of technology and possibility, one that is being driven by new blood and newer technology. The catalyst is the achingly perfect collision of cloud, mobility and social discovery with APIs, node.js, Git, NoSQL, HTML5, massive scalability… (I really could go on and on here).

Most of all, I’m excited by movements like Codecademy. This simple idea perfectly reflects the tenor of the time in which we live. People are no longer afraid of making things easy. The priesthood is gone; coding is now confident and mature.

I’ll be talking more about these topics and the important role APIs play in an upcoming webinar I will be delivering with James Governor, co-founder of Redmonk. This is the analyst firm that truly is at the heart of the new developer movement. I hope you can join us Thursday, April 19 at 9am Pacific. This one is going to be good.

QCon London 2012 Is The Place To Be This Week

I’m off to London for QCon 2012, the 6th International Software Development Conference. I am one of the track chairs for this meeting. I’ve just learned that the show is now sold out, but there is a wait list if you have not already registered. All indications are that this is going to be an outstanding conference, so if there is any way you can possibly attend, you should make the effort.

I’m hosting a track this Friday called Industrial-Strength Architecture for Integration and Web Computing. Here is how I described the track to potential speakers:

The enterprise is demanding more from the Web than ever before. No longer content with simple web application delivery, the new enterprise web has become an integration point between mobile devices, browsers, legacy systems, and third-party web apps. It is a difficult balancing act. The new enterprise web is highly scalable, but can also reconcile the different service level expectations across each participant. At its core, it enables agile product delivery while maintaining extreme reliability. In this track, we will study the architectural challenges faced by the enterprise that needs to harness the web as a rich delivery channel—and highlight the real world solutions that address these.  We will explore the intersection where trends such as virtualization, noSQL, JSON, OAuth, APIs and mobile apps meet. Join us to understand the fine tuning between milliseconds and dollars that can make the difference between wild success and disappointing mediocrity.

I’m fortunate to have a great roster of speakers, including Theo Schlossnagle from Omniti, Paul Fremantle from WSO2, John Davies from Incept5, and finally both Marcus Kern and David Dawson from Mobile Interactive Group.

I’m also going to chair a panel titled Integration At Scale: Lessons Learned From The New Enterprise Web. This one promises to be a very interesting discussion:

The mobile device revolution has upended our traditional view of the world wide web. The enterprise web is now about integration: connecting any device to to any data, reliably and under wildly fluctuating load. How has this affected web architecture, and what changes in the day-to-day operation of the web resource? Join us for this panel of senior enterprise architects, each of whom has met the challenge of the new enterprise web.

The panel line up consists of David Laing from CityIndex, Neels Burger from MoneySuperMarket.com, Neil Pellinacci form Tanzarine Technology, and Parand Tony Darugar from Xpenser. Each brings tremendous experience to the panel, and bringing them all together is going to make for a lively and informative debate. I’m looking forward to it.

Hope to see you in London.

Upcoming RSA Conference Talk: Hacking’s Gilded Age—How APIs Will Increase Risk and Chaos

I’m going to be speaking about API security at next week’s 2012 RSA conference. I gave this talk the provocative title Hacking’s Gilded Age—How APIs Will Increase Risk and Chaos. It’s scheduled for Friday, March 2, 2012 at 10:10am in room 302.

Here’s the long form of the abstract, which gives a little more detail of what I’m going to cover in the talk than the short abstract that’s online:

This session will explore why APIs (which are largely RESTful services) are fundamentally different than conventional web sites, despite the fact that they share common elements such as the HTTP protocol. Web sites abstract back end applications behind a veneer of HTML that should—if it well designed—constrain capability and thus limit an organization’s security exposure. APIs in contrast are a more explicit interface leading directly into applications. These often self-document their intent, and thus provide a hacker with important clues that may reveal potential attack vectors—from penetration to denial-of-service. Because of this, APIs require a much more sophisticated model for access control, confidentiality around parameters, integrity of transactions, attack detection, throttling, and auditing.

But aside from the technological differences, there are cultural differences in the web development community that considerably increase the risk profile of using APIs. Many API developers have a background in web site development, and fail to understand why APIs demand a more rigorous security model that the web sites they were trained on. In a misguided attempt to promote agility, convenience is often chosen over precaution and rigor. The astonishingly rapid rise of RESTful services over SOAP, OAuth over SAML, API keys over certificates, and SSL (or nothing) over WS-Security is a testament to fast and informal prevailing over complex and standardized.

Nevertheless, it is certainly possible to build secure APIs, and this session will demonstrate specifically how you can spearhead a secure and scalable API strategy. For every bad practice, we will offer an alternative pattern that is simple-but-secure. We will explicitly show how the API community is dangerously extending some web paradigms, such as avoiding general use of SSL or not protecting security tokens, into the API world where the cost of failure is far greater. And finally, we will prescribe a series of directives that will steer developers away from the risky behaviors that are the norm on the conventional web.

I hope you can attend. And if you do, please come up after the talk and say hello.

See you next week in San Francisco.

The Resilient Cloud for Defense: Maintaining Service in the Face of Developing Threats

Skill at computing comes naturally to those who are adept at abstraction. The best developers can instantly change focus—one moment they are orchestrating high level connections between abstract entities; the next they are sweating through the side effects of each individual line of code. Abstraction in computing not only provides necessary containment, but also offers clear boundaries. There is also something very liberating about that line you don’t need to cross. When I write Java code I’m happy to never think about byte code (unless something is going terribly wrong). And when I did board-level digital design, I could stop at the chip and not think much about individual gates or even transistors. It is undeniably important to understand the entire stack; but nothing would ever get done without sustained focus applied to a narrow segment.

Cloud is the latest in a long line of valuable abstractions that extend the computing stack. It pushes down complex details of systems and their management under a view that promotes self-service and elastic computing. In this way, cloud is as liberating for developers as objects were over assembler.

The physical location of resources is one of the first and most important casualties of such a model. Cloud means you should never have to worry about the day a power failure hits the data center. Of course the truth is that as you move down the stack from cloud to system through transistor to electron, physical location matters a lot. So any cloud is only as good as its ability to accommodate any failure of the real systems that underpin the resource abstraction.

Layer 7 has recently become involved in an interesting project that will showcase how cloud providers (public or private) can manage cloud workloads in the face of threats to their underlying infrastructure. The inspiration for this project is the following display from ESRI, one of the world’s leading GIS vendors:

ESRI developed this display to illustrate wireless outages as a storm rips through central Florida. But suppose now that instead of a wireless base station, each green diamond represents a data center that contributes its hardware resources to a cloud. As the storm moves through the state, it may affect power, communications, and even physical premises. Work loads in the cloud, which ultimately could map to hardware hosted inside at-risk sites, must be shifted transparently to locations that are at less of a risk of a catastrophic failure.

Today, few clouds offer the mass physical dispersion of compute hardware suggested by this display. Amazon Web Services, for instance, has the concept of an availability zone, which consists of several massive data centers interconnected within a region (such as US-East, which is in the Dulles area, or EU, which is hosted in Ireland). Their cloud is designed to leverage this regional redundancy to provide continuous service in the event of a site failure.

This big data center approach makes perfect sense for a service like Amazon. There will always be a place for the large data center that leverages commodity hardware deployed on a breathtaking scale. But there is an alternative that I think is set to become increasingly important. This is the cloud composed of many smaller compute facilities. We will increasingly see large clouds coalesce out of multiple small independent hardware sites—more SETI@home than supercomputer. This is where our initiative provides real value.

These highly mobile, micro-clouds make particular sense in the defense sector. Here, compute resources can be highly mobile, and face threats more diverse and much less predictable than hurricanes. This is an arena in which the physical shape of the cloud may be in continuous change.

This project is being done as a catalyst within the TM Forum, and we will show it at the TM Forum Management World 2012 show in Dublin this May. Catalysts are projects that showcase new technology for executives in the telecommunications and defense industries. This catalyst is sponsored by Telstra, and brings together a number of important contributors, including:

Keep an eye on my blog for more information. Hope to see you in Dublin.

Security in the Clouds: The IPT Swiss IT Challenge

Probably the best part of my job as CTO of Layer 7 Technologies is having the opportunity to spend time with our customers. They challenge my assumptions, push me for commitments, and take me to task for any issues; but they also flatter the whole Layer 7 team for the many things we do right as a company. And for every good idea I think I have, I probably get two or three great ones out of each and every meeting with the people who use SecureSpan to solve real problems on a daily basis.

All of that is good, but I’ve learned that if you add skiing into the mix, it becomes even better. Layer 7 is fortunate to have an excellent partnership with IPT, a very successful IT services company out of Zug, Switzerland. Each year they hold a customer meeting up in Gstaad, which I think surely gives them an unfair advantage over their competitors in countries less naturally blessed. I finally managed to draw the long straw in our company, was able to join my colleagues from IPT at their annual event earlier this January.

Growing up in Vancouver, with Whistler practically looming in my backyard, I learned to ski early and ski well. Or so I thought, until I had to try and keep up to a crew of Swiss who surely were born with skis on their feet. But being challenged is always good, and I can say the same for what I learned from my Swiss friends about technology and its impact on the local market.

The Swiss IT market is much more diverse than people from outside of it may think. Yes, there are the famous banks; but it is also an interesting microcosm of the greater European market—albeit run with a natural attention to detail and extraordinary efficiency. It’s the different local challenges which shape technology needs and lead to different emphasis.

SOA and Web services are very mature and indeed are pushed to their limits, but the API market is still in its very early stages. The informal, wild west character of RESTful services doesn’t seem to resonate in the corridors of power in Zurich. Cloud appears in patches, but it is hampered by very real privacy concerns, and this of course represents a great opportunity. Secure private clouds are made for this place.

I always find Switzerland very compelling and difficult to leave. Perhaps it’s the miniscule drop of Swiss ancestry I can claim. But more likely it’s just that I think that the Swiss have got this life thing all worked out.

Looking forward to going back.

The Future Is A Story About Mobile Computing

Earlier today CNET published an interview with Marc Andreessen, in which the Netscape founder and influential VC outlines his personal vision for where tech is heading in the near future. His new tagline, from a piece he wrote for the New York Times, is “software is eating the world”, a blunt reference to how software increasingly appears out of nowhere to utterly consume a traditional practice or business model—be this in commerce, the social realm, or just about everywhere.

Andreessen asserts that this affect will only accelerate in the future because of the explosion we are experiencing in mobile computing:

Most of the people in the world still don’t have a personal computer, whereas in three to five years, most people in the world will have a smartphone…. If you’ve got a smartphone, then I can build a business in any domain or category and serve you as a customer no matter where you are in the world in just gigantic numbers–in terms of billions of people.

This new scale of mobile is something we’re only beginning to see, but it is becoming clear that the change this brings about is going to be profound. Mobile computing is very interesting to Layer 7; watch our for some interesting new developments coming out of our labs early in the new year.

I discovered a similar indicator of mobile interest using Google’s Insights for search. Pete Soderling and Chris Comerford, from Stratus Security Technologies, gave an excellent talk back in 2010 at the RSA show about REST security. They illustrated how the zeitgeist around distributed computer communications was changing over time by comparing search volume for “SOAP Security” (blue line) and “REST Security” (red line):

Try this out for yourself here.

What struck me about this was not that REST came up so fast—you’d have to be living under a rock to have missed that one—but that the two approaches have been tracking roughly equivalent over the last year. This mirrors our own experience at Layer 7, where we support both SOAP and REST security equally. We see similar patterns of interest coming from our customers.

What is even more interesting is what happens when you add “Mobile Security” (yellow line) to the mix:

Try it here.

The future indeed, will be written from a hand held device.