Well, we're a good 20 years into "making IT more Agile", and I'm going to ask what we all want to know...

Are you more agile, or just different?

For most enterprises, I suspect the latter. While web technologies made it easier to develop application UIs, connecting those UIs to the back-end is generally more difficult and management (except for deployment) is without a doubt more complex. While XML is easy on the eyes, there's little indication that it's faster to develop for than a flat-out binary structure - more interoperable? Undoubtedly. Faster to develop for? Some claim so, I don't see it. And while today's websites are scalable to millions of users, it takes a whole lot of work to get there.

In short, the problems have shifted slightly, but are you truly more agile? For all of our advances, we're still using the basic mail servers we were using ten years ago, they're just a lot busier. Our networks are still IPv4 and we're still struggling with the correct VLAN configuration. New server admins still spend a ton of time figuring out how to get the drivers onto those big beefy servers and configured correctly, and we're still developing a lot of our enterprise apps, just the platform has changed. Meanwhile, other areas - like the language du jour and security - just keep getting more complex.

And across the board, users still seem frustrated. IT has been defined as a service organization, so sometimes users won't be pleased, but most of the time it should be possible, if we're making progress.

Our products can do much for you - virtualization, web acceleration, load balancing, other ADN functionality, NAS virtualization... All of these things help you handle the increased volume - of users, of storage, of spambots... But it seems for every problem our industry solves three new technologies and a new design methodology surface. It is passingly difficult to adequately serve the needs of users when the "needs of users" is a moving target, let alone when the tools to meet their needs are changing also.

As I've said in other posts, focus is your best option. Use products like ours to free up your time, then prioritize based on organizational goals and breadth of applicability.

The automated data center is on its way - both from the many-to-one perspective as LTM manages (many servers, one IP), and the one-to-many direction as VMWare and competitors are answering (many operating system instances, one server). Between the two, all of your adaptability needs are covered, and just in case, you have the cloud to outsource non-critical or constantly-changing applications. Stay on top of these developments, as they will continue to free up your network and systems administration time, and allow developers to focus on the business problem while worrying less about the network.

Certainly your workload will continue to increase, and you're not likely to get more staff (have I said this before?), that means you will have to cut out work where possible, use technology to make your life bearable - and to make your data center truly more adaptable. Fast is good, fast and effective is far far better.

Share this post :

Don.

Doug Washburn has a good post about PC power consumption that you could dump into the "Green IT" category.

It's not about saving power in the data center, it's about all of those desktops that are left running each night. And it's pretty accurate. Funny thing is that somewhere along the line, everyone stopped powering down on their way out the door.

BIG-IP LTM can help power down underutilized servers by distributing the load to other servers in the pool, but that would be a few high-power-consumption machines. Likely that won't touch the savings of thousands of turning off those running desktops each night.  Of course it depends on company size, but that's a two or three minute investment for each employee at the end of the day, and according to Doug (quoting Energy Star estimates) the return is $25-75 per year per PC. Can't sneeze at that.

Just thought I'd pass it along. Saving that kind of money with a policy change is bantered about a lot, but rarely actually pans out. This one is so simple that it actually will save you money.

Share this post :

Don.

Great post by Walter Bright over at Doctor Dobbs (always my favorite programming mag) about what college classes you need to be a programmer. While there are some I disagree with - Lori thought she didn't need calculus for programming either, but then we went into Geographic Information Systems (GIS), and guess what? GIS - at least the vector parts and distance in raster parts - is calculus and geometry with a database attached. Lori picked it up quickly of course, but it could have been less painful.

I would add OS design to his list - knowing the architecture and knowing software design theory does you little good in the age of Virtualization. And I'd remove Jet Engines, replacing it with military history (because security for sure shares a lot with military history, and much of CS could learn from it) - in the same spirit that he included Jet Engines ;-).

I would also swap the location of physics and business accounting in the list - not having physics doesn't limit your career options, not understanding the basics of how businesses work will limit the options of the most geeky of us eventually.

And I'm a fan of learning one of each type of language - he included assembly language, I would add a low-level compiled language like C or Pascal and a higher-level language like Java or C#. Not because you'll use that particular language, necessarily, but so that your entire experience with them isn't with the theory of their workings that you picked up from that one chapter of your compiler/interpreter design course.

Anyway, I'm sure you'd all customize that list also, but thought I'd bring it to your attention. Read the bit on economics, it is both funny and true.

Don.

Share this post :

/reading: Sept/Oct Archaeology Magazine. A good read this issue.

So we were discussing relationships today, and I got to thinking of the parallels between relationships and vendor relations. Lots has been written on the topic, but I'm never shy about throwing my two bits out.

It's interesting to me that when a person sets their sites on you they are often putting on a mask - the first six or eight or twelve weeks of a romantic relationship are sometimes different than reality. People are on their best behavior at the start of a relationship, and you see the world through somewhat tinted glasses - most of us rose-colored, but no doubt some of you are analytical enough that I'll just say tinted. You trip along merrily thinking the world is a very cool place and wishing you could spend all of your free time with this person.

