Development and General

When SOAP has failed.

Don MacVittie — Thu, 17 Jul 2008 19:27:22 GMT

Interesting read over at The Register that posits the question "will Flex SOAP 1.1 work with .NET betas?"

The steps he went through and how he got things going was mildly interesting, more interesting to me was that he even had to ask.

I cannot say how happy I am that the answer was a resounding "Yes, they work together", because if we ever see a "no, these two mainstream Web Services products don't inter-operate" (ignoring those first few painful versions of yesteryear when people were figuring it out), then SOAP has well and truly failed.

The entire purpose of SOAP is interoperability, we shouldn't need to ask these questions. Indeed, they shouldn't even occur to us and the environment should be such that if we try and they don't work together, we assume that we did something wrong.

But some vendor will do it, guaranteed. Trying to get you to use their tools only, they'll fail to support the standard correctly. When that happens, we, as an industry, need to slap them.

Until then, we get to continue to flourish in Nirvana.

Don.

/reading: Programming Ruby - free electronic version.

Share this post :

Cash for Open Source? HuH?

Don MacVittie — Mon, 14 Jul 2008 22:15:43 GMT

There's a blog post - ironically touting a title with "economies" in it - over on C-NET.com talking about the need to get more enterprises to contribute cash and updates to Open Source Projects.

