Every wondered how over the last 20 years or so popular culture has begged, borrowed and stolen everything from the past fifty years or so. I think we're currently upto in 1983 in this playback. Goodness knows where we will go after we've revisited grunge because I don't think anything original has been created since then.
Strangely Enterprise IT has it's cycles to:
Centralised IT - Mainframe and green screen dumb terminal
Client Server IT - Midrange UNIX boxes and desktop PC's. Custom built GUI Applications.
Distributed IT - n-Tier applications, middleware, web and application servers and browser delivered applications.
The problem with this model is that every time we've added something we've also taken away.
Green screens were great for data entry but try viewing a BI dashboard on one. GUI Apps were much prettier than browser apps but required all those installation and network overheads. Browsers are great for distribution and access from anywhere but often have a woeful user interface.
I've been waiting for the last 10 years for the next cycle to arrive. One candidate was the advent of Rich Internet Applications like Ajax, Flash or Curl but frankly I'm still waiting for these to arrive in Enterprise IT.
If the iPad get's picked up for the Enterprise them maybe all that will change and well start to see Apps being developed that are user friendly yet easy on the infrastructure. Isn't that a little bit like a return to the Client Server model.
Showing posts with label UNIX. Show all posts
Showing posts with label UNIX. Show all posts
Thursday, February 4, 2010
Tuesday, February 2, 2010
7x24
If you've been around in IT for a while you've probably come across the term 7x24 meaning 100% system uptime.
I was once employed in London by a Investment Bank as a DBA where we were developing a mission critical global options trading system. Luckily the data volumes were small, the servers and environments stable and I'd had plenty of time to work through a reliable hot standby failover solution with an excellent UNIX Sysadm. All was good in my world.
Then during the preparations for go-live the topic of Availability arose. The Project Manager threw into the mix that we had to guarantee 7x24 availability.
My response was that we could aim for 100% uptime excluding planned outages but that we couldn't guarantee it. This resulted in a bit of table-thumping, as was quite often in IT projects in an Investment Bank.
Suffice it to say that when I explained the costs and complexities involved in guaranteeing high that availability from a solutions side and the human side it the PM became a bit more reasonable, especially when I threw in the fact that neither Scott McNealy nor Larry Ellison could guarantee 100% uptime on the configuration of Solaris and Oracle that the solution was constructed.
So the lesson is that before you start discussing High Availability the metric that needs to be understood is the actual cost, either in dollars or reputation, to your business of the mission critical app being unavailable. Until you have that there's really no point in discussing the HA requirements of the system. The funny thing is that when I was consulting I designed lots of Technical Architectures and never once could I get that fact out of the client.
I was once employed in London by a Investment Bank as a DBA where we were developing a mission critical global options trading system. Luckily the data volumes were small, the servers and environments stable and I'd had plenty of time to work through a reliable hot standby failover solution with an excellent UNIX Sysadm. All was good in my world.
Then during the preparations for go-live the topic of Availability arose. The Project Manager threw into the mix that we had to guarantee 7x24 availability.
My response was that we could aim for 100% uptime excluding planned outages but that we couldn't guarantee it. This resulted in a bit of table-thumping, as was quite often in IT projects in an Investment Bank.
Suffice it to say that when I explained the costs and complexities involved in guaranteeing high that availability from a solutions side and the human side it the PM became a bit more reasonable, especially when I threw in the fact that neither Scott McNealy nor Larry Ellison could guarantee 100% uptime on the configuration of Solaris and Oracle that the solution was constructed.
So the lesson is that before you start discussing High Availability the metric that needs to be understood is the actual cost, either in dollars or reputation, to your business of the mission critical app being unavailable. Until you have that there's really no point in discussing the HA requirements of the system. The funny thing is that when I was consulting I designed lots of Technical Architectures and never once could I get that fact out of the client.
Sunday, January 17, 2010
Where did my Open Systems go?
Early in my career I bought into the concept of 'Open Systems' in a big way. I'd been working on proprietary mainframe systems for a couple of years and figured that 'Open' had to be the way to go.
For those unitiated in the world of Open Sytsems it effectively was a euphamism for UNIX and RDBMS technology. The 'Open' basically mean that systems could be developed on one platform (say Sun) and ported to another (i.e HP or IBM) without much effort. Portability was the key to keeping your vendors sweet and it was also ensure that cross skilling your staff was easier. The same was theoretically possible with SQL based databases.
So did this happen? Not really. I used to work in a software porting team for a UNIX/RDBMS based product and because we applied strict standards to keep our code open we managed the transition without too much effort. This was not typical though. Most IT guys out there will tell you that porting from one server or database to another is a major undertaking.
That has resulted in the vast majority of IT shops out there often selecting a particular flavour of UNIX or RDBMS as its system of choice and that kind of defeats the whole argument of Open Systems if you think about it.
For those unitiated in the world of Open Sytsems it effectively was a euphamism for UNIX and RDBMS technology. The 'Open' basically mean that systems could be developed on one platform (say Sun) and ported to another (i.e HP or IBM) without much effort. Portability was the key to keeping your vendors sweet and it was also ensure that cross skilling your staff was easier. The same was theoretically possible with SQL based databases.
So did this happen? Not really. I used to work in a software porting team for a UNIX/RDBMS based product and because we applied strict standards to keep our code open we managed the transition without too much effort. This was not typical though. Most IT guys out there will tell you that porting from one server or database to another is a major undertaking.
That has resulted in the vast majority of IT shops out there often selecting a particular flavour of UNIX or RDBMS as its system of choice and that kind of defeats the whole argument of Open Systems if you think about it.
Thursday, December 10, 2009
Accidental Heroes
UNIX (in its many variants) is the OS at the heart of modern IT. It also is behind three of the four top desktop OS's (MAC OS X, Linux and, when available, Google's Chrome). It is the foundation for iPhone OS and Android. In short it's everywhere.
I like UNIX and have been working with it for nearly 20 years. You may already know that UNIX originated as a small reseach project of at AT&T in the late 60's. But what you probably don't know is that one of its creaters is gobsmacked that it became adopted for use as a commercial OS - for that was never the intent of the project. How do I know this - well I worked with one of the creators relatives and she told me.
Now let's look at Java. I don't have the stats but it is one, if not the, biggest language in use in enterprise IT today. Unlike UNIX however, Java, was written as a commercial product. It was a language developed for appliances - yes appliances. TV's, fridges, washing machines and the like. It was never intended for use in enterprise IT.
So what's the common denominator - well there are two that I can think of. Firstly both were given away free at some stage of their life, but more significantly they grew out of projects of somewhat humble origins and expectations. This is a phenomenon that is not uncommon in Research Science in that some of the greatest discoveries and developments have been accidental, for example Fleming's discovery of penicillin. So my point is that when somebody tries to sell you the future of the IT they're probably wrong. They can't know because the next accident may not yet have even occured.
I like UNIX and have been working with it for nearly 20 years. You may already know that UNIX originated as a small reseach project of at AT&T in the late 60's. But what you probably don't know is that one of its creaters is gobsmacked that it became adopted for use as a commercial OS - for that was never the intent of the project. How do I know this - well I worked with one of the creators relatives and she told me.
Now let's look at Java. I don't have the stats but it is one, if not the, biggest language in use in enterprise IT today. Unlike UNIX however, Java, was written as a commercial product. It was a language developed for appliances - yes appliances. TV's, fridges, washing machines and the like. It was never intended for use in enterprise IT.
So what's the common denominator - well there are two that I can think of. Firstly both were given away free at some stage of their life, but more significantly they grew out of projects of somewhat humble origins and expectations. This is a phenomenon that is not uncommon in Research Science in that some of the greatest discoveries and developments have been accidental, for example Fleming's discovery of penicillin. So my point is that when somebody tries to sell you the future of the IT they're probably wrong. They can't know because the next accident may not yet have even occured.
Subscribe to:
Posts (Atom)