Scott Morrison

Scott Morrison

Scott Morrison is the Chief Technology Officer at Layer 7 Technologies, providing the visionary innovation and technical direction for the company. He has extensive technical and scientific experience in a number of industries and universities, including senior architect positions at IBM. He is one of the four co-editors for the WS-I Basic Security Profile. Scott is a much sought-after author and speaker. He has published over 50 book chapters, magazine articles, and papers in medical, physics and engineering journals.

April 20th, 2012

The Well-Designed API

Written by
 

Layer 7 API Portal AnalyticsWe have worked with a lot of APIs here at Layer 7. And over time we’ve seen it all, ranging from the good to the bad. We’ve even seen 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 APIs, as they will probably be around for a long time. 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 – 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 TechTalk How to Design A Good API & 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 your language of choice, 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.

April 16th, 2012

Webinar Reminder: Developers, Developers, Developers

Layer 7 RedMonk Developers WebinarIt’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.

Click here to register for the webinar: Developers, Deveopers, Developers - Why API Management Should be Important to You featuring RedMonk

March 8th, 2012

QCon London 2012 is the Place to be this Week

QCon LogoI’m off to London for QCon 2012, the Sixth International Software Development Conference (March 7-9). 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 waiting list if you haven’t already registered. All indications are that this is going to be an outstanding conference, so if there is any way you can attend, you should make the effort.

I’m hosting a track this Friday, called Industrial-Strength Architecture for Integration & Web Computing. Here’s 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 challenges. 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!

February 23rd, 2012

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

RSA Conference 2012I’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 & 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 does:

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 is well-designed — constrain capability and thus limit an organization’s security exposure. APIs, in contrast, represent 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 backgrounds in Web site development and fail to understand why APIs demand a more rigorous security model than 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!

February 16th, 2012

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

TM Forum Management WorldSkill 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, it 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. Suppose 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. Workloads in the Cloud, which ultimately could map to hardware hosted inside at-risk sites, must be shifted transparently to locations that are at less risk of 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). Amazon’s Cloud is designed to leverage this regional redundancy in order 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 it brings together a number of important contributors, including:

Watch this space for more information. Hope to see you in Dublin!