"I have a mind like a steel... uh... thingy." Patrick Logan's weblog.

Search This Blog

Loading...

Friday, October 05, 2007

Bungie Cuts the Cord, So to Speak

Wow. This is huge. This speaks volumes between the lines and in the lines themselves. Just as Halo 3's $300MM USD is ballyhooed all over the press.

Just when there's all this buzz about how even enterprise applications are should become more game-like, and just as Microsoft must be getting desperate to show they can innovate, Bungie obviously takes off in order to be more innovative with game development than they can be as part of Microsoft.

Todd Bishop's Q&A is great. Maybe he could interview U.S. presidential candidates?

Say it Once Again

Pete Lacey: What is SOA?. Nicely done.

The definition of SOA is still an argument after all these years. This is a darn good sign that we should not care to use the term at all.

Equivocate: To avoid making an explicit statement. See Synonyms at "lie".

Mark Baker wisely points out...

There are, of course, a very large number of automated solutions to a particular problem.

...if you don’t feel disdain towards a lot (97%?) of these solutions, then you simply don’t understand what it means to be a software architect.

There is too much equivocation in our field. It's hard enough building software when you've got good tools at hand.
e·quiv·o·cal (-kwv-kl)
adj.
  1. Open to two or more interpretations and often intended to mislead; ambiguous. See Synonyms at ambiguous.
  2. Of uncertain significance.
  3. Of a doubtful or uncertain nature.

Thursday, October 04, 2007

Oh Dear, Part VII

Arnon Rotem-Gal-Oz assumes the position...

One thing that is missing from "HTTP variety of REST" implementation is reliable messaging. Location transparency is harder to solve with HTTP etc...

The solution should match the problem, that's probably the primary reason why we need architects after all.

Please Don't Pick on the Donkey

More Steve...

REST is unproven. Sigh. I can’t decide if people say this because they’re just trying to stir up an argument, or they’re so heavily biased toward their non-REST approaches that they just can’t even consider that there might be viable alternatives, or they really have no clue about what REST is, how it works, and why it works, and they’re not interested in learning it, so they just react badly whenever they hear it, or all of the above. If you’re anti-REST or REST-ignorant, and you haven’t read RESTful Web Services, then don’t even talk to me about REST. The book is absolutely wonderful, and its explanations and answers are extremely clear. If you consider yourself informed and capable when it comes to distributed systems and integration, but you don’t know REST, then there’s simply no way you can read that book and not have it lead you to seriously question your core beliefs regarding how you think such systems should be built, unless you’re completely close-minded of course...

What do mono-language programmers have to do with ESBs? It’s all part of the same culture, the “one size fits all” approach, where you have answers looking for problems rather than the other way around, and where people intentionally wear blinders to less expensive, more productive, and far more flexible and agile approaches because “it’s just not the way we do things around here.”...

At the end of the day, if you want to ignore my advice on using REST and dynamic languages, that’s your own problem.

And where his previous post received a comment, apparently from a Neudesic employee (ever heard of Neudesic???)...
Sonic Software, BEA, IBM, IONA, TIBCO, webMethods, Cape Clear, Fiorano, Oracle, Software AG, Neudesic, And how many open source projects????

All deliver ESB’s. It seems highly unlikely that all of these organizations, with plenty of smart folks, could be incorrect. Moreover, Gartner, Forester, ZapThink, and Burton, all speak loudly about ESB’s being an enabling technology on the road to building workable SOA’s.

Oh, dear. Steve responds best...
Making a list of smart companies to prove a point, well, doesn’t actually prove anything. I bet there are some actual smart people out there who have locked themselves out of their car, for example, or deleted whole directories they really wanted to keep but never backed up, or even paid actual money for a Zune. What does that prove?...

Unlike most of the commenters on this posting, I’ve personally built at least one of everything I’m talking about, on the ESB side and on the REST side, so I’m extremely confident in my opinion. I’d therefore much rather get specifics from you.

The View From Here Is... Grisly?

Joe Wilcox on MSFT Vista, speaking of big software the world is leaving behind...

The results, while arguably anecdotal, are grisly...

"Everyone—every single person—that I put on Vista has switched back to XP," he said. "It's too complicated."

From an administrator's perspective, my VAR buddy likes some Vista deployment tools, but he viciously complained about poor driver support, networking changes and end user complaints about UAC (User Account Control) and Internet Explorer 7 security popups.

