Have you tried rebooting?

How does cloud affect the storage infrastructure?

// November 16th, 2011 // No Comments » // Technical Know-It-All

Surely everywhere you venture these days, there is talk about Cloud. A year or two ago, it was limited to the Enterprise, but now it seems that its found its way onto the consumer space as well (eg; iCloud).

I’m not the foremost expert in cloud, but I think everyone’s got a definition for it today. You decide if what I’m saying makes sense.

Is cloud a product?
I don’t think so. Its almost like asking if Internet is something you can buy.

Is cloud a technology?
Hmm… in some ways, but not completely accurate.

My definition is really that Cloud is more of a CONCEPT (for providers) and SERVICE (for users).

Think about it for a second, all you ever hear about cloud is really about a service you can buy or provide. Example being, IaaS (Infrastructure as a Service), PaaS (Platform as a Service), SaaS (Software as a Service) and etc. So don’t be completely fooled when vendors trys to sell you Cloud…

I think in-terms of storage, what vendors are really selling would probably be better termed “Cloud-Enabled“.

Features such as thin provisioning, wide striping, data resiliency, storage virtualisation, dynamic tiering and charge backs tools are some of the key features that makes sense to a cloud deployment. How so? I’m not gonna deep dive into the details but hope you will get the drift…

If you ask me, Cloud is just another buzz word in recent times that describes the evolution of the IT industry… Lets take a stroll back memory lane…

1. First there were built-in hard-disks. We realised that utilisation was low, so we built SAN’s for “sharing” storage.

2. We built the PC, but we wanted to communicate with the next PC. So we hooked them up. We realised then, we needed to “share” data with more PC’s, thus we built the LAN, then later the WAN, then the Internet.

3. Servers were great functioning as physical boxes. Again, low utilisation meant that we wanted to “share” to better utilise the resources. Tada… Server virtualisation!

4. Now we have SAN’s, NAS’s and etc. We realise that every vendor talks their own language. EMC doesn’t link with HDS and vice versa. So we have pockets of storage that is not properly utilised. If you don’t already know, this is now happening, and its called Storage Virtualisation, where all storages are consolidated into a single pool regardless of vendor. So we can “share” more efficiently.

5. What’s next on the roadmap? Not too sure if you have heard, FCoE and CEE is around the corner. In a nutshell, that is again, consolidation of SAN and LAN, so the networks can “share” a single common infrastructure.

So, if you look at the 5 points above, the common word amongst them is really sharing (in the enterprise, it’s better known as “cost saving” ).

Looking at cloud again, we combine all of the above, and again look at the possibility of further reducing costs and/or sharing. And the Cloud is born. Use the existing infrastructure in its entirety and share it out at a higher level.

So when shopping for your next enterprise purchase, be it storage, software or servers, make wise decisions as to how its features can be shared. Do not just take the vendors word for it, cause some just don’t quite make sense.

SAS vs FC Disks

// November 8th, 2010 // No Comments » // Technical Know-It-All

In recent times, there has been much said about the future of SAS (serial attached scsi) vs FC (fiber channel). Don’t get me, I’m not saying that FC is dropping dead tomorrow. It is probably still relevant for another 3-5 years, but I for see the future in SAS disks.

Here’s my quick lowdown on it. In no way conclusive, but its something to ponder about.

1. Why SAS?

Why the crap not? SAS is a fraction of the price cheaper, has a strong roadmap moving forward with 6Gbps today, and moving ahead in the future to faster backends. FC has been at 4Gbps for the longest time and have not moved an inch since. It also doesn’t have a roadmap to go any further beyond 4Gbps.

SAS also comes in 2.5″ variants. Have a real estate or green issue? Here’s to a smaller, lighter and greener media.

2. But SAS is Tier 2 disks

How do we define Tier 1 from Tier 2 disks today? Reliability and performance.

In terms of reliability, SAS disks are manufactured and developed to the same specifications of a FC Disk. The only difference is the connector / interfaces at the backend. The likelyhood of a SAS drive failing is the same as a FC drive failing.

