Antonio Rodriguez, founder of Tabblo and brother of the founder of Archivas (Andres Rodriguez), has a lengthy post worth reading on why AWS isn’t manna from heaven. He makes two key points:
- Given Amazon’s core business, it’s worth questioning the SLAs of AWS.
- The answer to the problem of entrepreneurs dealing with “muck” is open source and not managed services.
I completely agree with the first point and I’m sure Amazon has a reasonable SLA pitch or they wouldn’t be used by that many startups. Then again, the devil is in the details.
The second point I disagree with. It’s not that open-source doesn’t help with muck or that managed services do an amazing job. You just cannot compare the two–they are orthogonal.
If one of my companies needs some infrastructure functionality, say, a reliable message delivery service, it certainly won’t build one. It’ll go with an available provider. The choice between open-source or not will be made based on a number of factors, including the software delivery model, the target customers, potential M&A targets, etc. It is not obvious that open-source would be the only way to go.
Let’s say the company is thinking about going with Mule. Using Mule from a development standpoint is not a problem. Getting Mule to scale to huge message volumes and putting Mule in an appropriate high availability and disaster recovery (HA/DR) environment with all related bits and pieces of infrastructure may be a problem. There are issues of up-front cost, complexity and know-how. That’s where it may be worthwhile to consider a managed service that can help with bringing Mule up to this scale (high-end outsourcers will do this) or a managed service that does reliable messaging such as Amazon’s SQS. The ultimate choice would depend on many factors but whether the messaging service itself was open source or not would not be the biggest one by far.
Huge over-generalization alert. It is worth mentioning that open-source projects, as a pattern, tend to leave two types of functionality on the back burner–management and performance in large scale environments–because (a) management is uncool, (b) most designs initially don’t focus on very large scale environments and (c) it is hard to assemble the HW/SW necessary to run tests in these types of environments. That’s a problem but also an opportunity.
I see 2 additional problems with Amazon WS:
1) They have not (over the past few years) managed to keep their interfaces stable. Nobody wants to invest seriously in something that is going to change every few months
2) Their public WSDL has historically only really supported client auto-gen tools that are based on .net (because they apparently used .net to implement the providers). They have not paid attention to the discrepancies in SOAP definitions between Microsoft’s implementation and other companies’. For example, IBM’s RAD tool barfs on many of the Amazon WSDL interfaces because of their (Amazon’s) reliance on arrays of complex types. This reduces essentially to a disagreement on the specs.