So the Freeks (Free Freaks who expect everyone else's work to be free but still want to be paid for their work) are now not-so-free? You can't have it both ways. Either capitalism in all of its glory reigns, or socialism in all of its glory reigns. But you can't destroy the free market and replace it with a mandatory payment scheme. Well you can try, if you're really interested in seeing your experiment dwindle on the vine. Just ask any of the (former) economists for the (former) Soviet Union.

Look, I use Open Source, I've contributed back to Open Source, but the point of OSS was to make software free. You did that. You start to sound like a drug dealer when you call for something in return for free software.

After all, the first hit is always free, right?

Don.

/Reading: This was a bonus post, see my last post from this morning if you actually follow my reading habits.

Share this post :

Storage - Where do we go from here?

Don MacVittie — Mon, 14 Jul 2008 17:10:57 GMT

There's a lot out there right now that is up in the air... The future direction of social networking, mobile vs laptops, security, when next I'll shave my head, and the topic of today's post, what to do about data storage.

There's a post over on DrunkenData.com that talks about preliminary results from a bit of UC/NetApp research that decided... SURPRISE! That 90% of your data is just sitting there taking up space.

The first thing that struck me about this claim was "Structured or Unstructured?" but I quickly remembered that it's NAS, so unstructured.

Not that this is really news to most people in the storage world, but the next question must be "what to do about that"? It's information we've had for a while, and things like ILM did nothing to help us capitalize on it, just as many of us predicted and analysts denied.

The post suggests going to tape and optical jukeboxes for those infrequently accessed files, and now that all OS's actually honor access times, that's possible in a NAS world (it wasn't, more recently than you think), and there are plenty of products like Acopia that can direct data based on access date/time. Another thing that gave me a chuckle was the tape world. Tape is good for long-term, off-site, archival storage. Its other uses have dwindled as the cost of disk has dwindled. But the article calls tape arrays "greener technology". Funny, it used to be sold as "cheaper". one can't help but wonder what it will be sold as after this post.

Another solution that doesn't require 15 year wait times for tape to seek to your users' files when they need access to them is disk arrays that spin down when not in use. Simple and to the point, EMC and NexSan make them, I'm certain others do too, but it's been a while since I was living/breathing in this space. The theory is simple, if this is tier two (or three) of your data architecture, and drawer #7 hasn't been accessed in X number of minutes, spin it down and leave it that way until someone does access a file stored there. That's green, it saves you green, and you don't have tape seek times to contend with (and in a jukebox, just tape or disk selection time could constitute the need for a coffee break).

Combine that with an intelligent tool for figuring out what goes on this system and what goes on your big, beefy, NetApp box, and you're in data nirvana, right? Well, at least your costs are down, your access times aren't up, and you are on the road to a greener Mother Earth. And tape can still be your archive format of choice.

I'm not as close as one might expect with the Acopia team (I know, I'm working on it), in fact, I know more about the competing technology one of our competitors sucked up, but migration based on access times is pretty simplistic as NAS Virtualization goes, so I'm going to stick my neck out with some amount of bravado and suggest we can do it.

So the architecture then would be simple. in front an Acopia box, behind it your spin-down disks on the right, and your NetApp Filers with hyper-active data on the left. As the data ages, it moves to the right (any presumed allegory to humanity is in the author's imagination, I assure you), the trays on the right are arranged such that all older data is in one tray, working backward to the newest stuff. So you'll have a couple of trays that never spin down, a bunch that are nearly always spun down, and your NetApp cranking out file after file. All coordinated by your NAS Virtualization engine, of course.

The only thing left in the seven-headed hydra that is data storage is SAN, and since the only company that truly managed the SAN/NAS leap is dead and gone, their technology and patents disappearing into the bowels of EMC, I guess you'll have to wait for the next revolution to work SAN into your NAS architecture.

Think about it, once set up you would have to do nothing and your electricity costs would go down. Monthly savings until such time as technology eliminates this architecture as an option versus the one-time expense of setting it up. Appealing.

Don.

/Reading: Smotherhood. These days I read while waiting for paint to dry on miniatures, and Lori left it lying around. Good book.

Share this post :

Making Use of kSOAP2 at Dr. Dobbs

Don MacVittie — Tue, 24 Jun 2008 21:03:36 GMT

Hey all, shameless bit of self-aggrandizement here...

I can't find the shameless self-aggrandizement tag in our tags list though, so I'll mark it as development. ;-)

Dr. Dobbs Journal has run my article on programming in kSOAP2. This article has more info and compliments the Tech Tip here on DevCentral entitled The Minimum Steps to use KSOAP. If you're a mobile device developer, these two articles will help you get a jump start on using kSOAP to SOAP-enable your applications.

Yeah, I'm a little bit pumped. Even when I worked for CMP - the company that owns Dr. Dobbs - I couldn't get first publication there, though they did re-print a couple of my Network Computing articles. So this is a first for me, in a publication I 'grew up' with.

The progenitor of both of these articles was the Blackberry iControl Application lab that lets you monitor your BIG-IP from just about anywhere. Check it out if you haven't yet.

Don.

Good Stuff and Vacations.

Don MacVittie — Tue, 10 Jun 2008 00:19:03 GMT

Well, it's been an exciting week all around!

Amazon had their little stumble, and that got the conjecture/rumor mills running, Apple is talking about all sorts of new stuff, and the much bally-hooed 4th edition of Dungeons and Dragons was released (with a tribute to Gary, good call guys).

I read the news on Amazon and Apple, talked to some of my contacts to find out more inside information just because happenings in high-tech interest me, and stood in line at the FLGS at midnight with a guy lovingly called The Ninja to get our copies (and Lori's) of D&D 4E.

And personally, I got an article placed in a publication that I've thought I'd like to get something placed with for a while, on a topic that I'm passionate about, good stuff. Top all that off with the fact that I'm headed out on vacation as soon as I post this, and that's a pretty good week.

While I'm out, you'll need some reading - you do all come here just to read what I write, correct? So I thought I'd leave you some pointers to some of the other great stuff on DevCentral. Our team rocks, so finding great stuff isn't nearly as difficult as keeping it down to blog-post length!

There's another hit for the DC Post of the Week - If you haven't been following Deb and Colin on these, you should. They take a good thread from the forums and expound upon all of the possible solutions.

Colin has a great article on forcing download (as opposed to display) of certain file types: Content-Disposition. If I recall correctly, this article was spawned by last week's Post of the Week.

Lori brings your attention to a problem with some routers supposedly caused by Windows XP SP3 in her blog.

While we're speaking of Lori, I've probably mentioned this one before, but her Unifying Rest Access article is great if you're a BIG-IP user with a REST architecture.

And finally, Joe's bit on Self IPs gives you all you need to know about the Self IP interfaces for iControl. A good reference to have if you need to twiddle with self-IPs from code.

Me? I'll be at home catching up on all sorts of stuff I should have done months ago, then Lori and I are going to head out to Vegas for a couple of days to meet with some other geeks (we're bringing 4th Ed D&D books and our C&C books, so that kind of geeks).

Until then, enjoy the above reading, it's good stuff.

Don.

/reading: Keeper of Dreams, Orson Scott Card.

Over-Engineered vs. Good Enough.

Don MacVittie — Tue, 13 May 2008 17:32:38 GMT

The Boss and I were discussing the quality vs. timeliness debate yesterday, and then last night I was drinking a bottle of New Glarus (Cherry - the only brewed alcohol I consume, but that doesn't matter) - my first consumption of alcohol in 15 months - and looking at a model I was painting (An M4 GMC with mortar, but that doesn't matter either). The vehicle was nowhere near finished, but I was holding it and going "that looks good enough! I should be done!" The New Glarus was clouding my vision, allowing me to ignore the glaring unfinished and sub-par bits.

In case you're wondering, the M4 is not mine any more than the Belgian Red logo, it's a finished one from Military Modeling.

Sadly, it doesn't take New Glarus to get in this position. Most organizations are there every once in a while, ignoring glaring faults with their process or product (in the case of IT, 'product' is the service you provide the rest of the organization) because they've adapted one-or-the-other mentality.

The never-ending debate that in most organizations runs in circles goes like this - "we need to stop analysis paralysis" versus "we need to improve quality".

Want the truth? There is no panacea.

So if you're standing on one side of the fence prepared to defend it, you're on the wrong side.

But that's okay, because experience says you'll hop over that fence several times during the course of your career.

There is a place in the world for both, but very few projects warrant all of one or the other. I want my car over-engineered, thank you. I want mission-critical applications - in this case mission critical is "the company cannot run without them" to be over-engineered also. That app the sales managers use to calculate their bonuses? Not so much. For most organizations you want your public face to be over-engineered also. If your website is down, it is the 20th century equivalent of having no sales people on the floor to help prospective customers. But if you over-engineer every system in your data center, either you have a big staff or you're not getting anything done. That's just simple fact. Look around your data center, and take a second to marvel at how many applications actually run there every day. It's astounding.

Over-engineered implies too much time is spent on it - not possible on some systems like the US 911 emergency system. Good Enough implies that it was rushed out the door just complete (and stable) enough to be acceptable - and some companies have built multi-billion dollar empires on this very concept. For most of us, and for most of our applications, reality is somewhere in between. Something is indeed better than nothing - unless that something causes anger and disillusionment, or keeps something productive from being done - "because we have a solution we should work within".

So what are you to do? Make certain you're investing time and effort on the systems that truly are required should the worst occur because those are the critical systems. Remove politics from your analysis, and think about it in terms of "what would we need to function should things go horribly wrong?" the answer is a tiny subset of the systems you manage every day. Get those to be supported by products like ours (LTM for server-sized emergencies, GTM for data-center sized emergencies, etc), give them more slices of your timeshared pie, and only after you're comfortable that these apps are darn-near over-engineered do you worry about apps like the Janitors' cleaning scheduler. You're already doing this, but politics does tend to cloud the discussion, and what's important is not always obvious (I worked at a good sized enterprise once where the apps were well taken care of, but the databases... well, it was ugly because they weren't considered in light of the apps that required them until the incident) .

