On the heels of writing that last article, I found a copy of Amazon.com Mashups in the post.  The book was written by a friend of mine, Francis Shanahan, and the book also has a great chapter that covers the S3 service mentioned in my previous post.  From defining objects and buckets to building out working prototypes that interact with the S3 service, this chapter helps you get up and running with S3 in an hour, well worth the price of the book for that chapter alone (<$20 on Amazon).

Beyond S3, the book provides a good introduction to the concept of mashups, as well as hands on introductions to mashing up services from Yahoo, Microsoft, YouTube, and others. It also showcases some of Francis' mashup creations, which are cool in their own right (i.e. Zollage, Zuggest, RoboCast, etc.). 

I'd recommend checking out the book and his mashups.

The book can be found here:

http://www.amazon.com/Amazon-com-Mashups-Francis-Shanahan/dp/0470097779/sr=8-1/qid=1167221205/ref=pd_bbs_sr_1/104-4399996-7228729?ie=UTF8&s=books

His site (and related mashups) here:

http://www.francisshanahan.com

I've been on the web services bandwagon, since... well, I think before there was officially a bandwagon, actually.  When I was VP of development at Gazelle Systems, we had the challenge of providing our software (POS integrated CRM for hospitality, which included loyalty, couponing, gift cards, etc.) such that it readily integrated with point of sale systems. For those unfamiliar, the POS market is fairly diverse as the solutions (at that time) ran on a multitude of platforms (windows, unix, qnix, dos, proprietary) and also in a number of location configurations (1 self-contained terminal, multiple terminals on a store specific lan, multiple stores on a wan, and remotely hosted POS by an Application Service Provider). We needed a location agnostic, platform agnostic approach to integration. Around this time, I'd heard about Don Box and SOAP, and we built out our own SOAP server and built out our loyalty and other functions as services, and defining XML (pre-XSD XSD) that would represent our messages for loyalty et al.

At that time, I saw that services represented a bright future for the development of software, but I also saw them as the end of an era. Specifically, for the 'little guy'. In the early days of development on the Windows platform, particularly for the VB community, there was a great ecosystem of third party control vendors that offered up .VBXs and eventually .OCXs to incorporate canned functionality inside of your Visual Basic and Visual Studio applications.  The beauty of it was that anyone could do this, the fabled 'two guys in a garage' could put together some innovative controls and offer them up.  For me, this was immortalized in folks like the company Mabry.  They were always advertising in Visual Basic programmers journal, putting out things like an SMTP control, and I can't imagine they were a large operation.  For those unfamiliar, scan the newsgroups archives and you'll find multiple references.

In a web services world, however, it rapidly becomes more difficult for Mabry and the category now known as the Micro-ISV. Why? Infrastructure.  In the days of .VBXs and .OCXs, you were shipping compiled code that typically ran on the desktop. Moving into the services space is a much different animal -  you need servers, bandwidth, memory, disaster recovery scenarios, multi-tenant geo-clustered databases, storage, real-time/near-time support in a global setting, and enforceable service level agreements.  The upfront investment in infrastructure is a major barrier to entry, and really limits innovation in the ability for Micro-ISVs to deliver services.

This is starting to change, with vendors such as Amazon offering what are being called utility services. Utility here having a similiar meaning to the water/power/natural gas utilities you have for your home.  Like your home utilities, utility services provide a pay-for-what-you-use model, providing the ability to scale. Like with standard utilities, these services require a metering infrastructure - with that meter being found in the cloud vs. the side of your home.

Amazon offers something in this space focused on storage, a service called S3. Effectively, if you need storage, they can provide it to you on a metered basis for a very reasonable cost. If you wanted to build your own Flickr, YouTube/SoapBox, or any other service that requires storage, you can do it and do it in a fashion that will scale with your business. It's services like these that lower the barriers to entry to the Micro-ISV, allowing them to innovate without the upfront costs.  These sorts of services free up the ability to innovate in a services world, and the 'two guys in the garage' are back in business.

With utility services coming onto the scene and standards for both identity federation and secure web services established, I'm hopeful and eager to see the next generation of Mabry's innovate around the platform.

Mercuri's "Services SLA Paradox"

Paid services haven't taken off because there aren't SLAs from Service Providers.
There aren't SLAs from Service Providers because people aren't paying for services.

-----------------------

When someone gives you something for free, they have no obligation to you and you have no recourse if something goes wrong. When I was a student, if I was moving to a new apartment, my friends would would help me pack up my old place, load the truck, and unload it at my new apartment.  Sometimes people would show up late, sometimes things would get broken, but hey, they were doing me a favor, so I had no room to complain.

