The High Cost of On Premises Infrastructure
-
Looking at real world examples we can look at many different price and scale points. From the smallest 1U single server environments to two or three 2U server environments to quarter, half, full rack hosting to cage areas or multi-rack environments. Different scale points offer different opportunities and challenges.
The easiest examples to tackle are the one and two servers scales which are also most applicable to the SMB market where it is relatively rare that more servers are needed (and when they are scaling the example is relatively straightforward.)
Moving to colocation does require some changes in thought processes, which is worth noting. SMBs running on premises systems may option for large pedestal or tower devices simply because there are no space concerns and planning for density does not enter the picture. But commonly 1U and 2U rack mount servers easily fit the bill.
Colocation also encourages a move toward hyperconvergence. Simplifying the physical installation and design of an infrastructure making it more self contained can be beneficial to making the move to a colocation facility even easier and make supporting an environment much easier. Being able to swap nodes, rather than to describe and support many different infrastructure components, can be significant. Also, moving physical support from IT to vendor can be beneficial here as well.
-
Placeholder for example
-
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
You normally flippant answer of don't use them is not the acceptable answer to the business principles that make the decisions. Yes, times are changing and WAN speeds and new technologies are moving things, but these two points have to be properly addressed to make any kind of realistic move to colocation for the SMB space.
-
@JaredBusch said in The High Cost of On Premises Infrastructure:
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
You normally flippant answer of don't use them is not the acceptable answer to the business principles that make the decisions. Yes, times are changing and WAN speeds and new technologies are moving things, but these two points have to be properly addressed to make any kind of realistic move to colocation for the SMB space.
The last place I worked had a very small number of employees (~15) but the size of the files they dealt with made it impractical to move data off site. With an 18Mb connection, doing CAD work with files that are multiple hundreds of MB in size isn't feasable. They use DropBox for some things, but the large majority had to be hosted on site.
-
@stacksofplates said in The High Cost of On Premises Infrastructure:
@JaredBusch said in The High Cost of On Premises Infrastructure:
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
You normally flippant answer of don't use them is not the acceptable answer to the business principles that make the decisions. Yes, times are changing and WAN speeds and new technologies are moving things, but these two points have to be properly addressed to make any kind of realistic move to colocation for the SMB space.
The last place I worked had a very small number of employees (~15) but the size of the files they dealt with made it impractical to move data off site. With an 18Mb connection, doing CAD work with files that are multiple hundreds of MB in size isn't feasable. They use DropBox for some things, but the large majority had to be hosted on site.
We have a huge number of CAD files and maps in house as well. Around 10TB and at any moment we may have to browse and find something.
Have looked at Panzura and Nasuni a few times but the cost of a storage gateway is still somewhat high.
-
@JaredBusch said in The High Cost of On Premises Infrastructure:
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
Point one is the really hard one. Files take time to move, there's no "ignore it" answer. There is WAN caching, file caching, compression, "bigger links", WAN tuning, changes in file sharing infrastructure... but all come with cost or change.
LoB apps are generally easier. Modern apps rarely have big bandwidth problems are there are lots of good acceleration methods for older ones. Doesn't fix every single app, but it does address the majority.
-
@JaredBusch said in The High Cost of On Premises Infrastructure:
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
You normally flippant answer of don't use them is not the acceptable answer to the business principles that make the decisions. Yes, times are changing and WAN speeds and new technologies are moving things, but these two points have to be properly addressed to make any kind of realistic move to colocation for the SMB space.
Couldn't we throw regulatory compliance in there too as a consideration?
https://www.truevault.com/blog/hipaa-physical-safeguards-explained-part-1.html -
@NetworkNerd said in The High Cost of On Premises Infrastructure:
@JaredBusch said in The High Cost of On Premises Infrastructure:
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
You normally flippant answer of don't use them is not the acceptable answer to the business principles that make the decisions. Yes, times are changing and WAN speeds and new technologies are moving things, but these two points have to be properly addressed to make any kind of realistic move to colocation for the SMB space.
Couldn't we throw regulatory compliance in there too as a consideration?
https://www.truevault.com/blog/hipaa-physical-safeguards-explained-part-1.htmlNot IMO. Because colo means the data is never in anyone else's hands.
-
@NetworkNerd said in The High Cost of On Premises Infrastructure:
Couldn't we throw regulatory compliance in there too as a consideration?
https://www.truevault.com/blog/hipaa-physical-safeguards-explained-part-1.htmlYes, compliance is one of the biggest factors keeping on premises from being a good option. Very few non-enterprises can maintain a secure local environment. So going to colocation is very important for those companies to maintain adequate physical security, that's a good point.
-
@JaredBusch said in The High Cost of On Premises Infrastructure:
@NetworkNerd said in The High Cost of On Premises Infrastructure:
@JaredBusch said in The High Cost of On Premises Infrastructure:
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
You normally flippant answer of don't use them is not the acceptable answer to the business principles that make the decisions. Yes, times are changing and WAN speeds and new technologies are moving things, but these two points have to be properly addressed to make any kind of realistic move to colocation for the SMB space.
Couldn't we throw regulatory compliance in there too as a consideration?
https://www.truevault.com/blog/hipaa-physical-safeguards-explained-part-1.htmlNot IMO. Because colo means the data is never in anyone else's hands.
And you can encrypt the entire colocation platform, so that physical extraction is not a direct concern as well. Someone stealing hard drives or even full arrays would be useless to them.
-
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@JaredBusch said in The High Cost of On Premises Infrastructure:
@NetworkNerd said in The High Cost of On Premises Infrastructure:
@JaredBusch said in The High Cost of On Premises Infrastructure:
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
You normally flippant answer of don't use them is not the acceptable answer to the business principles that make the decisions. Yes, times are changing and WAN speeds and new technologies are moving things, but these two points have to be properly addressed to make any kind of realistic move to colocation for the SMB space.
Couldn't we throw regulatory compliance in there too as a consideration?
https://www.truevault.com/blog/hipaa-physical-safeguards-explained-part-1.htmlNot IMO. Because colo means the data is never in anyone else's hands.
And you can encrypt the entire colocation platform, so that physical extraction is not a direct concern as well. Someone stealing hard drives or even full arrays would be useless to them.
I'm less worried about physical theft than I am about someone plugging a USB stick in and infecting the host, etc.
-
@Dashrender said in The High Cost of On Premises Infrastructure:
I'm less worried about physical theft than I am about someone plugging a USB stick in and infecting the host, etc.
Infect it how? Can you describe this attack vector? When you plug a USB stick into a server, assuming that you have been breached in a datacenter to this level which is essentially unthinkable, and assuming that you've not disabled the USB ports, what would cause the files on the USB stick to be executed, or even mounted?
-
@Dashrender I've never tried this, but just thinking about it, no matter what is on a USB stick, I don't know that any ESXi, Xen, KVM or Hyper-V environment would react to the USB stick at all, or maybe just acknowledge that it exists. I'm not aware of any situation where they would "see" the files on the device. Obviously you can protect against this by blocking USB access on the hardware, you can stop the disk drives from being used, too.
But assuming that those things have been missed, I'm interested in where you've seen this threat and what has caused you to be concerned about it.
-
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@Dashrender said in The High Cost of On Premises Infrastructure:
I'm less worried about physical theft than I am about someone plugging a USB stick in and infecting the host, etc.
Infect it how? Can you describe this attack vector? When you plug a USB stick into a server, assuming that you have been breached in a datacenter to this level which is essentially unthinkable, and assuming that you've not disabled the USB ports, what would cause the files on the USB stick to be executed, or even mounted?
Yeah I forgot about disabling the USB ports - so this should be a non issue. Never mind nothing to see here.
-
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@Dashrender I've never tried this, but just thinking about it, no matter what is on a USB stick, I don't know that any ESXi, Xen, KVM or Hyper-V environment would react to the USB stick at all, or maybe just acknowledge that it exists. I'm not aware of any situation where they would "see" the files on the device. Obviously you can protect against this by blocking USB access on the hardware, you can stop the disk drives from being used, too.
But assuming that those things have been missed, I'm interested in where you've seen this threat and what has caused you to be concerned about it.
As you said, it's not real concern, you're much more likely to be breached like this in a SMB shop. As I said "move along, Move along"
-
@Dashrender said in The High Cost of On Premises Infrastructure:
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@JaredBusch said in The High Cost of On Premises Infrastructure:
@NetworkNerd said in The High Cost of On Premises Infrastructure:
@JaredBusch said in The High Cost of On Premises Infrastructure:
The two biggest arguments that always have to be addressed are
- speed of access to file shares
- access to the client/server LoB app used now.
You normally flippant answer of don't use them is not the acceptable answer to the business principles that make the decisions. Yes, times are changing and WAN speeds and new technologies are moving things, but these two points have to be properly addressed to make any kind of realistic move to colocation for the SMB space.
Couldn't we throw regulatory compliance in there too as a consideration?
https://www.truevault.com/blog/hipaa-physical-safeguards-explained-part-1.htmlNot IMO. Because colo means the data is never in anyone else's hands.
And you can encrypt the entire colocation platform, so that physical extraction is not a direct concern as well. Someone stealing hard drives or even full arrays would be useless to them.
I'm less worried about physical theft than I am about someone plugging a USB stick in and infecting the host, etc.
How is that any less safe then your office building? You have patients coming in and out all day, contractors, maintenance, etc etc etc. You don't know who is in your building and who could, just as easily, plug a USB stick in to a host.
A colo knows exactly who is in their building, many have biometric security and pressure sensitive pads to prevent piggy backing.
-
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@Dashrender said in The High Cost of On Premises Infrastructure:
I'm less worried about physical theft than I am about someone plugging a USB stick in and infecting the host, etc.
Infect it how? Can you describe this attack vector? When you plug a USB stick into a server, assuming that you have been breached in a datacenter to this level which is essentially unthinkable, and assuming that you've not disabled the USB ports, what would cause the files on the USB stick to be executed, or even mounted?
Dont you watch House of Cards?
-
@Dashrender said in The High Cost of On Premises Infrastructure:
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@Dashrender said in The High Cost of On Premises Infrastructure:
I'm less worried about physical theft than I am about someone plugging a USB stick in and infecting the host, etc.
Infect it how? Can you describe this attack vector? When you plug a USB stick into a server, assuming that you have been breached in a datacenter to this level which is essentially unthinkable, and assuming that you've not disabled the USB ports, what would cause the files on the USB stick to be executed, or even mounted?
Yeah I forgot about disabling the USB ports - so this should be a non issue. Never mind nothing to see here.
But even if you didn't, is there an attack vector? How could you get something to execute if the USB was accidentally exposed?
-
@bigbear said in The High Cost of On Premises Infrastructure:
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@Dashrender said in The High Cost of On Premises Infrastructure:
I'm less worried about physical theft than I am about someone plugging a USB stick in and infecting the host, etc.
Infect it how? Can you describe this attack vector? When you plug a USB stick into a server, assuming that you have been breached in a datacenter to this level which is essentially unthinkable, and assuming that you've not disabled the USB ports, what would cause the files on the USB stick to be executed, or even mounted?
Dont you watch House of Cards?
No and I'm guessing that this would make me want to avoid it?
-
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@bigbear said in The High Cost of On Premises Infrastructure:
@scottalanmiller said in The High Cost of On Premises Infrastructure:
@Dashrender said in The High Cost of On Premises Infrastructure:
I'm less worried about physical theft than I am about someone plugging a USB stick in and infecting the host, etc.
Infect it how? Can you describe this attack vector? When you plug a USB stick into a server, assuming that you have been breached in a datacenter to this level which is essentially unthinkable, and assuming that you've not disabled the USB ports, what would cause the files on the USB stick to be executed, or even mounted?
Dont you watch House of Cards?
No and I'm guessing that this would make me want to avoid it?
They do get a lot of silly technical things wrong, but the story is generally pretty good.
