> managing your own systems at places like Softlayer
The problem is, at a place like SL, they're not actually your own systems.
> can save you a bundle
It can, and usually does provide at least some savings, but it still comes with both the obvious form of vendor lock-in, and a subtler disadvantage, which is that you're limited by SL's specific hardware and engineering (including network) choices.
The real (performance and/or cost) magic of running ones own servers comes from custom combination of commodity ingredients, not merely lack of virtualization.
> The problem is, at a place like SL, they're not actually your own systems.
You are right, I do prefer colo and EOL hardware for low budget operations. But SL is a step lower than AWS. SL still can give you a punch in the face. But the point I really want is bare metal more than anything.
Also, if you need current gen stuff not owning can be nice because you won't have to repair when they break.
> It can, and usually does provide at least some savings, but it still comes with both the obvious form of vendor lock-in, and a subtler disadvantage, which is that you're limited by SL's specific hardware and engineering (including network) choices.
I advise you never to use vender provided features (that means avoiding AWS features along with depending on SL network topology (which is vlans, nothing special)).
Anybody making a service today should be able to buy a server at any provider, or setup a colo anywhere and join those resources in and get advantage of those resources instantly. All without depending on stacks and software you have no control over.
I hear this as a reason not to own, but I struggle to understand it, given my experience with how reliable modern hardware is (with notable exceptions[1]).
Regardless, you don't have to repair anything broken at all. It may seem preposterous at first, but, for low enough failure rates, on things with low enough replacement cost [2], using warm spares and abandoning in place can be a reasonable strategy. This can work remarkably well for disks in remote locations, especially in non-hot-swap enclosures.
> depending on SL network topology
One doesn't have a choice, though. There's no alternate topology (nor maximum bandwidths) available. Not taking maximum advantage may be premature optimization (optimizing for stability, rather than performance).
> Anybody making a service today should be able to buy a server at any provider, or setup a colo anywhere and join those resources in and get advantage of those resources instantly.
That would be nice, but it's tantamount to asking everyone go "multi-cloud", which removes too much of the "don't have to think/worry about it" purported benefit of cloud/IaaS.
[1] high-density (say, more than 1socket/U) seems to be the worst offenders
[2] by which I mean the current equivalent, including something like half of a server of a quarter of a CPU
The problem is, at a place like SL, they're not actually your own systems.
> can save you a bundle
It can, and usually does provide at least some savings, but it still comes with both the obvious form of vendor lock-in, and a subtler disadvantage, which is that you're limited by SL's specific hardware and engineering (including network) choices.
The real (performance and/or cost) magic of running ones own servers comes from custom combination of commodity ingredients, not merely lack of virtualization.