The whole NOSQL thing has been a hot topic over the past year or so in the tech blogosphere and I don't aim to add to the discussion (suffice to say that both relational and non-relational data stores have their place and it all depends on your requirements; this is not my area of religion). No, the reason I bring it up has more to do with the larger concerns behind the rising tide of NOSQL and other like uprisings against conventional enterprise architectural thinking.
It seems that folks are starting to understand that those things very important to enterprise applications are often different than those most critical to an internet-scale application (or other what some like to call "platform" applications). The people designing and developing these apps tend to come from the same community of technologists, with their own preconceptions of the architectural characteristics an application or system should have. Since enterprise applications came first, you get the things important to them applied to platform systems, even when it might be clear to a dispassionate observer that different concerns should be at play. So you get ACID or even 2PC transactions at every corner, relational databases, lots of small custom applications, failures treated as fatal. You might have some of those things in a platform architecture, but often they are not nearly as important as the twin towers of horizontal scalability and the expectation - and thus resilience in the face - of failure. The middleware vendors orient their best practices around enterprise applications, since that's their bread and butter from a financial perspective (but that just adds to the confusion).
It's good to see that these preconceptions are being pushed aside as platform applications are becoming more prevalent.
Enterprise architecture can learn from platform architecture too. I just hope folks don't go whole hog in the other direction ...
Saturday, February 20, 2010
Wednesday, February 10, 2010
things i'm paying attention to
Yeah, Yeah, I know: a list of things I'm "paying attention to" is just another way of saying that I have no ideas or opinions of my own at the moment. Sort of like the tour guide at the Duff Brewery when he says, "We've got a lot of exciting new ideas in the works." Homer presses him on it, "Like what?" The guy is dumbfounded by the probing question and stands mute while we see a single pipe in the background originating from one big vat of beer and then splitting off into three chutes labeled Duff Dry, Duff Dark and Duff Regular. Sort of like that.
Actually, I have a lot of opinions and even some hair brained ideas. Most of my technology-related opinions today are centered on the increasingly important constructs enabling software to run efficiently and correctly under truly (and highly) concurrent conditions. Lots of adjectives there. This is increasingly important for (at least) two reasons: 1.) More and more machines have more processors and more cores per processor and 2.) More organizations have the need for larger scale systems, generating more data, requiring significantly more parallel (read: concurrent) processing in order to match its scale. Often this is distributed concurrency (which has its own challenges) but within that larger framework exist increased needs for in-process concurrency. Ya can't really scale up and take advantage of additional processors on a box if the software itself was not designed to execute concurrently. That means doing it efficiently and correctly or suffering the consequences.
Java 5 provided a whole host of high-order concurrency capabilities to the JDK with java.util.concurrent and Java 7 is adding the fork/join construct (the master of java concurrency, Brian Goetz, explains the latter here). Still, even when we get to the point where Java 7 goes first GA and then mainstream (a few years off), all of this good stuff is still fundamentally built on the concept of synchronizers guarding shared, mutable data, and that's pretty darn low level for your average developer to be able to reason about consistently. One slip-up and you've got a ticking time bomb. A time-bomb that often doesn't go off until you're in production running on machines with more and faster processors with additional cores than ya had in development or QA.
Concurrency is something where Scala shines. I've written elsewhere on this blog about my love-hate relationship with Scala, but for highly concurrent capabilities running on a JVM, it's only love-love I have for this half-breed OO/functional concoction. After all, Scala is short for scalable. The reasons for this are two-fold: 1.) Scala's Erlang actor framework provides a high level mailbox messaging construct that is easy to reason about when it comes to formulating software that is correct in the face of concurrency and 2.) Scala's functional programming heritage means it's easier and more efficient to make your data immutable than it is with Java, and we all know immutable data is one of concurrency's best friends.
I said I was just going to list the things I'm paying attention to today, and so now I will:
Actually, I have a lot of opinions and even some hair brained ideas. Most of my technology-related opinions today are centered on the increasingly important constructs enabling software to run efficiently and correctly under truly (and highly) concurrent conditions. Lots of adjectives there. This is increasingly important for (at least) two reasons: 1.) More and more machines have more processors and more cores per processor and 2.) More organizations have the need for larger scale systems, generating more data, requiring significantly more parallel (read: concurrent) processing in order to match its scale. Often this is distributed concurrency (which has its own challenges) but within that larger framework exist increased needs for in-process concurrency. Ya can't really scale up and take advantage of additional processors on a box if the software itself was not designed to execute concurrently. That means doing it efficiently and correctly or suffering the consequences.
Java 5 provided a whole host of high-order concurrency capabilities to the JDK with java.util.concurrent and Java 7 is adding the fork/join construct (the master of java concurrency, Brian Goetz, explains the latter here). Still, even when we get to the point where Java 7 goes first GA and then mainstream (a few years off), all of this good stuff is still fundamentally built on the concept of synchronizers guarding shared, mutable data, and that's pretty darn low level for your average developer to be able to reason about consistently. One slip-up and you've got a ticking time bomb. A time-bomb that often doesn't go off until you're in production running on machines with more and faster processors with additional cores than ya had in development or QA.
Concurrency is something where Scala shines. I've written elsewhere on this blog about my love-hate relationship with Scala, but for highly concurrent capabilities running on a JVM, it's only love-love I have for this half-breed OO/functional concoction. After all, Scala is short for scalable. The reasons for this are two-fold: 1.) Scala's Erlang actor framework provides a high level mailbox messaging construct that is easy to reason about when it comes to formulating software that is correct in the face of concurrency and 2.) Scala's functional programming heritage means it's easier and more efficient to make your data immutable than it is with Java, and we all know immutable data is one of concurrency's best friends.
I said I was just going to list the things I'm paying attention to today, and so now I will:
- Elastic Search
- Scala 2.8
- Heroku
- Akka Project
- How to Measure Scale (an "oldie" but a goodie)
- Comparison of grid frameworks
- InfoQ Comparison of Spring MVC and JAX-RS
- InfoQ: Automating Operations with Spring Batch and Spring Integration
- InfoQ: The Future of Flash
- JClouds
- IBM's Java Concurrency Practice Series by Brian Goetz, et. al.
Wednesday, February 3, 2010
Agile by any other name might just be Salvageable
I agree totally with Brad Murphy's fear of the coronation of Agile as "mainstream" by industry analysts and CIO magazine. I've been working primarily as a consultant over the past decade or so and have been to a lot of organizations. Sadly, all too often, "Agile" is rolled out as though it were a software package (just like SOA and now Cloud Computing). They then declare themselves iterative and agile because they've instituted a couple of practices that are associated with "agile" (usually, things like continuous integration and refactoring and far less often things like test driven development and pair programming).
Sometimes an organization actually really does try and do emergent design and truly iterative development but again, far too often, where they've gone this extra mile, they've declared the results a failure and stepped back from the ledge. Of course, it fails usually because senior management does not also commit to these things and enforce their practices across all the stakeholders involved. It was always, "Well, QA will still test things at the end." Or, "we'll still run the project the way we have." Or, "We'll still do up-front requirements gathering." Or, "production operations folks will still only accept the complete and 'final' version of the software." And almost always, "We already have a deadline and the features committed for that date." This last is rarely flexible, even when in almost every case, things are delivered late and without all the features anyway. Still, can't let senior management in on the fact that they've got their heads firmly buried in the sand.
Not all organizations are like this of course. And not all parts of even large organizations have fallen in this regard. But a lot have. And claiming agile is now truly mainstream is simply validating an organization's false understanding of what agile principles truly are.
Perhaps, like SOA, we simply need now to find another name for Agile in order to save it from itself.
Sometimes an organization actually really does try and do emergent design and truly iterative development but again, far too often, where they've gone this extra mile, they've declared the results a failure and stepped back from the ledge. Of course, it fails usually because senior management does not also commit to these things and enforce their practices across all the stakeholders involved. It was always, "Well, QA will still test things at the end." Or, "we'll still run the project the way we have." Or, "We'll still do up-front requirements gathering." Or, "production operations folks will still only accept the complete and 'final' version of the software." And almost always, "We already have a deadline and the features committed for that date." This last is rarely flexible, even when in almost every case, things are delivered late and without all the features anyway. Still, can't let senior management in on the fact that they've got their heads firmly buried in the sand.
Not all organizations are like this of course. And not all parts of even large organizations have fallen in this regard. But a lot have. And claiming agile is now truly mainstream is simply validating an organization's false understanding of what agile principles truly are.
Perhaps, like SOA, we simply need now to find another name for Agile in order to save it from itself.
Subscribe to:
Posts (Atom)
Posts
