John Moe has written up a taxonomy of various SOA styles including Guerrilla SOA. I think John’s is a useful taxonomy, I completely agree that Guerrilla SOA is preferable to Gorilla SOA. Following on from John’s essay, Dave Chappell argues on the SOA mailing list that much of the cost in an SOA project stems not from middleware, but from people. And that actually SOA without middleware leads to reinventing wheels which is then left behind by Guerrilla consultants.
I’ll take that as a nod in my direction since last week Dave and I participated on a panel at the SOA symposium in which similar language was used. Let’s start by breaking the argument down into its two constituent parts:
1. Cost of middleware versus cost of project
On the cost front, I can provide some anecdotal evidence based on recent experience. I was part of a team approached by a telecomms service provider. These folks are all about carrier grade service, and massive throughput – a challenging and frankly daunting area of computing.
Prior to our first project starting, that client had already undertaken some analysis of their future architecture (which needs scalability of 1 billion transactions per month) using a blue-chip consultancy. The conclusion from that consultancy was to deploy a bus to patch together the existing systems, and everything else would then come together.
The upfront cost of the middleware was around £10 million. Not big money in the grand scheme of things, but this £10 million didn’t provide a working solution, it was just the first step in the process that would some day, perhaps, deliver value back to the business, with little empirical data to back up that assertion.
Understandably, this pitch fell flat. £10 million spent and no change in production systems was simply unacceptable. So instead the chief techies in the organisation reached out to my crew.
My (small) team spent a couple of weeks working through some analysis of the problem, including some simple mathematical models of how the problem domain scales over time, and how the solution would have to compensate. We took the time to understand how to incrementally alter the enterprise architecture to release value early, and we proposed doing this using commodity HTTP servers at £0 cost for middleware. Importantly we backed up our architectural approach with numbers: we measured the throughput and latency characteristics of a representative spike (a piece of code used to answer a question) through our high level design, and showed that both HTTP and our chosen Web server were suitable for the volumes of traffic that the system would have to support.
Armed with that empirical data, we went ahead and built the first service in the ecosystem. It took us in total around four months with a modestly sized team (less than 10 folks, day-to-day), and as we delivered software we tested it heavily against both functional and performance requirements.
I’ll repeat that, because it’s important: we performance tested the solution every single day to ensure that we would always be able to meet the SLAs imposed on us by the business. We were able to do that because we were not tightly coupled to some overarching middleware, and as a consequence we delivered our first service quickly and had great confidence in its ability to handle large loads. With middleware in the mix, we wouldn’t have been so successful at rapidly validating our service’s performance. Our performance testing would have been hampered by intricate installations, licensing, ops and admin, difficulties in starting from a clean state, to name but a few issues.
Based on the success of the first service, we began work on the next project. Since we’d already proven the technical patterns in terms of scalability and reliability, the green light for the next service was immediate. For the next service, the problem domain was slightly more intricate, and the team slightly larger, and the software took a 5 months to go from nothing to production (that is: serving customers and earning money). Again we were able to continuously build and performance test the system, and show it running – weekly – to our stakeholders. Nothing was invisible because there was no bus which could hide problems.
When this service went into production, it immediately started to generate revenue. The combination of the two services we deployed incrementally took strain off other parts of the system, and allowed uptime to soar. The last I heard a few weeks back, the system as a whole was dealing with several hundred percent more transactions per second than before we started.
But what’s particularly interesting, coming back to the cost of people versus cost of middleware argument, is this: we spent nothing on middleware. Instead we spent around £1 million on people, which compares favourably to the £10 million up front gamble originally proposed. To be explicit:
Total cost of working software in production: £0 (middleware) + £1,000,000 (staff) = £1,000,000
Total cost of middleware approach: £10,000,000 (middleware) + £? (staff) = > £10,000,000
If Dave’s point is accurate, that people cost more than software, then the minimum cost for the middleware solution would be £20,000,001, or around 20x the cost of the Guerrilla approach. And that doesn’t even account for the revenue lost (or risk) with big-bang deployments as opposed to rapid release models. But I’m nice like that, so I’ll let it slide – 20x is already a substantial enough differential.
2. Frameworks versus reinvention
In terms of frameworks, well I’d say I’m a big fan. I like WCF and Jersey, I like MVC and Spring, I like Jetty and Tomcat, I like the .NET framework and the JVM. In fact every piece of software I have ever delivered into production has relied on frameworks for heavy lifting – we used Jetty and Tomcat/JBoss and a bunch of mature open source libraries (thanks Apache!) for the services I described above.
What’s different about the frameworks I favour, is that they don’t imply a large up-front commitment (or gamble as it should be called), but instead allow choices to be deferred until a more responsible moment. Using these frameworks also allows delivery of tested and, importantly, testable code (thanks to Michael Feathers for educating us all about this!). And this is important because code which isn’t tested is legacy, and legacy is risk.
The teams at the telco services company are still working in the same Guerrilla SOA way, underpinned with agile practices. And they are still delivering high-quality solutions into production, and generating revenue for their business. There’s no “magic” in the system – no proprietary middleware that only some arcane specialist can deal with. They just have code and commodity frameworks which allows them to keep on delivering value to their customers.
Guerrilla SOA doesn’t reinvent frameworks, it embraces them. But it only embraces those frameworks that accelerate delivery, and not those which require up-front gambles that are detached from business imperatives. The Guerrilla Consultant is all about commoditisation: using commodity/open frameworks and commodity skillsets (.NET, Java, Ruby versus specialists for products like Oracle Fusion), and all about deploying rapidly and repeatably onto commodity hardware.
It is anything but the trench warfare approach espoused by enterprise middleware.