When I move now, I hire a moving company. Why? Because my time is more valuable to me than it was 15 years ago, and I also have much more expensive stuff.  If I was scheduled to move out of a house on the 31st, and the mover's truck broke down, I'd want to make sure the company could swap in another truck from their lot. If my $4,000 television is dropped, I want someone who's insured and who's going to make it right.

Today, we have a number of people giving away services - Google, Yahoo, Flickr, Amazon, StrikeIron, etc.  While there are exceptions like Amazon and StrikeIron that are doing some good work in the utility services space, where they're doing metered usage, I've had a hard time finding SLAs anywhere else. People are doing interesting mash-ups with 'free stuff', but is anyone willing to put free stuff in their application for any key piece of functionality? If you do, and you don't have SLAs, you're a gambler, and for your sake, I hope you're very lucky.

At the Web Builder 2.0 conference held earlier in the month, Day 1's keynote had a speaker who talked about Ajax and mashups, using his company's product as an example.  At the end of the presentation, he opened up the floor for Q&A, at which point I asked him two questions - "what about SLAs" and "what about federated identity".  The answers? 

SLAs: These services are free, so there are no SLAs.

Identity: These services (Yahoo) are free, so that's not an issue.

I find it amazing that people don't pro-actively address the SLA and Identity issues, and I find it borderline irresponsible that 'experts' ignore or wave off these questions when raised. The need for SLAs should not be such a surprise, people who've spent time looking at the space at this have written about it, myself having done so back in 2001  ("14 Best Practices for Selecting a Web Service Provider", 2001, .NET Magazine, Fawcette) Yes, it's cool to include maps, search, and images in my application but if the service code go down - or disappear entirely - at any time, for many scenarios they're a non-option.

If you want to use services for anything real - and by real I mean something you'd use in a key area of an Enterprise or Commercial Software/WebSite - you need to have a Service Level Agreement. Using a service effectively moves a third party from being a vendor to being a business partner. The service provider controls the hardware, the bandwidth, the support, etc. but the service interactions are exposed through your application, with your brand, and your reputation attached to it.

With today's lack of SLAs, if the service goes down for an hour on Thursday, it goes down for an hour on Thursday. Moreover, there's no guarantee that the service is going to be around for a week, a month, a year, etc.  Google just announced (http://news.com.com/2061-10812_3-6145053.html) that they're no longer taking on new customers for the SOAP API they'd been offering. They're moving new customers to an AJAX API. If you were evaluating this and building this functionality into a spec for a smart client application you were developing, and now it's gone, sorry charlie. What were you expecting? You're not paying for it, so you can't complain. Without an SLA, no promises are ever made  made by the provider, so there are no promises to break.

My argument is that SLAs are late to the game, because people aren't paying for services and people aren't paying for services because there are no SLA's. Something I've shamelessly named 'Mercuri's Services SLA Paradox'.  There are some positive movements in the right direction - Amazon and StrikeIron come to mind - but they are definately the exception and not the rule.

If you're like me, you'd like to be able to leverage and mashup services that you can depend on. If we collectively don't stand up and insist on these, we're stifling innovation. I challenge you to ask the providers - at conferences, in forums, online and in person - "What is your SLA for your services and what will it take/cost for you to offer me this service in a dependable fashion?"

Way back in May, I wrote a post on context and search (http://www.marcmercuri.com/PermaLink,guid,9d050e2c-e3dc-4b16-953a-4ea7c2d48702.aspx).  The post was prompted by something that was going on in the national media. Essentially, the US President's Press Secretary, Tony Snow, had come out and said that certain newspapers were being less than factual or selective in statistics they were reporting. In that post, I made a statement and a 'wouldn't it be cool' ask.

The statement was - set aside the politics for the context of discussion. The issue raised by Mr. Snow's statements questioned the level of trust associated with a particular periodical. Some people trust the Washington Post more than the New York times, that sort of thing.  The 'wouldn't it be cool' ask was about custom search.  Whether I'm searching on anything from presidential politics to the hottest new gadgets or the latest antics of Paris Hilton, I should be able to do that with a sense of context and trust.

At Microsoft, I attended a 'Search Mashup Day'. People across the company can get together, learn about search, throw out ideas, and for some of us, build out some mashups.  My 'wouldn't it be cool' ask was the intended basis of my work at Search Mashup day. Unfortunately, the search guys made it too damn easy, so I finished up pretty quickly (a good problem!)

The Live Search guys implemented this via something they call a search macro. You can create one in less than 10 minutes.

Step 1. go to http://search.live.com/macros

Step 2. Select Basic and click the Next Button

Step 3. Enter in the news / gossip sites you want to include in your custom search engine.

          Here's a sample list of some of the more popular news and gossip sites (remember, only copy in the web addresses from the first column):