Archives
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- January 2006
- December 2005
- November 2005
- September 2005
- August 2005
- July 2005
- June 2005
- May 2005
- April 2005
- March 2005
- January 2005
- December 2004
- October 2004
- September 2004
- January 2004
- December 2003
- October 2003
- June 2003
- January 2003
- December 2002
- June 2002
- January 2002
- January 2001
- May 2000
- April 2000
Categories
Meta
Category Archives: Campaigns
The Beginning of the End For AntiVirus
It took a long time to make an impact, but eventually we managed it. Myself and others who have long taken the view that AntiVirus technology is a poor and inadequate defense against malware have finally had an impact on the buyers and users of IT Security software. Finally, AntiVirus is in retreat.
The Gradual Growth of Whitelisting
The truth is that we were never fighting against the advocates of AntiVirus Software – the AntiVirus vendors themselves and their supporters. Such people never even dared to engage in debate. After I first posted Come In AntiVirus Your Time Is Up, no AV company ever engaged me in debate – with the pleasant exception of CA, who did have a dialogue with me, but at the time they were already moving to a whitelisting capability, which is now part of CA’s HIPS offering. Other AV vendors gradually followed their lead – notably Symantec and Kaspersky, which forged an alliance with Bit9.
What we were clearly fighting was the inertia of the IT security buyers who are, for understandable reasons, are very conservative. Even the pioneers amongst them who dared to purchase whitelisting technology usually continued to deploy antivirus for a year until they had gained sufficient confidence in whitelisting to abandon the defunct AV software. This became a drag on the growth of whitelisting technology, as few companies were willing to spend twice for protection.
Eventually, however, the whitelisting success stories began to emerge and in the mean time, AV products continued to fail. There were two particular areas of concern for security conscious organizations:
- Zero day threats
- Root kits
AV technology has a terrible record against zero day threats for the laughingly obvious reason that the bad guys buy the AV software and test their malware against it, before they let it loose on the unprepared. AV technology was always about slamming the stable door after the horse had bolted, and zero day threats proved it time and again. When we began to witness the emergence of root kits, then IT security folk who understood the nature of the threat started to become very nervous.
A root kit, if you didn’t know, is malware that buries itself in an untraceable way into a system. It is very difficult to spot and AV technology is powerless against it. It is not a virus payload, it’s the kind of software a hacker installs if a virus gets in. So the possibility was that hackers were unleashing malware and using the window that created to install root kits. Some whitelisting technology has been proven to prevent root kits – and the fact that it could gave it another market to go after.
The Zoomerang Survey
So recently, a survey conducted by Zoomerang showed a dramatic shift in attitudes to AV technology. It was sponsored (anonymously) by Core Trace (a whitelisting vendor), carried out in August 2009 and completed by 226 IT professionals.
Here are the “headline” results:
- 80% of respondents were of the opinion that the threat from malware is increasing
- 74% expressed a lack of confidence in blacklisting anti-malware products (Hurrah! At last!) while only 4% had complete confidence in such products
- 66% believe that blacklisting products are ineffective on “day-zero” of new attacks
- 50% were concerned about the performance impact of blacklisting scans
- 39% are not aware of options to blacklisting approaches
OK. So there’s work still to be done in educating the IT world about whitelisting and how it stops viruses stone dead and we still need to bang the gong a little to reinforce that as far as blacklisting is concerned:
It’s all pain and no gain.
or to put it another way
It’s hurting, but it ain’t working.
So I’m considering going into business selling T-Shirts that say:
Friends don’t let friends use blacklisting technology
If you want to read the full survey click here.
One final point. The rash of cybercrime, which still continues to grow, owes its existence to viruses. It’s viruses that enable the assembling of thousands of zombie PCs. If we stop that we’ll reduce cyber crime considerably. The key to doing that is to get the world to adopt whitelisting.
The Death of the Data Center. Part 7 – The Software
In my rough model of scaled-up data center costs, I never had a separate category for software costs. These were simply bundled in with the server costs. You can think of this as a natural consequence of the costs of an operating system normally being bundled in with the server when you buy hardware.
Note that I was also modeling a highly scaled operation. If it’s Infrastructure as a Service (IaaS) then all you are going to have is operational software; the applications come from the customer. The same will be true of Platform as a Service (PaaS), it’s just that you will also be providing a software stack and development environment. With Software as a Service (SaaS) you’ll be providing the application and in most circumstances that’s going to be an application your company built.
Open Source Software
In the last decade Open Source software has become part of the fabric of the IT industry. It is available for a wide variety of tasks. Some of it is very high quality and nearly all of it can be used for no license fee, as long as you obey the associated license. Open Source software has already become a business factor in the ISP business with most ISPs providing a easily installed and highly functional software stack for building web sites. It is going to play a similar role in the aaS businesses, but not just because the cost is very low.
A critical factor is going to be that the source is open.
As an operator of a large data center you will not have much of a problem paying for support from any given Open Source team, but you probably wont want support of the normal kind. In all probability you will change the source code to tailor the software you use to precisely fit your environment.
Just think of the OS for the moment. Under normal operation an OS will have many background processes running. All such processes have a function and quite a few of them run by default, whether you have a need for them or not. Some of them are keeping logs, some are handling messages from the network, some are there to fire off scheduled jobs if there are any, some handle printing, some provide directory services and so on. They all sit there happily chewing up cpu cycles whether they are busy or idle. You don’t want any of them there unless they have a specific role to play.
In a normal environment you would never even think of deleting these useful background processes, but in an environment that cares about efficient resource usage you really don’t want superfluous anything. Not only that, you maybe interested in rewriting some of these tasks; because you need them, but in your brave new world you may need them to run slightly differently. That’s why open source is key.
The Context Change
You may not know what a context change is. Think of it like this. You are getting on with some task; writing a program or writing a report or designing something and you get interrupted by a phone call. It’s someone on the line and they need your attention at once. You give them the assistance they need and five minutes later you’re back to what you were doing.
The question is: how long will it take for you to get back to the level of productivity you had before the phone rang?
It varies from person to person, but the general consensus is somewhere between 5 and 10 minutes. Computers are the same. They don’t like context switches either. With a computer the context switch occurs when it has to drop one application to get on with another. Technically, this is simply because the computer has to put a kind of bookmark in the application it is running, save it in a state where it can start up again and then load another application – filling the instruction pipeline to the processor. Context changes are expensive, both for people and computers. They consume cycles.
All those background jobs that do printing or write logs or handle network traffic cause context switches. If you can eliminate some of this activity you win more than you might think. And if you know precisely what your workload is going to be then you can design the whole flow of instructions and data to the cpu to try to minimize context switches.
All I’m really trying to do here is point to the fact that, although we have had general purpose computers for decades, we now have the possibility of building very application specific scaled computers.
The big point here is this:
Executing cpu instructions is what a data center does.
That’s it’s prime job. That’s why it is there. If you improve the efficiency of that activity then you win EVERYWHERE:
- Less electricity
- Less cooling
- Less hardware
- Less networking
In the next posting I’ll cover optimization. We’re not done here yet.
The Death of the Data Center: The Model
The Death of the Data Center: Location, Location, Location
The Death of the Data Center: Power
The Death of the Data Center: Cooling
The Death of the Data Center: Networking
The Death of the Data Center: Server Hardware
The Death of the Data Center: The Software
The Death of the Data Center: Software Optimization
The Death of the Data Center (Part 6 – Server Hardware)
In my rough model of scaled-up data center costs, the highest cost was server hardware, making up 36.9% of the total, including the cost of data storage. You don’t need to think hard before you realize that such costs can vary dramatically. Consider data storage costs. If your data center is feeding video streams to the Internet from a vast video library, like YouTube does, the storage requirement is huge compared to streaming SMS length messages to the world, as Twitter does. Indeed Twitter doesn’t even store its billions of tweets indefinitely, so it can estimate its storage requirements easily on a per user basis, whereas the YouTube library just keeps on growing forever.
The same is true of servers or server boards. You have to have sufficient cpu power and memory for the primary workload. So life is a great deal easier if you have a single workload rather than any kind of mixed load. This in turn means that the economies of scale are going to be better for Software as a Service (SaaS), than for Platform as a Service (PaaS), which in turn will be better than Infrastructure as a Service (IaaS). It’s really all about workloads.
Server Economies of Scale
Let us not forget that we are talking about massive scale here. When you are an old-style data center buying new hardware, you may be able to go to HP and IBM and demand a significant discount on the hardware you intend to buy over the next few years. If you are building a scaled out data center that is designed precisely for a specific workload, you are more likely to go to HP or IBM to discuss the design of the hardware you are going to buy. In fact you might not go to any of the traditional hardware vendors. Instead, you might go to an engineering design company that will design the boards and the networking switches for you and then take the contract to a manufacturer in Taiwan to build the precise hardware that you want.
The point is that if you are going to buy thousands or tens of thousands of servers, you’ve moved to a level of demand where you have choices that the typical data center does not have. You are like a manufacturer designing a new plant who needs to make precise decisions about the tooling of the plant, right down to the design of the robot welders.
I’m not being critical of the server products that are built and delivered by the big computer manufacturers. Such engineering is difficult to be critical of, but all such servers, whether mainframes or cheap commodity server boards are designed for “the average circumstance.” It’s really unlikely that your requirements are anywhere close to the average.
Think first about cooling. Servers and blade cabinets are generally built to go in glass room data centers with raised floors and atmospheric cooling. Cooling is one of your major costs, so you will want the server boards and the data storage to be designed to be exactly complementary to the cooling system and you’ll probably want much more focused cooling.
Now think about cpu, memory and disk. You will want a specific ratio between these that fits the workload. There is no point in having surplus anything, because surplus memory or cpu or disk needs cooling if it’s turned on, and if it isn’t turned on, why have you got it? Now think about whether you want local disk or a huge SAN, or a combination of the two. Think also about failover and redundancy and how the server hardware blends with the networking hardware.
Here’s the point:
If you don’t get the hardware right, then you made a mistake with the biggest cost element in your whole operation.
Only a rank amateur would make a mistake like that.
See also:
The Death of the Data Center: The Model
The Death of the Data Center: Location, Location, Location
The Death of the Data Center: Power
The Death of the Data Center: Cooling
The Death of the Data Center: Networking
The Death of the Data Center: Server Hardware
The Death of the Data Center: The Software
The Death of the Data Center: Software Optimization
The Death of the Data Center (Part 5 – Networking Costs)
When you build a small corporate data center you are unlikely to be too concerned about the state of the Internet in you area. This is especially the case if you are building the data center in some population center (New York, Frisco, London, Paris, Singapore, Hong Kong, etc.)
There will be enough bandwidth and, if bandwidth actually is running out locally, some provider will doubtless step in and boost it. It’s not the same if you’re building a very large data center that’s somewhere off the beaten track. There may not be adequate local bandwidth that meets your needs. You may have to do a deal with a provider. You will also need to make sure that there is enough built in redundancy in the service (in case a line gets severed) and that there are no potential bottlenecks between the main arteries of the Internet and your data center. You’ll need to care about the local Internet.
Networking costs are (according to the rough model I drew up) about 12.3% of total costs. Of course that includes all the networking equipment in the data center and as the model we’re using is based on a scale of about 50,000 servers there would be a vast array of networking kit, including monitoring software and devices. You will doubtless also include a high level of redundancy internally (or deploy big data center switches that have it built in.)
Economies of Scale
Let’s consider the economies of scale that you may be able to get here. First of all, with a very large data center you are going to be in a situation to negotiate with your communications provider. So you may buy a great deal of bandwidth, but you won’t be paying a high rate per gigabyte and you will be buying a guaranteed service.
Within the data center, you may be able to predict the network traffic with great accuracy. This depends on the kind of service the data center is providing. If the scaled data center is Infrastructure as a Service (IaaS) or Platform as a Service (PaaS), then it’s going to be less easy to do this.
Network traffic depends on what the applications do and if you don’t know ahead of time then it’s equally possible that you might have workloads that do nothing more than send short messages over the network (say 100 bytes) or you may have whole videos moving around (say 2 gigabytes). There’s a big difference there in bandwidth requirements. You will want to virtualize the network for sure (using Cisco’s NEXUS 7000 or Brocade’s DCX or similar high power switches.) That gives you the capability of reconfiguring the network on the fly, assigning the bandwidth available in any part of the network and changing it dynamically where necessary.
However, if you are doing Software as a Service, you will be able to predict very accurately what the traffic will be and the need fro flexibility is much lower. This means that the cost will be much lower. That is the beauty of the SaaS scaled out data center; the single workload. Absolutely everything can be designed for one application. When you have that situation, all the costs come crashing down.
See also:
The Death of the Data Center: The Model
The Death of the Data Center: Location, Location, Location
The Death of the Data Center: Power
The Death of the Data Center: Cooling
The Death of the Data Center: Networking
The Death of the Data Center: Server Hardware
The Death of the Data Center: The Software
The Death of the Data Center: Software Optimization
The Death of the Data Center. Part 8 – Software Optimization
Let’s start with the statement I made in the last posting:
Executing cpu instructions is what a data center does.
This is the point of the whole series of articles I’ve produced here. If you build a car factory it’s in order to produce cars (of a given quality) as economically as possible. If you build a power plant it’s in order to generate power as economically as possible. If you build a scaled out data center, it is in order to execute cpu instructions as economically as possible.
Building such assets is a risky business. If you’re in a competitive market of any kind you can only control the price to a limited degree. After that, profitability depends on sales success and cost control.
So a company will build a massively scaled data center (or several) with the specific goal of keeping throughput costs as low as possible. It doesn’t matter whether it’s Infrastructure as a Service (IaaS), Platform as a Service (PaaS) or Software as a Service (SaaS), the metric that is going to matter is the cost of executing each instruction. Actually there are other metrics that matter, the cost of managing each byte of data stored and the cost of each byte of information transmitted or received by the data center, but they are the same kind of metric.
I’m deliberately framing this in technical terms, because if you are going to optimize the throughput of a data center, you need to look at every possible strategy and it starts with the nuts and bolts. In fact, it’s mostly about nuts and bolts. So I’ve created a nuts and bolts list of ten possible areas where you might have a technical axe to grind:
I have not compiled this list with the idea that all scaled out data centers will, in the future, adopt all these technical tactics. All I’m demonstrating here is that there are many areas of attack, where the designers of a data center can reduce the number of cpu cycles required to carry out recurring tasks. The motivation to do this will be very high. In the last 20 years we’ve watched cpus grow increasingly powerful and seen their power squandered by programmers that no longer cared to write efficient applications.
Well, the motivation for efficiency has now returned.
Also:
The Death of the Data Center: The Model
The Death of the Data Center: Location, Location, Location
The Death of the Data Center: Power
The Death of the Data Center: Cooling
The Death of the Data Center: Networking
The Death of the Data Center: Server Hardware
The Death of the Data Center: The Software
The Death of the Data Center: Software Optimization