BASE Jumping in the Cloud: Rethinking Data Consistency. Home » Research » ZapFlash » BASE Jumping in the Cloud: Rethinking Data Consistency Your CIO is all fired up about moving your legacy inventory management app to the Cloud.
Lower capital costs! Dynamic provisioning! Outsourced infrastructure! So you get out your shoehorn, provision some storage and virtual machine instances, and forklift the whole mess into the stratosphere. Everything seems to work at first. You frantically dive into the log files and diagnostic reports to see what the problem is. You dig deeper, and you find the database is frequently in an inconsistent state. The Problem: Consistency in the Cloud The problem is that while it may appear that your database is running in a single storage partition, in reality the Cloud provider is provisioning multiple physical partitions as needed to provide elastic capacity. Failure is the Only Option. I ran a computer department for a small private school back in 1991.
I remember rolling out our first Macintosh computers, the ones with one megabyte of memory and no hard drive (the hard drives were too expensive for us). I managed to get them up and running with no disk in the floppy drive, so that students could load and save their work to their own floppy. This diskless approach was not particularly stable, however, and the computers would crash on a regular basis. As a result, my mantra was SAVE YOUR WORK! Expect your computer to crash, and plan accordingly! Schoolkids being schoolkids, however, they frequently ignored my admonition. How I Became a REST “Convert” Many of you know me as one half of the ZapThink team – an advisor, analyst, sometimes-trainer, and pundit that has been focused on XML, Web Services, SOA, and now Cloud Computing over the past decade or so.
Some you may also know that immediately prior to starting ZapThink I was one of the original members of the UDDI Advisory Group back in 2000 when I was with ChannelWave, and I also sat on a number of standards bodies including RosettaNet, ebXML, and CPExchange initiatives. Furthermore, as part of the ZapThink team, I tracked the various WS-* standards from their inception to their current “mature” standing. I’ve closely followed the ups and downs of the Web Service Interoperability (WS-I) organization and more than a few efforts to standardize such things as business process. Why do I mention all this? To let you know that I’m no slouch when it comes to understanding the full scope and depth of the Web Services family of standards. Web Services in Theory and in Practice. The Right End of REST. One of our Licensed ZapThink Architects, Michael Poulin, struggled with our recent ZapFlash, Where is the SOA in REST-Based SOA?
In a forum post, Poulin asked: If we have a UI that works with the middle- and back-end resources, do we care if … REST or Web Services are used behind the UI? If [the] UI all of a sudden becomes the orchestrator on its own (which contradicts the essence of Service with interfaces where one of [them is the] UI), how [may the] UI journey/workflow … be attributed to the communication channels – REST calls – running behind it? What constitute[s] “A REST application” … and how [does it differ] from non-REST application[s], especially from the architecture perspective? REST-Based SOA: an Iconoclastic Approach. At ZapThink we’re proud to be iconoclasts.
After all, building agile architectures requires critical appraisal—and frequent dismissal—of traditionally held beliefs. We know this role places us among the heretics who dare challenge established dogma. In fact, the whole notion of agility has long suffered this battle between iconoclasm and dogmatism. As we discuss in our Licensed ZapThink Architect course, the Agile Manifesto embodies an iconoclastic approach to software development dogma – and yet, so many people have become dogmatic about the Agile Manifesto itself, entirely missing its point! ZapThink once more jumped into this iconoclasm-masquerading-as-dogma fray with our recent ZapFlash, How I Became a REST “Convert.”
Get out the torches and pitchforks! To quote our beloved Agile Manifesto, we want to favor responding to change over following a plan—even if that plan is how SOA or even REST is “supposed to be done.”