In this ringing Vista endorsement, one Microsoft Watch commenter claimed: "I'm an IT consultant and I'm proud to announce I've formatted 450 Windows Vista machines back to Windows XP to date. I have also prevented at least 1,000 Windows Vista sales."

...the relevance of Windows is in decline. Microsoft's desktop operating system is rapidly becoming a commodity.

LAMP

Her royal pingdom lists...

OS: Linux 7 - Windows 2
Web server: Apache 7 - IIS 2 - Lighttpd 2
Scripting: PHP 4 - Perl 4 - ASP.NET 2 - Python 1 - Java 1
Database: MySQL 7 - SQL Server 1 (possibly 2)
And you should not be investing in some reasonable approximation to LAMP, again, because...?

Protected Game Preserves

That's how Bob Warfield refers to how Adobe, Microsoft, and SAP are approaching Software as a Service (SaaS). There's something different about Adobe relative to the other two.

Microsoft and SAP are figuring out how to transition gigantic cash cows into a world that is rapidly leaving them behind. Not so much for Adobe.

Adobe bought BuzzWord. They now have an early beta of an interesting word processor. They also have a few more apparently kickass flash/flex developers and creative software designers.

As opposed to MSFT's and SAP's situations, the fact that BuzzWord doesn't compete with other current Adobe products is probably an advantage. BuzzWord as a product may or may not ever matter.

Adobe's strengths in the new world appears to be (1) graphics, especially as they become more web-friendly, e.g. Thermo is hot.

And (2) their own decent runtime from Macromedia, something relatively easy to build upon compared to java or dotnet, from a company with decent developer relationships.

I think considering the company as a whole, Adobe has some good stuff to take into the new world. MSFT and SAP have bigger transitions to make, product-wise and company culture-wise. Not that I would bet much against them, because they are f'ing big and know how to sell software to vice presidents.

Properly Striking a Balance Between Shared Agreement and Decentralized Execution

Stu Charlton of BEA says stuff on the ESB brouhaha, but then he says some really crucial stuff we all need to consider...

I like ESBs if they're used properly -- to me, a good ESB is actually just a scripting language with supporting infrastructure. AquaLogic Service Bus, to me, is a Pipeline language, an XQuery language, and the supporting management & interoperability infrastructure, for example. But an ESB is not mandatory, and sometimes can slow you down if you're not looking to make legacy systems interoperate.
Wow. Equating Aqualogic with a scripting language. That's bold.
I agree with Steve Vinoski's The ESB Question. Don't use an ESB if it's going to slow you down. ESBs are a decent, productive tool for SOA (and even REST!) when applied properly, but so are Python or Ruby. ;-)
I want to like what Stu's saying, but his sprinkling of "properlies" just seems like equivocation.
BEA tries really hard to make Jython supported in WebLogic and AquaLogic, for example. The whole JMX object model is scriptable, and you can do some amazing things with it. And we have PHP running on WebLogic Server.
OK. I kicked the tires on Aqualogic over a year ago. I did not appreciate it any more than other ESBs, and found Jini/Javaspaces significantly more productive.

But I like the parts about Jython and PHP.

What gives? Perhaps two things:
  1. software has long term residual value but our investment decisions are always short term
  2. we intertwingle what changes from what doesn't change
We've fixed #2 with hardware platforms. SOA was supposed to fix it for software, but perhaps not (yet).
Yeah, across the industry we pretty much have #2 at the level of a high art.

As for SOA, well. It's well known...

SOA is the only thing Chuck Norris can't kill...

Its too bad you can't afford it.

Now we get to where I really like what Stu writes (and it has nothing to do with ESBs, unsurprisingly)...
I've seen many fast-moving IT departments, particularly in investment banking, but even some in telecom, continue to use the "build it to throw it away" mantra with reasonable success. This works when your organization is compartmentalized. But when information sharing is of primary importance, such as the intelligence or defense establishment, for example, we get to a case where these huge organizations need a different approach. Layers upon layers of bureaucracy make it hard to abandon any pet project.

This is partly why I think Enterprise Social Computing, the Web's architecture (or some successor of REST), etc. are very exciting; they seem much more likely to strike a balance between shared agreement and decentralized execution.

Every branch of software I know of must build an organization that is good at building software that is easy to throw away. If your organization can do this, it is at the master level and should be highly valued. Very few organizations can throw away much of anything in their data centers. This is *horrible*.