Focus on the important, remember that just because a particular business manager screams a lot doesn't make his app more important, it does say something about him/her though.

At least one of you is already thinking "not possible here..." I disagree. When you start talking about "protecting the business", people listen. They have to, you're talking about what's important to them too. And when you start talking about modifying processes (in general, not just DR processes) to better suit the needs of the business, people listen to that too. Because I've never been at the place where IT was perceived in a positive light, so any attempt at improvement will be well received.

There you have it, my advice of the week - (1) Don't drink New Glarus while modeling unless the model isn't important to you... It will be "Good Enough". (2) Over-engineer what's important, and make certain you've got a handle on what isn't.

Don.

/reading: Can't say, I signed a non-disclosure. But it's good.

/imbibing: Coffee and Mt. Dew, clearing my head ;-)

Here Comes 1990 - Again.

Don MacVittie — Tue, 29 Apr 2008 16:41:48 GMT

The web, like most new technologies, was going to make life easier, speed delivery, cook you breakfast in bed.

And it did.

My life is easier thanks to the web - I can do research faster, I can order things without getting dressed, I can order from companies I would never have known existed and get that one geeky bit that never would have made it to Green Bay, Wisconsin, the Technological Mecca of the Midwest United States.

But have you pondered what it's done from a software perspective?

The web browser was designed to be a thin client, no intelligence, just a rendering engine with the ability to send bits of data back to the server.

