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.