Stu nails that. But moreover he latches onto what should remain relatively constant in the data center: the information (web) architecture. That seems to be a good way, as he writes, "to strike a balance between shared agreement and decentralized execution". If you do that properly, you win.

That BEA Enterprise Social Computing thing looks interesting. It's encouraging to see BEA reaching out in that direction.

Making Great Decisions

From the Lean Development yahoo group...

Ford has spent the last thirty years moving all its factories out of the US, claiming they can't make money paying American wages. Toyota has spent the last thirty years building more than a dozen plants inside the US .

The last quarter's results: Toyota makes 4 billion in profits while Ford racked up 9 billion in losses. Ford folks are still scratching their heads

I viewed a Google Tech Talk recent on "Making Great Decisions". The presenters have a book by the same name. The talk and the book a very similar. The book has more content, of course, but the format is better as a book for me. It's the kind of book that I can pick up here and there and read a few of their stories. Nothing truly astounding has jumped out to grab me, which may be good: the stories are just common sense reminders for the most part, with a few fundamentals of analysis thrown in, e.g. considering your biased viewpoint when analyzing a trend.

By and large we tend to stop thinking even when we appear to be "doing".

Apollo

I've enjoyed reading Steve's posts and articles for a while. His latest is somewhat of a shockwave. An entertaining shockwave, the best kind...

The ESB becomes like one of those tools you see on late-night TV, where it’s a screwdriver and a hammer and a wrench and fishing reel and a paint brush, and plus you can flip it over and it can make you a grilled cheese sandwich. Of course, such tools always end up not doing any of those things particularly well.
But more than that he's former Apollo, which is way up on my list of lost treasures. Aegis / Domain/OS was a joy...
AEGIS was distinctive mainly for being designed for the networked computer, as distinct from its competitors, which were essentially standalone systems with added network features. The prime examples of this were the file system, which was fully integrated across machines, as opposed to Unix which even now draws a distinction between file systems on the host system and on others, and the user administration system, which was fundamentally network-based.

Wednesday, October 03, 2007

Yes, IM

From "discipline and punish" this...

Now every application isn't complete until it can send/receive IMs.
For whatever reason this came to mind the other day...
Send an instant comment to me,
Initial it with loving care
Don't surround
Yourself.

'Cause it's time, it's time in time with your time and its news is captured...
I'll have to go back and listen to the recording. I always thought it was "instant comment" but most lyric sites have "send an Instant Karma to me". Hmm.

OK. So in case anyone is interested, I did listen to the music this morning, and it does sound like he's saying "send an Instant Karma to me". Oh well. That's probably more Yes anyway.

Delay Tactics

See over on OreillyNet...

Well-intentioned people often add risk to their projects when they make hard decisions too early.

Carry On

The comments to Cedric Otaku's "verdict" on Erlang are a better read than the post itself. A smattering of choice words...