For some of us lucky ducklings, that feeling continues on unabated. I'm one of those. Thirteen years in and I still think Lori's the perfect woman for me. She's not the perfect woman for you though, she's married. ;-) For most relationships, once the make-up comes off and you have to deal with this person on a daily basis - without the shield of perception but in the harsh light of reality, you find faults. For most relationships those faults are condemning. That's why most of us date a lot more people than we marry.

The same is true of IT purchases. The problem is that it's far easier to lose a girlfriend/boyfriend that turns out to be difficult than it is to lose a technology that isn't all that you expected. And the same type of hype goes on during the sales cycle as goes on during the courting cycle. It is the sales representative's job to sell you products, not to point out the weaknesses in those products. And third-party accreditation has become a market unto itself, so while some test labs and analysts go out of their way to be truthful, for most taking their word is like asking your new girlfriend's best friend if she's a worthy person. Of course the answer is yes, they're invested in each other.

So the conversations are somewhat parallel...

You: I like stock car racing.

Her (in an evening gown): Me too!

Is functionally equivalent to

You: We have this business problem.

Sales rep: Our product is designed form the ground up to solve that problem!

Is it all sales reps? No, there are a fair number out there that are trying to help you solve your problems and believe that their products will do just that. Of course, they wouldn't be very good sales reps if they didn't believe that, so the question of applicability to your problems is still valid.

The reason that relationships end up with you finding faults is simple, this person wasn't hand-made for you, they grew up in a different environment with different inputs and experiences. That makes for great variety but also causes a lot of seemingly promising relationships to bottom out quickly.

Have no doubt, the same is true of your IT purchases. That product wasn't made for you, you're going to find things that you wish were better. After all, a database or an Application Delivery Controller are not going to solve your business problem, only give you the tools to solve it yourself. You have to work at it, much as you do at a real-life after-the-makeup relationship. So be aware of that, lots of things sound great in the sales pitch that don't pan out long-term, or that the work required to get there is too much.

The best you can do is some research to try and ferret out the weaknesses others have encountered - see what others who have dated your vendor think after the makeup came off. After all, there is no eHarmony for vendors.

The other thing you can do is ask some questions about how to work around unknown weaknesses. Ask about adaptability and programmatic interfaces - see if you can make your long-term relationship with this vendor into what you want with a bit of extra work. iRules, profiles, and iControl are part of our answer to the "we can't be your perfect life-partner out of the box" market reality of ADCs, which means you can make us into your perfect mate. Other vendors in every space should be doing the same - just ask them, because should be is not the same as are.

If you don't ask those questions, you may find yourself sitting in your datacenter late at night, trying to resolve your issues and listening to the blues.

And that's a great question for your next date too - "Are you adaptable to become whatever I want, whenever I want, even if it changes over time?"

/Just sayin'

Don.

Share this post :

Wow, I was surprised at the number of people who were interested in my multi-core post. It's spawned a whole lot of email plus the comments on the post itself (note - I prefer comments on the blog post, then others can see your generally good commentary).

In response, let's talk some more about it!

First off is the link sent to me about Bjarn Strostroup discussing the new C++ standard (C++0x) slated for vote in 2009. Sounds like great fun to me, we'll see how timely it is though since this is a problem today.

Next up is the comment from Ilya at Cilk Arts. Her comment prodded me to go out and look, since I hadn't heard of Cilk Arts before - very cool stuff, if you haven't seen it and you do C++, check it out. Note that the video about quicksort is just a tiny bit disingenuous - quicksort screams to be parsed out to multiple CPUs. Of course, it's marketing material, so they picked the best possible use-case, so don't judge them too harshly for it. Just don't expect that all your applications will see that kind of performance improvement.

Ilya mentioned several other vendors, and while it's a stretch to say I need to research them for my job, you all should care because it affects the data center, so I'm going to use that excuse to go research it :-). So there will be a part three in this series, perhaps more.

Meanwhile, keep doing what you do - giving your business the best systems you can with the budget and constraints you have - and I'll try to get you advanced info on when/how the multi-core conundrum will be solved.

Don.

Share this post :

/Reading: Nada. I'm currently between books. Got a suggestion? I like fantasy and tech books along with military history, occasionally read business books. Drop me a line.

Fortune has an article about multi-core CPUs and the struggles of software to make use of them.

If you follow software development at all, you knew this was coming, and like a car crash, can't seem to look away, though you know it's going to be ugly.

And it is all a question of market maturity. Funny thing about computers, in many ways the market has grown up over the last 20 years, but due to an endless stream of innovation, in many ways it hasn't.

This particular problem is probably the best example we have of this phenomenon.

