Daily Archives: September 17, 2011

The demise of the IT engineer?

Scott Lowe is one of my favourite virtualization experts. I have 2 of his VMware books and his latest book on VMware 5.0 will be out next month. He is currently the CTO of EMC’s vSpecialist team and in one of his blog entries, he spoke about “The End of the Infrastructure Engineer” or IT Engineer in our local speak.

I wrote about having the Cloud will be forcing many of us to be out of our jobs last month. I mentioned that the emergence of Cloud Computing will be superceding the roles of system integrators and resellers, because the Cloud Computing Service Provider will bypass these 2 layers and goes direct to the end user or customer. This will render the role of the IT engineer less significant when they are working for the reseller or partner. Scott’s blog goes a step further saying the the IT engineer role will be gone and they could be forced to be in the application development space for Cloud Computing.

The gist of my blog last month was to get the IT engineer to think deeper and think how they should evolve to adapt and to adopt to this new Cloud paradigm. In Malaysia, in my almost 20-years of IT in the Malaysian IT scene, I have seen the decline of IT engineer. I don’t see many of the younger generation to taking a passionate and enthusiastic fire to enhance their skills and learn even more than it is required for their job. This is a sad thing and through my voluntary work with SNIA Malaysia, I hope to get some of the senior engineers (despite all the fancy titles, we are still pretty much engineers) to get off the fence to start a strong IT community on storage networking and data management technologies. I am strong believer of “If you build it, they will come”.

I agree with what Scott has mentioned, that the role of an IT Engineer will not go away because you will always need an IT Engineer (or Infrastructure Engineer) to manage the infra. But the jobs available for these positions will get scarcer and lesser. So, to those IT engineers who are just so-so, (ooops), you are not good enough anymore.

Perhaps it is a chicken-and-egg thing to say that if there’s no market, why should the IT engineer learn something more to be different and enhance himself/herself. But if this chicken-and-egg debate thing was to continue, then we will forever be trapped in a loop that does not change our status in IT. We will be forever in a rut while others continue to pass us by.

I am always amazed by the amount of intelligent people drawn to the Silicon Valley and with the reknown technology universities such as Stanford, UC Berkeley, MIT and Carnegie Mellon continue to innovate, we continue to see the birth of better, greater and disruptive ideas coming out from Silicon Valley. The IT community in Silicon Valley is very strong and we continue to get IT people challenging the status quo and be different. And more and more “Silicon Valley”-like communities are birthing around the world. Malaysia, in my frank opinion, spends too much time glamourizing (if there’s such a word) IT (or ICT in local Malaysian terminology) and does little to address the core of IT. Our IT people are too complacent and too obedient to be different.

So, here’s my argument to the skeptics of this chicken-and-egg thing. Yes, we only do what we must do to earn our pay for the bread-and-butter stuff in our Malaysian IT, but it is also time to break out from this loop. It’s time to be different, and it’s time get deeper into IT.

Nothing gives me the creeps to see an IT engineer going out to the customer and start pitching speeds and feeds. Come on, any customer could read that off a brochure or a datasheet! So there is absolutely no value in the IT engineer if they only know how to pitch speeds and feeds. Get to know in depth of the solution. Get down into the hardcore of things like the philosophy of the design of the solution. Learn deeper about technology and even better, start thinking of new ways to challenge what’s already out there.

I spend a lot of time learning about file systems in storage networks and that’s my passion. I hope that more IT engineers would break away from the norm to do more. Believe me, as Cloud Computing becomes more prevalent in the Malaysia IT scene, there will be demand for damn good IT engineers, not the ones who knows only speeds and feeds.

Using simple MTBF to determine reliability to Finance

The other day, a prospect was requesting quotations after quotations from a friend of mine to make so-called “apple-to-apple” comparison with another storage vendor. But it was difficult to have that sort of comparisons because one guy would propose SAS, and the other SATA and so on. I was roped in by my friend to help. So in the end I asked this prospect, which 3 of these criteria matters to him most – Performance, Capacity or Reliability.

He gave me an answer and the reliability criteria was leading his requirement. Then he asked me if I could help determine in a “quick-and-dirty manner” by using MTBF (Mean Time Between Failure) of the disks to convince his finance about the question of reliability.

Well, most HDD vendors published their MTBF as a measuring stick to determine the reliability of their manufactured disks. MTBF is by no means accurate but it is useful to define HDD reliability in a crude manner. If you have seen the components that goes into a HDD, you would be amazed that the HDD components go through a tremendously stressed environment. The Read/Write head operating at a flight height (head gap)  between the platters thinner than a human hair and the servo-controlled technology maintains the constant, never-lagging 7200/10,000/15,000 RPM days-after-days, months-after-months, years-after-years. And it yet, we seem to take the HDD for granted, rarely thinking how much technology goes into it on a nanoscale. That’s technology at its best – bringing something so complex to make it so simple for all of us.

I found that the Seagate Constellation.2 Enterprise-class 3TB 7200 RPM disk MTBF is 1.2 million hours while the Seagate Cheetah 600GB 10,000 RPM disk MTBF is 1.5 million hours. So, the Cheetah is about 30% more reliable than the Constellation.2, right?

Wrong! There are other factors involved. In order to achieve 3TB usable, a RAID 1 (average write performance, very good read performance) would require 2 units of 3TB 7200 RPM disks. On the other hand, using a 10, 000 RPM disks, with the largest shipping capacity of 600GB, you would need 10 units of such HDDs. RAID-DP (this is NetApp by the way) would give average write performance (better than RAID 1 in some cases) and very good read performance (for sequential access).

So, I broke down the above 2 examples to this prospect (to achieve 3TB usable)

  1. Seagate Constellation.2 3TB 7200 RPM HDD MTBF is 1.2 million hours x 2 units
  2. Seagate Cheetah 600GB 10,000 RPM HDD MTBF is 1.5 million hours x 10 units

By using a simple calculation of

    RF (Reliability Factor) = MTBF/#HDDs

the prospect will be able to determine which of the 2 HDD types above could be more reliable.

In case #1, RF is 600,000 hours and in case #2, the RF is 125,000 hours. Suddenly you can see that the Constellation.2 HDDs which has a lower MTBF has a higher RF compared to the Cheetah HDDs. Quick and simple, isn’t it?

Note that I did not use the SAS versus SATA technology into the mixture because they don’t matter. SAS and SATA are merely data channels that drives data in and out of the spinning HDDs. So, folks, don’t be fooled that a SAS drive is more reliable than a SATA drive. Sometimes, they are just the same old spinning HDDs. In fact, the mentioned Seagate Constellation.2 HDD (3TB, 7200 RPM) has both SAS and SATA interface.

Of course, this is just one factor in the whole Reliability universe. Other factors such as RAID-level, checksum, CRC, single or dual-controller also determines the reliability of the entire storage array.

In conclusion, we all know that the MTBF alone does not determine the reliability of the solution the prospect is about to purchase. But this is one way you can use to help the finance people to get the idea of reliability.