It is amusing to watch people attempt to tear apart and deconstruct Erlang, trying to refute its benefits, while Erlang coders continue on their merry way creating incredible software. Carry on, Java programmers!
and
What you're saying in effect is that despite the fact that the Erlang guys have already proven this stuff in practice time and again with actual, working, reliable, and long-running telecommunication systems (and systems in other fields as well), your gut feelings are a much better proof and indicator of what actually works in practice and what doesn't, so the reader should believe you, not them. Wow.
and
The real difference here is that it is much simpler (i.e. you don't even have to think about it) to run the supervisor process on an entirely separate node in your cluster. This is paramount for real fault tolerance in a running system, and you don't even have to think about it in erlang. I don't know how easy or hard this would be to accomplish in Java, but it is stupid simple in erlang.
and
In fact, the "post message to mailbox" operation has historically been the most tightly tuned hand-written algorithm in the entire erlang VM, for exactly that reason... but go ahead and assume it sucks. :)
and
Someone suggested Java can't compute 4 digit factorials. Use BigInteger - and it comes back in a snap for the factorial of 1000.
(You gotta love *that* one, don't you!) And...
Man, I'm sooo over language wars.
Finally from the post itself...
The only way a process can modify the state of or talk to another process is by sending a message to that process. Regardless of how lightweight the implementation of this message passing is, there has to be a lock on all these inboxes to guarantee that when dozens of processes send messages to your own process, these messages are delivered and treated in the order they are received from.
Erlang makes no such ordering guarantees. The messages from any process A to any process B will arrive in order, but independent of the interleaving of messages to B from processes C to Z or beyond.

And like Mark Baker has said about designing Restful HTTP systems: nobody said it would be *easy* just more simple and rational than other approaches. I don't know anyone who said Erlang made complex, distributed programs *easy*. But Erlang makes some aspects simple, gets you thinking in the right way, and has a body of knowledge and community easily available to help you build large systems.

Earlier in the year the team I am on took on building the kernel of a potentially large system using Jini/Javaspaces. That is the most "erlang-like" tool for building large, distributed systems in Java. (No, ESBs are not even in the running.)

The software was fine. The mechanisms worked. The biggest lack was the community. It would take a good deal of effort to build up our own knowledge base. There were bits and fragments and people like Dan Creswell we could call on to get advice here and there. But Dan moved on from J/J for the most part into another full-time gig. The rest of the community just wasn't there.

That community and knowledge base seems to be pretty much in place for Erlang development. That in itself is a huge advantage. Carry on.

Tuesday, October 02, 2007

Flex Builder Alpha for Linux

Flex Builder alpha for Linux. Great. Well, I use emacs, but still, great for most people.

Dang, I can hardly wait for AIR to beta, or even alpha, for Linux. Did I miss something yet???

By the end of the year, we can hope?

Sunday, September 30, 2007

Many-Node has many more implications than Many-Core

ManyCoreEra refers to a post on the Parrot VM and various concurrency mechanisms.

These shared-memory mechanism discussions continue to miss the point about the Many Core Era...

The many-core era will also be a many-node era. You will not have a C: drive except for those legacy systems running in their little jars of formaldehyde.

You will have a lot of computing power "out there" and several kinds of displays that are not directly attached to "your computer". You probably will not be able to locate an "application" as being installed on your C: drive and running on the CPU on the mother board that has a ribbon running out to the disk that has C: formatted on it.

Hardware will be too cheap to be organized this way. We need to begin reorganizing our software now or five years from now, we'll be really bad off, without any excuses.

If your current programming models distinguish between "these threads threads" and "those other processes over there" then it's almost certainly the wrong model for today, not to mention tomorrow.

Update:

The Java Server Side site has a lengthy discussion based on this lil'post of mine. A number of different views there.

More on the ESB

Cross-referencing fuzzy's cross reference to my cross reference -- we may create a vortex that implodes on itself. But anyway, in my URI post I said the ESB subject per se is a topic for another post, which turns out to be this one. Mike's hit my main impression with ESBs over the years. I wonder what Ross Mason or other ESB advocates have to say about my experience. First Mike's note on his recent exploration with Mule...

I have more learning on Mule to do. I was a little overwhelmed in working with it yesterday (lots of jar files, lots of XML config, examples that didn't help with what I wanted to do, docs that didn't answer my questions - typical newbie stuff). I did succeed in getting it configured to do what I wanted it to do after going down a number of rat holes & now have something to build on this week.
In my experience with various middleware tools (some of which predate the term "ESB" but all of which tend now to place themselves somewhere in the ESB territory) these turn out to be excercises in installation and configuiration by dialog box and/or by XML config file. I dislike both.

ESBs seem to me to be lumps of things useful for integration, but do not form any kind of coherent shape out of the individual lumps. If you need XML transformation, email, HTTP, file drop, etc. then why not just use the simplest dang library for the one or two of those needed for any given situation? If you need more than two of those in a single situation, then that's a symptom rather than a need.

Look at the list of "adapters" or whatever an ESB advertises. In each case, one can locate a fairly simple library, probably already on their machines, that implement that one feature well enough. ESB's say they can "wire" all that stuff together.

Such wiring usually appears to be more complicated than the original problem. They just have never appealed to me. But never say never, I guess.

I am from Missouri when it comes to ESBs. Show me. I'll give you the benefit of the doubt, if you can just show me, why it makes more sense to use such an all-in-one, configuration nightmare. :-/

I may be biased already, but I've not seen where these things pay off over a little code, some tests, and a couple simple libraries that do exactly what's needed. Assuming your experience differs from mine, please show me.

Update from comments: Yuen-Chi Lian's comment to this post responds to Dan Creswell's. First, Dan Creswell's... (Dan's connected to Jini/Javaspaces, in particular to the Blitz Javaspace implementation and some significant uses of J/J in production situations)