Not every car needs to be a Maserati when a beat up old Ford will get you to work every day. This is common sense applied regularly in every industry and field of endeavor out there - you don't send strategic bombers to blanket the country where a bank robbery is occurring. And yet in computers, bigger and faster is always assumed to be better for every application. That's where the first, truly useful, wave of Virtualization came in - putting all of those servers that were using a tiny percentage of their resources together on one box... Because we always had to have the newest, fastest box. Many of you are about to decry "but that's all they sold..." yeah, that's a part of the problem. The other part is that while you're bringing in the faster bigger brighter box through the front door, perfectly serviceable boxes were going out your back door as "too old".

The other part of the problem is that this is a tools issue, not a developer issue. The vast majority of developers in today's world are focused on business problems, not technical problems. With millions of developers across the globe, asking them to do what we would have done even 10 years ago - relearn everything to the "cool new standard" - is not acceptable. Some will, no doubt, those who, like me, are intrigued by difficult programming problems (in my case preferably close to the metal), but most won't. It's not their job. Even if it was their job, the state of software development is such that most development occurs in virtual machines or as interpreted languages - not development that could or should have to worry about what the CPU is doing. And honestly, for most enterprise developers, their eyes glaze over when you start to say "parallel development". Start talking about atomic operations, protected code segments, and locks, and you'll lose them completely. That's no business problem.

So what do we do? Well, the tool vendors need to figure it out. Either your VM can handle multiple CPUs or it can't. Just let us know, so we know whether we need more cores or more boxes when the time comes. You could lay this at the feet of OS vendors - and I could make that case since that's one of the ways the development tools could be generated - but do you really want your OS wasting even more cycles worrying about whether your machine is multi-core or not? Yeah, me either.

Do I wish I was involved in the research? Oh heck yes, that type of development is really fun - in that frustrating until you get it sort of way. Do I think that Fortune mis-represented the problem? Only kind of. They never come out and say that the Enterprise should be worried about it, but their target market includes C-Level execs, and they never clearly state that this is not - and should not be - an enterprise problem either. Tool vendors and in some cases appliance vendors will have to struggle with this problem, but enterprise developers? Nope.

What can you do in the meantime? Well first off, don't oversize too much. Unless you're certain your app can take advantage of multi-core, it may not be doing you any good. Second off, when your application outgrows that server, save it as a hand-me-down, don't let Bob take it home to add to his network. Other apps likely don't have the same sizing requirements. And finally, watch the smart folks at Intel and AMD, that's where the problem is likely to be fixed first... Intel sells a C++ compiler that can directly take advantage of multi-core, so they're on the road to the solution, just need a little time to bubble it up to more commonly used enterprise languages.

Don.

/Reading: M10 GMC in Action

Share this post :

I've said this before, even asked this less formally before, but we've got 3x the users we did just around a year ago, so it bears asking again.

As you no doubt could guess, we spend quite a bit of time talking about what kind of content we provide to you and what will provide you with the best information in a timely manner.

Our dilemma is of course that there are 30,000 of you and four of us (five if you count our fearless leader, a few more if you count the extended team), and while some of you provide excellent content that helps us out a lot, we still have to focus our time on what will help the most of you or items that will tell you about things you may not have been considering. It's a struggle that we engage in pretty regularly, trying to balance our coverage.

The thing is, we can make these determinations in a vacuum - we know why you're here - but prefer to get your input so that our coverage is focused on what you feel is important. We've got a six month calendar to guide our coverage, but want your help making that calendar even more useful.

With that in mind, I'm dropping you a poll to see what you think.

As long as I was bashing statistics yesterday, I thought I'd do the same today, this time hitting up TechCrunch and their article about bloggers going to jail and how the number is going up. It amazes me that Mr. Shonfield didn't even bother to correlate this number to the number of blogs, because the rate of bloggers going to jail is actually decreasing at an amazing rate - indeed, utilizing his mind-set, law enforcement should step up its efforts to police blogging!

Indeed, the data (sourced from World Information Access) overall is bogus in my opinion. If you want people to take protecting bloggers seriously, you must put things into context. Since 2004 the number of bloggers has increased by hundreds of thousands - literally hundreds of thousands - of times. According to Technorati's about page, they track 112.8 million blogs, and that's just what they're tracking. Yet the point of this blog post is how horrendous it is that the number of bloggers arrested has gone up seven times. To their credit, they do attempt to list only cases where blogging was the actual cause of the arrest, and even then there were some categories they were not willing to include. So it wasn't a numbers grab on WIA's part, though TechCrunch wanted you to see it as horrific, and thus the article is dubious at best. The net effect is like saying "More deer are dying in traffic accidents!" without pointing out that the herd went from 10 deer in Minnesota to covering the plains states like a blanket.

In a world of wide and free information access, there comes the burden of thorough analysis. Trying to attract attention by over-inflating the numbers is lying to pander for clicks. It's no surprise coming from a place like WIA, but beneath what one should be able to expect from an organization like TechCrunch.

Here's hoping that they take some forethought before pandering to the crowds in the future... But if not, at least this post drove me to find details on the number of blogs out there, which was pretty interesting.

Don.