rumor has it in 2010 Kurtz wanted the name cloudstrike but the
domain name was already taken (2008)
Quoting Nathan Anderson via VoiceOps <voiceops@voiceops.org>:
(lol @ my "croUdstrike". My fat fingers originally Freudian-slipped
out "CloudStrike", and when I tried to correct it, apparently forgot
to also change U > W.
FROM: VoiceOps [mailto:voiceops-boun...@voiceops.org] ON BEHALF
OF Nathan Anderson via VoiceOps
SENT: Tuesday, August 13, 2024 5:10 PM
TO: Voiceops
SUBJECT: Re: [VoiceOps] Acquire MetaSwitch
To your point, I do think the "blame game" / C.Y.A. angle plays
a big part in this, yes. If you're actually responsible for your
own infrastructure working, then you can be held accountable. (What
a horrific thought!) But if you farm it out to somebody else --
especially if that's made acceptable by the fact that /everybody
else is _also_ farming it out/ -- then you can pass the buck
upstream. "It's not *our* fault! *We* did everything we reasonably
could and according to industry best-practices!"
Perhaps not-unlike today's software security scheme. See:
CroudStrike. Or just the AV industry in general. "I bought and
deployed the solution that checked all of the boxes on paper!
There's nothing that we could have been reasonably expected to do
differently!"
It's all just the "you can't get fired for buying IBM" of today.
-- Nathan
FROM: Ethan Clay [mailto:et...@claytel.com]
SENT: Tuesday, August 13, 2024 4:58 PM
TO: Nathan Anderson; Voiceops
SUBJECT: Re: [VoiceOps] Acquire MetaSwitch
Like most things Nathan, Someone will have to die trying to
use an ILEC line that cannot route to the local PSAP trunk out of
the same building because it has to hairpin on the Azure switch
which is in a outage. Or maybe the IP transport provider is having
degradation too? There’s a million things now in path between your
media gateway and the switch.
The pro subscription offloading folks could argue that well
“it could’ve gone down at the local Central office too”. But now the
scope it’s not just a single CO. It makes it easier to play the
blame game tho!
---- On Tue, 13 Aug 2024 19:43:49 -0400
voiceops@voiceops.org<voiceops@voiceops.org[1]> wrote -
Ethan Clay wrote:
Pretty much the same, but everything is over SDWAN get to the
meta. So if the CO loses Internet or experiences Internet packet
loss, all voice services will be impacted.
Very dystopian, but I think that’s the future for rural ILECs
such no thanks
very hell no
much screw that
wow
Jawaid Bazyar wrote:
OK, so one thing I'm hearing here, is concern for "survivability"
where you can at least still maintain local calling even if WAN
goes down. (The internet never goes down does it? ;-)
Of course 911 availability requirements are a key element of this,
but, "the internet is down" is also bad news for any business in
your town.
[...]
I suspect the economics of the industry are against this business
model (proprietary, on-premise switch, large capex) continuing.
Yes, one concern I have would be the "survivability" aspect / fewer
single-points-of-failure. Not a rural ILEC here (in fact, we're an
even smaller fish than that in an even bigger pond than that, heh),
but I maintain a similar philosophy when helping corporate clients
set up new voice services: *local* (IP) PBX that then has
connectivity to the outside world with a SIP trunk or whatever...we
do not do the cloud/hosted PBX thing for customers. If voice
services go out (regardless of whether that's the internet's fault
or not), at least local intercoms and PA systems all still work
etc. And we can still VPN in to help manage and maintain the PBX
from afar, so lack of hosting in a centralized place is not an
impediment to management. And IP PBX takes up so few hardware
resources, and computing cycles are so inexpensive these days, that
you can run the damn thing on a cheap, commodity, (essentially)
disposable SBC, so the whole "who wants to maintain a 'costly'
piece of proprietary local hardware" argument *also* goes out the
window.
To my mind, the whole idea of hosted extensions on a cloud PBX is
akin to proposing that we should be running a separate WAN
connection to each and every PC in an office. If two PCs in the
same building -- even if it's only one office door down from the
other -- want to talk to each other, then that traffic has to leave
the facility and hairpin back? "LAN" and "WAN" resources are
essentially indistinguishable and bump into each other all the
time? If the provider's local POP goes down, there is zero
networking, period? WTF?
(Granted, we might be going a little bit in that direction already
anyway, at least on the residential side, what with people paying
for multiple "unlimited" mobile data subscriptions per household,
and tablets and laptops shipping with WWAN options, and people
somehow not batting an eye and readily paying for those services
rather than just taking the minor inconvenience hit by tethering to
their phone when they are out and about...)
And I'm sure that the big boys would not be sad to see things go
that way, either. Having it be "normal" and "acceptable"
culturally-speaking to charge per-device rather than for either
aggregate bits or bit-rate is likely a dream come true for them.
But I also don't see it as being an automatic "win" for, or in the
best interest of, the customer, even if the average customer fails
to recognize that. It's not a clear win-win type of scenario, not
by a long shot. To that point, hosted PBX never struck me as good
for the end-user, either. It was always sold as "it has all of
these management advantages on the technical side, but also such
low CAPEX!" What it feels like, though, is just a way to shoehorn
all remaining voice services that don't already conform to this
into a per-extension business model...that's a benefit to the
*carrier*, not necessarily to the end-user, and that's why (IMO)
this model is being pushed so hard.
At an even more meta level, this just strikes me as another
incarnation of the "you will own nothing and like it",
life-as-perpetual-rental model of things that it seems like is
getting shoved down our throats everywhere, and which I hate with
every fiber of my being.
Building on that & circling back around to the LEC discussion +
local switching, I guess I don't see why, other than perhaps
industry inertia, the two choices are "proprietary, expensive,
on-premise switch" or "also just-as-proprietary, centralized
multitenant cloud-based switch". That strikes me as a false
dichotomy. If a LEC is going to modernize and IP-ize whatever parts
of their COs and tandem connections they can, rather than shipping
that traffic off to the cloud, I would think it is *just* as
feasible a proposal to keep it in-house and have those same bits be
handled by some commodity software running on some commodity PC
servers of their own. Probably cheaper in the long run, too, even
factoring in functioning HA/backups and ongoing maintenance. Sure,
you might need to make adjustments in staffing, but it's not like
running the big expensive switches didn't require these telcos to
keep people on staff that knew how to troubleshoot and service
*them*. You'd be trading one area of specialization for another.
And we still also haven't touched on the practical implications of
moving all of this stuff to the cloud and making yourself dependent
on someone's SaaS services. Things like, if the application
provider decides to push out an update on such-and-such a day, you
either get on-board with it and do so on *their*
schedule/time-table, or...well, that's your only option, really.
Unless this is a private instance and not a multi-tenant thing, you
don't have the option of saying no, you don't have the option of
scheduling it when it makes the most sense for *you* and *your*
organization, you don't have the option of staging it in a lab
first, you don't have the option of rolling things back if the
update screws you over anyway, etc. You are completely at their
mercy. And at least if a hardware platform vendor goes out of
business tomorrow, my no-longer-supported hardware doesn't
immediately become a doorstop overnight & my customers remain up
and serviced while I can take my time to carefully plan and execute
whatever my next platform migration is going to be, whereas if the
cloud application vendor croaks overnight, I am *totally* screwed...
But, that's enough ranting for today, I suppose. :-P
-- Nathan
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
Links:
------
[1] mailto:voiceops@voiceops.org%3cvoice...@voiceops.org
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