Performance, used to be a big discussion point because SAS ran at 3Gbps, but now with 6Gbps and a non-arbitrated loop architecture, it is blowing FC off it’s socks. No discussion there.

3. SAS is SATA’s expensive cousin

Very good observations there. True! The commonality here is “Serial”, and because of that, you can now intermix SAS and SATA disks in the same enclosures. No need for different enclosures for different disk types and no more for funky FATA disks. Go forth and intermix. Beyond that there is nothing similar with regards to the built of the drives.

4. Not convinced still?

Surely vendors like Hitachi Data System’s (HDS) or even IBM can’t be so far off their socks. Hitachi for example have a Hard Disk’s Division that only builds drives. Their business is far far larger than their HDS counterparts. So do you think they will just drop their FC product roadmap just to help out a smaller subsidiary of theirs? Or do you think they are considering the shifting market trend?

Ultimately, there is always the opinionated Google that speaks for itself.

Does staff loyalty still exist?

// April 22nd, 2010 // 1 Comment » // Technical Know-It-All

Before I joined the work force many years ago, I never quite understood why employees these days rarely stay beyond 3-4 years in an organisation. Are those days where employees work for 10 years or so in a company gone, or is there something that either the employers/employees aren’t doing right?

Now, after being in the industry for a while and experiencing it first hand, I think I’m beginning to understand more. Here are my views from a techies standpoint.

1. Technically sound professionals are usually very loyal to an organisation if treated right. For techies, 2 key factors play a part in this. The opportunity to learn or upgrade their skills and their relationship with their reporting managers. While monetary returns are usually important, it is probably not the most important element when it comes to techies. Techies like to be challenged and need to stay sharp, that is why training is essential. Being stingy on training because of cost (economic conditions) is not exactly the best of excuses because cost is usually easily allocated to other departments that are perceived to be more important than the IT teams.

2. Relationship with the manager is probably the key factor behind staff loyalty that applies to all fields. If you can’t get along with your managers, no matter how much you like your job, it is always gonna be a challenge. Truthfully, there are only 2 ways around it. Live with it or just leave. Many experienced techies usually leave an organisation for greener pastures but lesser experienced techies will just live by it. I used to be in the “live by it” class, but I have come to realised that change might not be such a bad thing. I guess if its already bad, it can only get better right?

3. Company loyalty = Staff loyalty. Organisations these days are so much about dollars and cents that they forget that it is the people within it that drives the business. A happy staff equals a profitable company. Why don’t organisations realise this? Google isn’t up there because they slave drive their staff. Imagine programmers dragging their feet to meet a dateline, and marketing staff slacking off. How is that gonna help Google? Many companies are getting rid of the junior staff in favor of senior staff with the reason being, “bad economic conditions”. How many junior staff does it take to equal the salary of a senior director (that has potentially led the organisation into this mess)? Staff loyalty only exist if company loyalty exists. Period.

4. Cronyism is another big factor that deters many from staying in an organisation. While it is more discreet in Western work force, it is exceptionally prevalent in Asian organisations. Everyone likes to be boot-licked. Yes, I do agree. But we must be wary that it does not become a dominant culture. I’m not saying that all brown-nosers are incompetent, but the majority of them are. This will severely impact the organisations performance, not to mention that you will potentially lose valuable staff because of this. Techies like myself, just despise cronyism. Why? I suppose we are just geeky and we like to stand for whats right I suppose. .

Re-Training Technical Staff

// April 22nd, 2010 // No Comments » // Technical Know-It-All

“We have a new product and you need to get up to speed with it. Please make sure you learn it up”

Sound familiar? I suppose it is something that we get all the time as techies. I do understand that, we are paid to be techies because of our ability to grasp technical concepts and understand them easily. But sometimes, I feel managers should understand that technology is not generic. There is a significant difference between the skillsets of an IT Engineer and a NASA Engineer. Agreed?