But let us test today's reality. Do a clean install of your OS of choice, make it minimal for use as a GUI desktop. Then hit the web.

The first thing you find is that you need to install Java. Once you're done, you'll hit a site that requires Flash player. Need documentation? Download Acrobat. Then you hit that inimical site that requires the .NET engine. And don't even think about going to iTunes and downloading anything without installing something.

The web requires more software than we needed before it came along (unless you unistalled your word processor and are using Google's now. NOT), and in many organizations, the responsibility for installing that software falls increasingly on users. If it's not part of the corporate install then users have to hunt it.

Is it easier? Yes. You just go find it and it installs in most cases. But that doesn't change the fact that the thin client model is gone, tossed to the side of the information super-highway like the bag from your MacDonald's breakfast. You need disk space, you need processing power, and now, instead of just the OS sucking up resources you have the OS and the browser. The ever larger browser.

Is that necessarily a bad thing? No, if you as an IT staff member keep in mind that your users rely upon you to do their job and make certain that all of this software is part of the standard image. Disks have gotten huge, memory is cheap, and each rev of chips seems to add cores, so the only loss is in time invested. You can invest it once in the desktop/laptop image, or your users will invest it over and over on their own.

Performance is still an issue - many corporations run IE, which ships with limitations on the number of connections that can be open. Other browsers do too, but IE has to be changed in the registry, so if you lock the registry down, make certain the settings are set to something acceptable to your organization before the image is burned. In fact, most users shouldn't be mucking with browser config files either, so make certain the number is sane for whatever browser your corporation is settled on.

And we as an industry should be careful about how far we let this trend go. While I'd love to see our acceleration products fly off the shelves to solve your browser performance issues, we don't want to recreate the client/server environment with the client being the browser with 10,000 add-ons. If we're going to go there then why did we bother to upgrade our client/server systems? You haven't yet? No worries, you will.

The 90s were a great time to be in computers, lots to learn, lots of fun. But the progress was forward. Let's keep it that way, and not go revisit the 90s with a fat-client browser.

And don't even get me started about browser 'security'.

Don.

/imbibing: Mt. Dew

/reading: See yesterday's post.

SPAMbots and DNS Lookups.

Don MacVittie — Mon, 28 Apr 2008 12:46:01 GMT

Over the weekend, a bot network started sending spam with Lori and I's personal email addresses on them. No surprise there, it's not the first time our addresses have been used as a front to send out Viagra ads or offers for delivery in discrete brown packages. We've had these addresses since the early 90s, and they're plastered all about the web.

But this botnet must be pretty big because we're getting a ton of "return to sender" mail - I deleted over 200 when I got up this morning - and I didn't sleep all that long, newborn in the house and all.

The thing that bothers me about these failure notices is that a bunch of them come from appliances (and AOL) that have detected the email as spam, and it's returning it to tell me that I'm not allowed to be a spammer.

Nice. So flood my inbox with unsolicited email when all you really needed to do once you suspected it was spam was compare the source IP of the message with the IP of the nandgate.com mail server to know that it didn't come from me. Sure there's webmail and such, but if the mail server that sent the message was in Italy (one was) or Estonia (thanks AOL), and the most ironic, a Baracuda firewall sent me a rejection notice for a spam that originated from a Baracuda box in another country.

When all it takes is a lookup to determine whether you really want to spam the person whose email address is in the "from" field with a note that says this email is spam, you'd think it would just be standard fare. Particularly for companies like AOL and Baracuda. It's not, and it should be, after all, unsolicited is unsolicited no matter how it was generated.

So go fix it on your network, that'll be one less thing to delete for someone whose address is being used by a botnet.

Don.

/imbibing: Coffee and RedBull - I mentioned the child, right?

/reading: Back at Service Oriented Modeling, but it is dense and dry, so it's taking time.

FYI: I deleted 46 more notices while writing this. And I write fast.

Complexity breeds stupidity. Or vice versa.

Don MacVittie — Wed, 02 Apr 2008 20:33:27 GMT

We've all heard the stories about complex systems being defeated or subverted by simple expedients - like utilizing an old phone line with just-too-little power to mark it as a call, but enough to actually use the phone, or security auditors tailgating their way into a building. I've lived through a couple of those audits, and frankly, they're astounding. When your security systems are up to snuff, yet you're defeated by simple things like a little-known vulnerability in a web server or someone bluffing their way into the building - one auditor got half-way to the door at the end of the day with his escort, smacked his head and went "Oh! I forgot my computer in the conference room, be right back." leaving one escort having to decide which person to stay with, the one going back or the one who was still headed for the door. While away, the auditor lifted keyboards and looked on monitors until he had a few passwords, then grabbed his laptop and left, logging in half an hour later from a remote location with the help of the friendly employees that had left sticky-notes of passwords all over their cubicles. Thank goodness I wasn't the responsible manager through any of these ordeals.

The point is that these organizations all suffer from a similar problem - one most of us suffer from - over-complexifying (is too a word) topics that could be easy, or losing sight of the simplest solution to a problem. Sometimes it's the human element - like the sticky-notes, sometimes it's the technical element - like the analog phone line using power level for two different uses. But in all of these cases, no one seems to have sat down and said "what's the simplest solution to the problem of getting around this?" except the hackers/phreakers.

What's that got to do with you or DevCentral? The same thing is going on all over your enterprise, I guarantee it. People forget to look at problems from unique perspectives. People who are highly technical are more likely, in my opinion, to do so because systems tend to follow certain immutable rules. But a network or a Web 2.0 application is not a system, it is a complex network of inter-related parts that are more than the sum. And passingly more difficult to manage than the parts.

As I mentioned yesterday, we (the DevCentral Staff) are working on ways here to help you do more and be more adaptable, but looking about your workplace and the systems/network/applications you are responsible for from a different perspective can't hurt either. Yes, I do know that you're busy, but solving problems in unique ways takes more knowledge and insight than is gained by checking the server logs yet again. Take a look at your network holistically, where do all those connections go, what servers actually are carrying the brunt of the workload, and is there an inventive way (such as SOA) to offload some of it? Are the bottlenecks really necessary, or could you get around them by looking at the problem differently?

One auditor I worked with smiled at me and said "Yeah, the door is locked and the lock plate is reinforced steel... But the ceiling is a drop ceiling, want to bet whether I can get into the data center without opening the door? Or even if the wall goes all the way up, do you think it's made of anything that a utility knife can't cut?"

The door was not an obstacle to him because he looked for seriously off-the-beaten-path alternatives - stuff most people wouldn't have considered. In other words, there is no spoon.

That's the type of thinking we need every day in the enterprise if we're going to do more with less. Take a few minutes each day and ponder it, chances are that it will be well worth the investment.

Don.

/imbibing: Mountain Dew

/reading: Service Oriented Modeling by Michael Bell

Technically Accurate

Don MacVittie — Wed, 07 Nov 2007 19:23:13 GMT

Our great community at DevCentral sometimes gets so focused on the technology that we miss the greater picture of our jobs. ComputerWorld's Thomas Hoffman has an interview with John M. McKee wherein they discuss the dos and don'ts of a techie career.

Frankly, these are good things to remember, and on a daily basis when we are faced with choices like "do I work through lunch to finish this or can it wait?" we forget that we're in a larger environment that can have long-term impacts.

My favorite? Probably 4. Confusing efficiency with effectiveness. Lots of people fall into that trap. But 6. Knowing all the answers. is another common mistake.

Most of you (note I did not include myself in that one ;-) ) probably fall for 9. Failing to self-promote. Let's talk basic turkey here, if no one knows you're doing the right things at the right times and contributing to the success of your organization, there's a problem.

All in all a good read.

Now back to work so I have something to self-promote about...

Don

imbibing: Coffee

reading: No Phule like and old Phule