Why run 64-bit Windows?

Am sure by now majority of the platforms are and considering moving on to 64-bit platforms. If you aren’t yet sure of why’s – boy, you really are planning for a retirement, aren’t you !? No, its not mandated, but if scalability, vendor supportability and performance bothers you, then better think about it.

Now, there’s no point in re-writing what more experienced people have already summarized in way more details. But, here’s the reference for your considerations:

- Why run 64-bit Windows?

- Why run 64-bit Linux?

Now, amidst x86 and 64-bit decision, Itanium yet remains a question mark? HP and Intel have committed that they will continue to develop on it. But they dont seem to be showing anything promising beyond next planned version. Couple of Database Vendors (Oracle, Microsoft) have called out for Itanium phase-out already. Though others (IBM DB2, PostgreSQL, Sybase) are absorbing this as an opportunity to increase their footprint. If you ask me, I never liked IA platform much. Not that its bad anyhow, but it broke the most crucial backward compatibility. That’s a big no-no when you talk of Enterprise platforms. And that proved to be one reason that Industry was slow to get along with this Intel-HP development. Specifically, given today’s situation, it would be wise to look at what your data-vendor is supporting and what goes well within your existing/planned server farm.

Service Level Agreements (SLA) or Service Expectations

Every now and then you jump onto an article and on the first read they sound so… correct. Read them again, and may disagree to it !

A recent article on Gigaom is one of similar lot to me. It goes suggesting SLAs arent of much help, and one shall rather be worrying for Service Expectations. I suggest we revisit that.

SLAs are as what they stand for, an agreement – on basis of which a service level will be measured (and vendor paid up for). Service Expectations are some intangible facts and boundaries that a vendor shall understand and attempt to abide with before putting forth a SLA proposal – as they might have a direct impact on client’s business.

Now, there is a different between a mass offering and tweaked business/technical solution. A mass offering, as generally provisioned by Retailers & Utilities providers (cloud computing inclusive), only comes with a generalized SLA. E.g. amount of time service vendor would be able to keep the service online. Matching each SMBs (or small applications of big clients) service expectations would rather be next to impossible. As in any retail business, challenge here is to put out a service in market which excites majority (not, all) of potential clients by value it delivers. And it shouldn’t stop at point of excitement and buzz generated, but goes way to the point of meeting what you committed to masses. And you report it using SLAs.

A tweaked business / technical solution, on other hand, looks upon each and every business and service expectation for the specific client service is getting designed for. There are times when I have seen different SLAs being proposed for different times in a day / weekdays / weekends – for the same client. But that’s generally in the cases where you have a dedicated consumption line/resources (in some cases, private clouds inclusive). Though, once you have understood the expectations, have drafted the SLAs, you report back using those agreed SLAs – whether or not you are able to deliver.

Now, in any case, it would be bizarre to say I would give away SLAs as am concentrating on Service Expectations. Anyways, dodged SLA reports doesnt highlight Service Expectations more than the need for Business Ethics I would say. For retail business cases, an honest SLA report helps you consolidate current users confidence in your service, and in gaining new business. For bulk business cases, you definitely will have to start with understanding Service Expectations, but SLAs will hold equal importance so you can showcase whether or not you are able to meet those Expectations. Now, there are multiple things that goes out public in those monthly/quarterly/yearly review/reports, and SLAs should definitely be part of it !

 

Vikas Rajput

Solid State Disks

SSDs are in place for quite a while. Still they are struggling a bit in making their way into main stream. We, as human, prefer to believe in what other’s have to say, even if its nothing but blabbering. If you doubt it, go and ask your Admin if they know SSDs perform well then HDD? And if they know performance gains, ask why aren’t they fitting in SSDs in servers if they perform well, surely they might be having Cost over Benefits analysis !?

Well, to be honest, I too was one among those DBAs till the moment I got into a conversation and decided to find it out. Well, the current reason is problem called write amplification. SSDs are good for read based operations, but they fall back when data update comes into picture, not so badly, but they do. Another explanation is that current File systems are frankly written with HDDs in mind, they alleviate the mechanisms SSD uses as its shortcoming. e.g. in NTFS an update only needs to flip a bit, while its really not the case in SSDs.

Here’s the most promising paper on this topic which explains SSDs a lot better than I ever can, and much more than what I just scribed above.