I've gone over my love-hate relationship with Scala on these pages before but it's skewed toward love now that I've seen it in action for more than prototypes and poking around (it's used increasingly on the server-side with the products developed at my current client).
I want to be clear that I'll always have reservations about any language that tries to straddle the divide and be both object oriented and functional: it makes the language too big and too complex. Scala's approach toward operator overloading (really, just allowing operator characters such as + and / and == as valid method names) has me flashing back to the nightmare of C++ debugging while having so many ways to shortcut different expression idioms bothers me as well; it allows you to write Perl-like self obfuscating code. It's a positive trade-off for people with an aversion to typing but I'm sick: I enjoy writing and don't mind verbose expressions if they make things clearer, though I'm happy to be done with extraneous type declarations, parens and semi-colons.
The thing I'm digging with Scala is the relative simplicity in reasoning about concurrent operations and the power of being able to pass around little chunks of functionality. Now I know these aren't necessarily limited to functional languages: Ruby provides blocks/lambdas/closures and with Java 7's fork/join framework, the concurrency library of the JDK itself is helping to drain some of the unnecessary complexity out of concurrent programming with Java. But the elegant and immutable nature of functional programming brings out the beauty of software development like I haven't experienced in a while. And all this from just perusing the stuff.
I guess I'm lucky with my first taste of Scala in a real project. It seems most of it is written pretty well. That means not as a "better Java" ignoring the functional and Scala conventions and idioms. It also means not using all the language bells and whistles - it's damn complex enough on its own. You can write shitty code in any language and Scala will give you more than your share of rope in that regard - we haven't yet. Then again, I haven't taken my first crack at it yet here. :-)
Speaking of things functional, there's some good info in this InfoQ talk with Stuart Holloway on Clojure, a more purely functional Lisp-like language for the JVM (and the CLR). Makes me want to learn Clojure, but my brain's already full. Besides, I'm more English Lit than I am Comp Sci and I need to get back to my roots again (I haven't picked up a non-techie book in a few weeks and think I'm going through some sort of withdrawal). Then there are those two non-techie blogs I've been neglecting of late. Thank god for the rain today so I can catch up ...
Saturday, March 13, 2010
Saturday, February 20, 2010
Enterprise Architecture is not Platform Architecture
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 ...
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 ...
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.
Wednesday, January 27, 2010
Service Oriented Ambiguity Redux
I've been neglecting this blog in favor of my non-tech screeds for far too long now. When I have posted, I've done so only to point out some particularly interesting (to me) ideas and opinions from others. It's high time I put something out there that I'm particularly passionate about, so here goes ...
One of the things that has irked me over the past five or so years are the many myths and misconceptions around Service Oriented Architecture (SOA) (or, as Martin Fowler rightly labeled it, Service Oriented Ambiguity). I'm pretty much in agreement with Fowler (as I usually am) that SOA has long become a hopelessly sprintered term that means everything from "SOAP" to "Business/Technology Organizational Transformation" and should be abandoned to the dustbin of techno history (not necessarily the things people mean when they say "SOA" but simply "SOA" itself). Still, though the rampant hype has died down and replaced as the buzz word de jour by the equally ambiguous "Cloud Computing", SOA has stuck around. So I'd like to at least state what it means to me, strictly from an technology architecture perspective.
Generally, I tend to follow Tom Erl's literature when it comes to service orientation, particularly his principles and the manifesto he spearheaded. It quite literally means that your architecture is built and operates through the consumption and production of services. Yeah, yeah - services don't necessarily mean web services. Except that 99.9% of the time they do. They certainly don't mean just any web services: RPC-based SOAP "services" are too often simply procedure calls wrapped up in http and XML dressing. RESTful Services tend to be the most pure when they are really RESTful rather than just labeled that way (they all too often degenerate into "returning a bunch of shit wrapped in JSON/XML in response to a random http request"). Of course, the best RESTful services often follow a Resource Oriented Architecture (ROA), which is somewhat different. REST != SOA. REST is an architectural style, not an architecture. Read RESTful Web Services for more details on ROA. And check out the Web Oriented Architecture (Un)-Manifesto, which is not just about REST, but WOA is to my mind much more interesting than "SOA" ever was.
To get back to the point I'm trying to make, service oriented architecture means that the architecture of the system/platform/application itself is oriented around and talks services internally. It does not necessarily mean that the system/platform/application exposes services for use by external entities. You can have an architecture that exposes all kinds of wonderful web services for use by external clients and it might still be an ages-old monolith or a modern and perfectly reasonable component-based model. It's not necessarily service oriented. I'd call it service exposed. Likewise, you may expose no interfaces outside of the system itself, or you might publish an RPC API, but the internal architecture itself could still well be service oriented. The interfaces exposed to the client should be orthogonal to the architecture of the underlying system implementing them. Now, practically speaking, the two are likely to influence one another strongly, but the point is that they do not have to.
Software as a Service (SaaS) - and its offspring, Platform and Infrastructure as Services - also get intermixed into this equation. SaaS as a term predates SOA by many years but is more popular than ever now, while its much-hyped children, PaaS and IaaS, are even more the rage with Cloud Computing at the forefront. But each of these qualities of architecture have their own inherent characteristics, many not necessarily the most paramount or even applicable to service orientation (multi-tenancy, availability, scalability).
Too often I see all these architectural characteristics lumped together or used interchangeably and thought that at least for my own clarity, I'd get my 2 cents on the matter down "on record."
One of the things that has irked me over the past five or so years are the many myths and misconceptions around Service Oriented Architecture (SOA) (or, as Martin Fowler rightly labeled it, Service Oriented Ambiguity). I'm pretty much in agreement with Fowler (as I usually am) that SOA has long become a hopelessly sprintered term that means everything from "SOAP" to "Business/Technology Organizational Transformation" and should be abandoned to the dustbin of techno history (not necessarily the things people mean when they say "SOA" but simply "SOA" itself). Still, though the rampant hype has died down and replaced as the buzz word de jour by the equally ambiguous "Cloud Computing", SOA has stuck around. So I'd like to at least state what it means to me, strictly from an technology architecture perspective.
Generally, I tend to follow Tom Erl's literature when it comes to service orientation, particularly his principles and the manifesto he spearheaded. It quite literally means that your architecture is built and operates through the consumption and production of services. Yeah, yeah - services don't necessarily mean web services. Except that 99.9% of the time they do. They certainly don't mean just any web services: RPC-based SOAP "services" are too often simply procedure calls wrapped up in http and XML dressing. RESTful Services tend to be the most pure when they are really RESTful rather than just labeled that way (they all too often degenerate into "returning a bunch of shit wrapped in JSON/XML in response to a random http request"). Of course, the best RESTful services often follow a Resource Oriented Architecture (ROA), which is somewhat different. REST != SOA. REST is an architectural style, not an architecture. Read RESTful Web Services for more details on ROA. And check out the Web Oriented Architecture (Un)-Manifesto, which is not just about REST, but WOA is to my mind much more interesting than "SOA" ever was.
To get back to the point I'm trying to make, service oriented architecture means that the architecture of the system/platform/application itself is oriented around and talks services internally. It does not necessarily mean that the system/platform/application exposes services for use by external entities. You can have an architecture that exposes all kinds of wonderful web services for use by external clients and it might still be an ages-old monolith or a modern and perfectly reasonable component-based model. It's not necessarily service oriented. I'd call it service exposed. Likewise, you may expose no interfaces outside of the system itself, or you might publish an RPC API, but the internal architecture itself could still well be service oriented. The interfaces exposed to the client should be orthogonal to the architecture of the underlying system implementing them. Now, practically speaking, the two are likely to influence one another strongly, but the point is that they do not have to.
Software as a Service (SaaS) - and its offspring, Platform and Infrastructure as Services - also get intermixed into this equation. SaaS as a term predates SOA by many years but is more popular than ever now, while its much-hyped children, PaaS and IaaS, are even more the rage with Cloud Computing at the forefront. But each of these qualities of architecture have their own inherent characteristics, many not necessarily the most paramount or even applicable to service orientation (multi-tenancy, availability, scalability).
Too often I see all these architectural characteristics lumped together or used interchangeably and thought that at least for my own clarity, I'd get my 2 cents on the matter down "on record."
Tuesday, January 19, 2010
What I want to be when I grow up? Well ...
I've made a recent move from full-time information technology architect for an e-commerce solutions provider back to the role I played for the seven years prior to joining that company in 2007: technology consultant. Probably I'll be asked by clients to perform duties that on the surface seem pretty similar to those I was doing for my full-time employer; however, appearance can be deceiving. A lot of what you end up doing in a full-time gig, especially if you're in a senior role, only marginally relates to your "primary" responsibilities. These "secondary" duties often consume a large chunk of the day (project management, procurement of hardware, software, etc.). A consultant, on the other hand, is often hired to perform a very specific role for a very specific time period. Sometimes organizations bring on consultants for an unspecified period of time to essentially fill a full-time position, but I'll be specifically shying away from those engagements this go-round.
I'm not suggesting that one role is better than the other. Both clearly have their pros and cons. But I'm ready to focus more on the task(s) I feel I'm good at and that I like doing and consulting gives me what I feel is the best opportunity to do that. Or to go broke trying. :-) Of course, it'll also land me in places I'd rather not be (but I'll ensure that this only happens for short periods of time by keeping the contract lengths short). With consulting, I have to keep on my toes over a broad spectrum of technologies so that I can be 'the expert' on short notice. I like that. I also have to deal with the uncertainty of (un)employment from time to time and the possibility of significant travel, which I don't like so much. Still, on balance, the siren song of consulting finally won out, at least until I can find out what I really want to do when I grow up. :-)
If I have my druthers, I'll be focusing on large scale web capacity, scalability and concurrency challenges and resulting solutions for clients. That's where my passions are these days and will be how I orient my marketing message to potential clients. But whatever the gig, I'll do my best to make the most of each engagement, always on the look-out for that next special domain and/or organization that I might want to stick around with on a more permanent basis.
I'm not suggesting that one role is better than the other. Both clearly have their pros and cons. But I'm ready to focus more on the task(s) I feel I'm good at and that I like doing and consulting gives me what I feel is the best opportunity to do that. Or to go broke trying. :-) Of course, it'll also land me in places I'd rather not be (but I'll ensure that this only happens for short periods of time by keeping the contract lengths short). With consulting, I have to keep on my toes over a broad spectrum of technologies so that I can be 'the expert' on short notice. I like that. I also have to deal with the uncertainty of (un)employment from time to time and the possibility of significant travel, which I don't like so much. Still, on balance, the siren song of consulting finally won out, at least until I can find out what I really want to do when I grow up. :-)
If I have my druthers, I'll be focusing on large scale web capacity, scalability and concurrency challenges and resulting solutions for clients. That's where my passions are these days and will be how I orient my marketing message to potential clients. But whatever the gig, I'll do my best to make the most of each engagement, always on the look-out for that next special domain and/or organization that I might want to stick around with on a more permanent basis.
Tuesday, December 22, 2009
Blogs with your Eggnog
I just love reading Ted Dziuba's blog. The guy has a way with words and to top it off, a wonderfully cynical sense of humor. The latest post goes over his method for spotting engineering talent. Specifically, how he determines who is and isn't a valuable engineer (his formula is valuable = smart + productive + battle-tested). He gleans the most information by figuring out what pisses the candidate off. Particularly if it's some piece of a technology that they otherwise enjoy. Good stuff.
Another of my favorites from the blogosphere is Kitchen Soap, an operations focused missive which subscribes to the development/ops (Dev/Ops) philosophy (sadly, it's a philosophy that is a long ways from catching on in most corporate IT departments).
Nutrun (gotta love it for the name alone) is another I've been perusing of late, especially the post related to incremental deployment, since large scale deployment with lots of moving parts has been an increasing interest of mine.
I see Spring 3.0 went final. I still think Spring rocks, but there is increasing grumbling that the lightweight rebel who helped depose the bloated, self-satisfied Java EE king is itself getting a little bloated and self-satisfied (maybe there's some fear regarding SpringSource's new VMWare master and what it'll do to the technology). Meanwhile, Java EE 6 has come out after a good while in the gym looking much more fit and useable again. Perhaps ready for another run at the crown? Maybe. I wouldn't go quite so far myself just yet. Like I said, I still think Spring rocks.
Speaking of Spring, I can't wait for it to get here - already sick of snow not even two days into winter ...
Another of my favorites from the blogosphere is Kitchen Soap, an operations focused missive which subscribes to the development/ops (Dev/Ops) philosophy (sadly, it's a philosophy that is a long ways from catching on in most corporate IT departments).
Nutrun (gotta love it for the name alone) is another I've been perusing of late, especially the post related to incremental deployment, since large scale deployment with lots of moving parts has been an increasing interest of mine.
I see Spring 3.0 went final. I still think Spring rocks, but there is increasing grumbling that the lightweight rebel who helped depose the bloated, self-satisfied Java EE king is itself getting a little bloated and self-satisfied (maybe there's some fear regarding SpringSource's new VMWare master and what it'll do to the technology). Meanwhile, Java EE 6 has come out after a good while in the gym looking much more fit and useable again. Perhaps ready for another run at the crown? Maybe. I wouldn't go quite so far myself just yet. Like I said, I still think Spring rocks.
Speaking of Spring, I can't wait for it to get here - already sick of snow not even two days into winter ...
Subscribe to:
Posts (Atom)
Posts