Of course the more point-to-point type integration solutions can also get out of hand but as you say it's simpler, more contained and easier to get to grips with.....
And now Yuen-Chi Lian's response to that... (he's connected to Mule, says google, so presumably has some good case studies in applying ESBs)
That's the point. And when it comes to a system with more and more enterprise applications connecting to it -- different vendors, different language, etc. You need a centralized mechanism, a universal connectivity, a message bus, an ESB. To keep messy things at a manageable level.

Also, programming in the large is simply a different (not better) development model to follow. But there are still fundamental concepts as its core which we have learned throughout the years in "traditional" development -- "high abstraction" and "loose-coupling".

I've got some experience with the Tibco RV bus, JMS, and Javaspaces. I understand how to use pub/sub, queues generally, and tuple spaces to reduce the NxM connectivity problem. I understand how to define "canonical messages" so that the messages on the bus are not just propagating the internal implementation details of the participants. And so this to me seems like appropriate "high abstraction" and "loose coupling".

I've never been a fan of the big tools sets that have grown up around tools like RV. All the point-and-click, configure the xml, "wire-up-the-bubbles" tools just don't do much for me. Writing a little bit of code to read/write messages on a bus seems just fine.

And so to me "message bus" and "enterprise service bus" seem to be two different animals. One is a simple animal (basic bus capabilities), the other a mangy mutt (ESB). The ESB is like a grab-bag of mechanisms that form no coherent whole. And they tend to have WS-Deathstar infused in their being, lacking simplicity and simply defined terms.

So give me a bus, give me a tuple space, give me simple mechanisms like that. But xml config'ing a zillion jar files to "mix-n-match" all the ESB thingies -- who really does that? Successfully? And what does the *architecture* of that look like? I remain unconvinced and nearly uninterested.

Today I am drawn to the simple web approach as opposed to the simple bus approach. The web, via atompub and the atom format, seems to incorporate enough "bus-like" behavior to meet many needs. Where it falls short then simple bus mechanisms can be employed as I'd turn to before. But I'd look to do that *without* hurting the web aspects. All that NxM connectivity stuff should have a web woven around the bits. They can all use the web as the simple, unifying architecture.

ESBs do not form an architecture in and of themselves. They are mechanisms that can provide some plumbing. I'm not sure at all that they add much to the simple plumbing mechanisms I've had success with already. I have trouble understanding how to approach them, and nothing I have seen to date has eased that for me.

So really good case studies would be appreciated. Give me your best shot, and I'll try to consider it.

Leaning

Fuzzy again...

The Poppendiecks are my favorite methodologists. I have yet to be disappointed with Lean thinking.
(Get their books if you have not yet. And read their other articles too.)

Mike has some good quotes and I'll pull some others out here. Another nice article from that pair. They provide a setting for having discussions with the rest of the business, less tied to the jargon and rigidity that has overtaken a true "agile" approach to software development. Here they are quoting Taiichi Ohno of Toyota...

"Years ago, I made them hang the standard work documents on the shop floor. After a year I said to a team leader, 'The color of the paper has changed, which means you have been doing it the same way, so you have been a salary thief for the last year.' I said 'What do you come to work to do each day? If you are observing every day you ought to be finding things you don't like, and rewriting the standard immediately. Even if the document hanging there is from last month, this is wrong.' At Toyota in the beginning we had the team leaders write down the dates on the standard work sheets when they hung them. This gave me a good reason to scold the team leaders, saying 'Have you been goofing off all month?'

"If it takes one or two months to create these documents, this is nonsense. You should not create these away from the job. See what is happening on the gemba and write it down."

Years ago I attended several weeks of CMMI training from a couple of really good instructors from SEI. They taught us essentially this. Start where you are, make small, incremental improvements.

I was the "agile" person there, and of course identified with this immediately. Most of the other people there were from "the CMMI team" whose job it was to "improve" everyone else. Unfortunately after years of discussion, they never really understood how to make improvements. To a large degree this was due to the fact that none of them ever developed much software, ever made many improvements, and were determined to force a made-up, "ideal" process on all the developers and project managers, who did nothing but resent it.

And so it goes. Now we have "agile" groups acting just as rigidly about their crown jewels.

Blog Archive

About Me

Portland, Oregon, United States
I'm usually writing from my favorite location on the planet, the pacific northwest of the u.s. I write for myself only and unless otherwise specified my posts here should not be taken as representing an official position of my employer. Contact me at my gee mail account, username patrickdlogan.