Tag Archives: Servers

Mainframe 3.0

by Scott Kantner, May 18th, 2012 in Cloud Computing, CTO, Industry trends, Servers, virtualization

Great ideas in technology don’t change, though they do change forms.

Courtesy of Sega

I started my corporate IT career near the end of the Golden Age for mainframes – just prior to PC’s taking off in corporateworld. SNA networks were de rigueur in enterprise shops and 10Base2 Ethernet and Token Ring were considering leading edge tech. (If you had a deep understanding of everything in that last sentence before following any of the links, contact me – I’d like to buy you lunch). Read more »

Keep The Change

by Scott Kantner, June 23rd, 2010 in Human Factors

Does this sound like your IT shop?  Reports from the Uptime Institute consistently show that the majority of reliability and uptime woes aren’t caused by hardware,  facilities, or utility failure – they’re caused by humans, and what pray tell are those humans doing?  They’re changing things, and often too much of the change isn’t planned, approved, or documented.  Or, there is simply too much change going on at one time.

Much like a bomb is meant to explode, technicians are meant to be technical, so it’s a bit unrealistic to assume they’re giving a lot of thought to managing change, much less be fond of doing so. They just want to git ‘er done, and in large part, we pay them well to not only do that, but to do it right the first time.  Hard core techies, the ones that really know how to make things work, typically aren’t also wired for sitting in management meetings. The problem with managing change is that it’s boring. It’s not technical. And explaining highly technical things to non-technical folks in a change management meeting is not always the average techie’s strong suite, nor perhaps the best use of their time. To the contrary, it can be a very frustrating experience for them, which can lead them down the Dark Side of making changes beneath the radar. Effective change management therefore becomes a bit of a balancing act. We need to know what’s going on, but we don’t want to bog everyone down in the process.

In our data center controlling change is not optional. Reliability demands it, as do the Spanish Inquisition SAS 70 auditors. But we’ve found a way to manage it without terribly burdening our technical staff. Change requests may be formally entered in the system by any authorized individual whether or not they are technical;  they are simply the person requesting the change. The request is then routed to a technician who can assess what needs to be done, adds those details to the request, makes a suggestion as to when it might be done, and then it’s passed on to someone in management who can assess the risk and approve/disapprove it. If a change is of major significance, the request comes before a Change Advisory Board (CAB) for final approval. Technicians, while welcome, are not required to attend CAB meetings.  When requests are properly documented, the CAB is almost always able to make a good decision without further involving the technical staff.  When the CAB does need more information or defers a  request for some reason (e.g. too many changes on one night), the technician in question is notified and it’s handled outside of a meeting.  This saves time, money, and mental fatigue. Since the pain threshold is relatively low, this method also encourages all change activity to actually be run through the proper channels.

Our process is capable of handling very high rates of change, but that doesn’t mean that we do so.  On the contrary, we try to minimize the rate of change, batching things together when it makes sense to  minimize outages, and spreading them out when the risk is high to maximize uptime.

Managing change is not fun, and you may be justifiably weary of it.  Let us take that burden off of your shoulders.

//spk

Sun, The Clouds, And The IBM Blue Sky

by Scott Kantner, April 9th, 2009 in Cloud Computing, Hosting

In a front page article in the April 6th Wall Street Journal, we’re told that an IBM/Sun merger would result in IBM owning 42% of the $53 billion server hardware market, based on 2008 factory revenue numbers provided by IDC.

idcservermarketWith already a third of the market in hand, it hardly seems likely that IBM could be interested in Sun for the hardware.  Such a  move wouldn’t give IBM much of an edge against close rival HP in the corporate space.  Outside of academia and other niches where workloads push performance envelopes to the limit, Sun is just not a big player in corporate computing.  The sales figures make that pretty obvious.

Clearly, it’s not about market share – IBM is after something else.

Press pause on that thought for a moment and think about how many times you’ve read about cloud computing recently. Personally, I’ve reached the saturation point, because the word has been commandeered by marketing departments and spun to mean whatever fits a vendor’s product line.

A short history lesson tells us all we need to know about cloud computing.  In the 1800’s  power generation was the responsibility of  those who needed it. Be it steam, water, or electricity, if I had factory with electrical machinery and lights, I had to generate my own power, and if you needed power, so did you.   And both of us had the hassles of building, operating, and maintaining a power generation infrastructure which, by the way, was not our core business.    Power was necessary to the operation, but it was not the product or service we delivered for profit.

Eventually Edison and Westinghouse figured out how to transmit electricity, and entrepreneurs realized if they could build a Really Big Generator and implement a delivery method, they could sell power to industrial users.    The case from the entrepreneurs to business was clear: “Let us worry about the hassles of generating power so you can focus on your core business, and oh by the way, it’s going to cost a lot less than doing it yourself.”

Fast forward to the present…has the light just come on (pun intended)?   Cloud computing is nothing more than the name-du-jour for the centralization of computing resources so that they can be delivered as a utility service.  Nothing more, nothing less.

So what’s this got to do with IBM?   The answer lies in the rest of the electrical power generation story.  History shows that small generation companies were indeed started and did successfully deliver power to local business for profit.  The model worked, in fact so well that consolidation soon began to take place within the new electric “utility” industry.  Those in the business realized that the biggest fish was really going to win big.   Moreover, the biggest players early in the game were positioned to be the biggest winners after the first big wave of electrical utility consolidations was complete.

It appears that IBM knows its history and wants to be a big player early in the cloud computing game.  Sun is already way ahead of  IBM in the race to deliver computing as a utility.   Amazon and Google were out there first to be sure, but at this early stage in the cycle there is still plenty of room, and it seems like IBM wants to be an early player – a Very Big early player.   IBM may be hoping to paint the clouds in the sky IBM blue in an effort to create a lot of green for its shareholders.

At this point it would not be Al Franken-esque to ask “How does this affect me?”

Like the early days of power generation, most businesses are all still “generating their own power” with their own in-house infrastructures.   When so-called “cloud” computing really goes mainstream, those days will be over.    Cost will inevitably drive the equation in favor of the utility model.

When I first began suggesting this several years ago, I quickly achieved madman status in the eyes of some of my peers and business associates, but it’s getting closer to becoming reality every day.

martyfeldman

Begin to think how your job will change when your server room is gone.    You will still need to keep things running, but the way you do it will be very different. Will your business cards also change?  Perhaps to an address in the clouds?

If you want to get some early comfort working in a cloud before it’s thrust upon you, I know of a good hosting data center where you can get your feet wet.