While it may be possible for an application engineer to be a database engineer overnight, it is usually very very difficult. Even if they were to achieve it, they are usually not going to be as good as someone who has been working with databases all their lives.  It is becoming so common these days with the various mergers and acquisitions in the industry, that tech staff have been asked to learn various contrasting disciplines and given little time to get up to speed on it.

I always believe that in order to convince a customer to purchase your product, you will have to first know and believe in your product. Obviously, that is not the case. Tech staff are constantly blamed for not knowing the product well enough and not enabling the sales team to perform better.

Bottom line is this. Give your techies time to get there, and provide significant investments to get there. Do not expect to have your techies learn a new skill without providing training and equipment. You don’t get good at riding a bicycle without a bicycle now, do you? If speed is of essence, invest in a new headcount. Contrasting disciplines are not easily attainable overnight. For example, don’t expect a Storage Area Network (SAN) expert to be a Wide Area Network (WAN) in 1 week. The only thing common between them is the word “network”.

Horses for courses!

IT Project Management in the Real World

// March 9th, 2010 // No Comments » // Blogroll, Technical Know-It-All

It is just one of those things in the IT world that is “ultra subjective”. The debate here is simply whether a PM managing an IT project be technically sound (with a technical background) or should the PM be a true blue (by the book) type PM.

I have worked with many Project Managers in my time, and I must say it is probably not one of those jobs that I envy too much. To give credit to the PM’s out there, it is one helluva difficult job. Having said that, difficult doesn’t mean that PM’s have the excuse to slack off. To be honest, being a technical consultant is not easy too and it also doesn’t mean we can just simply rock up on site and start configuring stuff and just walk away saying, “sorry I just broke your system” right.

Here are 3 little tips to what a perfect IT Project Manager should have (or at least according to my definition).

1. I personally feel while there are good PM’s out there that doesn’t have the most in-depth technical knowledge, it should be a pre-requisite that IT Project Managers have had experience in the technical side of things before. Technical PM’s will have a better understanding of the challenges the technical folks face. As much as the PM needs to know the business objectives of the project, what many PM’s fail to understand is that technical staff have technical objectives as well. The requirement will come as such, “we need to get this done in 2 weeks time. period!”. It sounds like a lot of time 14 days, but non-technical PM’s don’t know is that sometimes problems crop up, and resolution time may or may not be as planned. For example, if you come upon an unknown bug that you have never seen before, its really a trial and error attempt until you fix it. So it could be 1 hour, 2 hours or maybe even 48 hours. Who knows! So, always always check with the technical folks the exact amount of effort needed to complete a job plus 10-15% of risk time.

2. Technical staff do not want to be caught in the politics. “we need to work on this because we need to protect this account and etc”, “we need to not say ‘this’ because it will cause ‘this’”. I can’t remember the amount of times I have had gone through this. As much as this is unavoidable, if possible, try to leave your technical folks out of the whole political landscape. Manage it from the project management side and have yourself as the single point of contact. This ties back to Point 1, because in order to be the single point of contact, the PM will be somewhat tech savvy. Technical folks are good at handling the 1’s and 0’s but may not always have the bandwidth/ability to juggle politics. For us, the machine will either work or don’t work. It will never have a hidden agenda.

3. Technical staff do not like to lie (not technically at least). Many a time, I have seen PM’s make technical consultants commit to timelines and objectives for their own personal agenda, or even worst commit it on their behalf. There is a fine line between optimism and lying. Technical folks generally don’t like lying because their reputation relies on their ability to call it as it is. This is somewhat different from traditional sales folks, where customers know you are there to make a sale. So as a PM, if it is bad news, work your magic and convey the message gracefully, do not butter and sugar coat it and get the techies in trouble.

I am probably underestimating the role and difficulties of a PM and might not completely know what it takes to be the best PM, but one thing I know for sure are traits that will make a bad PM. So hopefully, those aspiring to a PM can take some notes from this.