Burned by Eschewing Best Practices
-
@Carnival-Boy No what @scottalanmiller and @JaredBusch are saying is if you are buying SIP service from a vendor, you should be allowed to access that service from any Internet service provider in the world.
If you can't then you are locked in such a way that if you lost your internet, you'd also lose your phone service.
-
@JaredBusch said in Burned by Eschewing Best Practices:
@Carnival-Boy said in Burned by Eschewing Best Practices:
So you're saying the rule is that your internet pipe/leased line should be a separate contract to your SIP trunk. Company A (let's call them 'BT') sell leased lines and SIP trunks. Company B (let's call them 'TalkTalk') also sell leased lines and SIP trunks.
You should buy one service from BT, and one from TalkTalk. That's the rule, right? So TalkTalk are happy to run their SIP trunks on BT's leased line, and vice versa? The two are independent.
But if you buy both services from the same provider, their automatically tied together, and you can never separate them? That doesn't make sense?
Well in the US, assuming Company A is an ISP, Company A does not sell SIP service unless is on a line from Company A.
You cannot even buy SIP service from them to run over a line from Company B.
On the other hand, Company B does let their SIP service run on any line. So you can get separate services with SIP from Company B and a line from Company A.
Exactly.
Using company names:
Cox Communications sells ISP service and SIP service, but they only sell SIP service over their own ISP lines.
Qwest also sells ISP service.
VOIP.MS only sells SIP trunks, you have to get your own connection to the internet to use VOIP.MS service.
So you can buy ISP (internet) service from Cox and buy SIP from VOIP.MS
But you could not purchase Cox SIP and use it over Qwest ISP service.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
Are they truly separate? That's not available in the US AFAIK.
Why not?
No need to. All the money is in the trap of bundling and Americans fall for this hook, line and sinker MOST of the time. It's the most common deployment case. It's like why all VARs push SAN... the profit is so huge that losing savvy customers doesn't matter. They are happy to lose low margin customers, even the majority of them, to gain a smaller number of huge margin customers.
-
@Dashrender said in Burned by Eschewing Best Practices:
@Carnival-Boy said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
Are they truly separate? That's not available in the US AFAIK.
Why not?
Because people don't know better. Most buying services are just looking to the old timie solution providers like Qwest and AT&T. And those providers often demand a dedicated line to you to provide those services.
Yeah, they never engage IT oversight and just keep buying phones today as if it is 1980 and don't research to know that the world changed in the 1990s. They're unaware of convergence and don't think of phones as part of their business infrastructure.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
But if you buy both services from the same provider, their automatically tied together, and you can never separate them? That doesn't make sense?
That's the only model available in most countries I've dealt with. There are some countries where this is the only model legal in the country! In the US and Canada, it's the only model available from ISPs, but not by law, just because the law doesn't force them not to do it.
-
@scottalanmiller said in Burned by Eschewing Best Practices:
@Carnival-Boy said in Burned by Eschewing Best Practices:
But if you buy both services from the same provider, their automatically tied together, and you can never separate them? That doesn't make sense?
That's the only model available in most countries I've dealt with. There are some countries where this is the only model legal in the country! In the US and Canada, it's the only model available from ISPs, but not by law, just because the law doesn't force them not to do it.
This is why we are suggesting that you MAKE SURE that you have actually truly divorced services, don't just assume you do.
-
OK. I think I follow you all. It may well be the case with BT and other UK ISPs, I really don't know.
-
@Carnival-Boy said in Burned by Eschewing Best Practices:
So you're saying the rule is that your internet pipe/leased line should be a separate contract to your SIP trunk.
Not quite. It might manifest itself that way, but that certainly isn't guaranteed or even likely with that scenario. That exact wording in many (most?) locations would still be fully coupled.
It's that the two should be fully decoupled. Absolutely nothing that happens with one, including legal dispute, billing dispute, physical changes, service changes, account mistakes, etc. should have the ability to influence the other. If one "company" can truly act as two independent companies with the two services being truly decoupled, you can make a strong case that your trunk and your ISP are not from the same vendor, even though they share a parent.
This would be akin to buying a couch from Nebraska Furniture Mart and shipping it on BNSF. Yes, the same company owns both of those companies, but those two companies don't comingle data or accounts.
-
@scottalanmiller said in Burned by Eschewing Best Practices:
This would be akin to buying a couch from Nebraska Furniture Mart and shipping it on BNSF. Yes, the same company owns both of those companies, but those two companies don't comingle data or accounts.
nice
-
I buy my couches from Ikea. And call them settees.
-
I'm putting this here in case of future burn:
https://www.itnews.com.au/news/sa-health-takes-disaster-recovery-gamble-to-save-money-465730South Australia's Health department has decided not to implement a secondary site for disaster recovery with its new state-wide pathology system in an effort to save costs from a project that is running late and over budget.
State wide... Expected cost of $40 million... Dropping plan for DR site...
-
So this is a system that does centralized pathology computing for the entire state?
-
@scottalanmiller said in Burned by Eschewing Best Practices:
So this is a system that does centralized pathology computing for the entire state?
I believe so.
-
@nadnerB said in Burned by Eschewing Best Practices:
@scottalanmiller said in Burned by Eschewing Best Practices:
So this is a system that does centralized pathology computing for the entire state?
I believe so.
Okay, that does seem pretty foolish then. Assuming that just having the computer system online is valuable should the site fail.
-
Potential IPOD in the works for a mere 43TB.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
-
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
-
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
-
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
Sure, but I can fit that much storage into a single server and be within the tolerances set by the OP.
So while he is downsizing to 2 servers, 1 is all that he might actually require. Assuming SA is good enough.
-
@stacksofplates said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
@Dashrender said in Burned by Eschewing Best Practices:
@DustinB3403 said in Burned by Eschewing Best Practices:
Potential IPOD in the works for a mere 43TB.
Mere?
Someone's perspective seems odd.
Really it is a mere 43TB. Not until you're in the 100's of TB range should SAN's even be considered. Which this is where you start to reach the limit of single servers.
The size of data isn't really a limiting factor. It's the number of hosts that need to share the storage.
There is no reasoning as to why the OP thinks he needs a SAN other than it's what he had before and is familiar with. So that reason right there is a "red herring" and immediately means he should welcome outside review before purchasing anything.
Assuming he had 100 TB of storage across 3 servers he could go with scale or starwind's vsan and still be way better off than with the SAN.
