Compare Azure to Windows On Prem for Normal Business Workloads
-
@JaredBusch said in Compare Azure to Windows On Prem for Normal Business Workloads:
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
It most certainly is legacy thinking. You shouldn't be running any of those listed things in house (except maybe file storage and you even said that's lgeacy thinking in 2015). Whether you run it in your own infra in a hosted environment or just pay a SaaS you shouldn't be using that in house.
Yes, it may be legacy thinking, but that is not the point. The point is that that it is real world. You are conflating things.
No I'm arguing the fact he literally said "it's not legacy thinking". And he's changed sides on the argument when it suits his purpose.
-
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
The problem that we see in most cases is that when you actually look at how much it costs to be able to scale is higher than the cost of providing the capacity all of the time.
are blatantly false.
If I can run a k8s instance with 3 nodes 99% of the time and then use spot instances to spin up when necessary to add to my cluster to increase capacity it's clearly not true that it costs more to run all of the time.Sure, for that insanely specific, isolated workload. How does this apply to any normal business' general workloads? That's where the cost is.
-
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
Sure. But it's not "legacy thinking" that is the problem, it is "real world workloads." Look at file storage, email, instant messaging, ERP, and other workloads that IT manages for a business.
It most certainly is legacy thinking. You shouldn't be running any of those listed things in house (except maybe file storage and you even said that's lgeacy thinking in 2015). Whether you run it in your own infra in a hosted environment or just pay a SaaS you shouldn't be using that in house.
Except those SaaS providers can't do it as cheaply either. File storage especially, but even email.
And, again, you are using the fantasy world where you believe companies have affordable or available, reliable Internet that is fast enough to do this. That is a core assumption in making any of those things even possible in your model. Sure, lots of companies can consider that, but lots (and I mean LOTS) cannot. It's not even an option to discuss.
Email is the one workload where you could argue, and I would too, that hosted is fine even when your network is flaky because what good is email if you can't get messages in and out. Except those orgs that email internally, which could just use IM.
But everything else, companies need to keep running even when the Internet is down or not available. And I've yet to find any hosted storage that is cost competitive with in house at any size or performance needs.
-
@Pete-S said in Compare Azure to Windows On Prem for Normal Business Workloads:
Sometimes in cases where the clients need high speed connection to the server, moving both the clients and the server can be an option. Basically a VDI solution where the user runs the application remotely. RDP usually have much lower bandwidth demand than application's client to server connection.
That is true, that is absolutely an option and it will work and we know people who have tested it. RDP isn't lower bandwidth (AFAIK) in this case, but what is important is that it is drastically better at handling latency as it has very few data round trips whereas apps like Avimark might do 100 round trips to the DB before displaying any data. RDP might do two for the same data (the 100 being local on the back end.)
Problem with doing VDI or RDS (both work here) is that you have more systems to maintain and more things to pay for. So while it's a possibility, it makes it way, way more expensive.
-
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
The problem that we see in most cases is that when you actually look at how much it costs to be able to scale is higher than the cost of providing the capacity all of the time.
are blatantly false.
If I can run a k8s instance with 3 nodes 99% of the time and then use spot instances to spin up when necessary to add to my cluster to increase capacity it's clearly not true that it costs more to run all of the time.Sure, for that insanely specific, isolated workload. How does this apply to any normal business' general workloads? That's where the cost is.
Yeah that's not insanely specific. That's a normal workload people use. Theres nothing specific about K8s or scaling here that excludes 99% of applications.
-
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
Sure. But it's not "legacy thinking" that is the problem, it is "real world workloads." Look at file storage, email, instant messaging, ERP, and other workloads that IT manages for a business.
It most certainly is legacy thinking. You shouldn't be running any of those listed things in house (except maybe file storage and you even said that's lgeacy thinking in 2015). Whether you run it in your own infra in a hosted environment or just pay a SaaS you shouldn't be using that in house.
Except those SaaS providers can't do it as cheaply either. File storage especially, but even email.
And, again, you are using the fantasy world where you believe companies have affordable or available, reliable Internet that is fast enough to do this. That is a core assumption in making any of those things even possible in your model. Sure, lots of companies can consider that, but lots (and I mean LOTS) cannot. It's not even an option to discuss.
Email is the one workload where you could argue, and I would too, that hosted is fine even when your network is flaky because what good is email if you can't get messages in and out. Except those orgs that email internally, which could just use IM.
But everything else, companies need to keep running even when the Internet is down or not available. And I've yet to find any hosted storage that is cost competitive with in house at any size or performance needs.
This is a joke right? You're saying you can provide chat cheaper and more reliably hosted internally than using a hosted service that's either free or a couple dollars a person?
The only one that really had any weight is the file storage. And it depends 100% on the type of files your storing. If it's documents, according to you, you shouldn't be storing them on a filesystem. File storage that isn't documents, pictures, and things you can't redownload again is a slim margin.
-
@Pete-S said in Compare Azure to Windows On Prem for Normal Business Workloads:
Anyway, if you have enough workloads it's pretty clear to my that a hybrid approach is the best - some workloads in the cloud, some things SaaS, some stuff in a datacenter somewhere and some stuff on-prem. You just pick whatever is best for each case.
If you try to force one solution (like cloud) on everything, you just end up with either dissatisfied end users or higher costs.Yes, exactly, and that's what we do. If you have a stable enough infrastructure and/or you have workloads that simply don't matter if they drop from time to time then likely those isolated workloads in cloud will make sense.
For us, it's almost all "connector" workloads. Things that connect to the Internet outbound. Either calls, email, customer messaging, etc. Basically our hosted services. Things we'd normally by from a provider, but we are a provider so we do it ourselves. We generally, but not always, use cloud for those things.
But for internal infrastructure, we can't find any cloud that would make sense. We use hosted services for our email, internal IM, etc. But whether it is cloud or not isn't relevant, it's SaaS. How they build it is up to them, it's not exposed to us.
But we have terminal servers, big storage, secondary email, development environments, databases, and lots of LOB and those are all internal. Hosted on colo. Way cheaper than putting them on cloud. For us, even though our colo availability is higher than any cloud product we've seen, that doesn't matter. We can withstand a little downtime on those without an issue. For us it's cost related even though we are a prime cloud candidate with our distributed "all online" business model.
-
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
This is a joke right? You're saying you can provide chat cheaper and more reliably hosted internally than using a hosted service that's either free or a couple dollars a person?
Yup, that's what I'm saying. How much does it cost you to do that? Our cost is so low that I can't think of what you'd even think of competing with.
Teams is a joke. Slack is fine, but we don't find it's free versions to be as powerful. I don't know of anything free that provides what we need, and nothing we'd pay for comes close in price.
You act like this is impossible. But quite frankly, I'm shocked that it isn't obvious.
-
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
The only one that really had any weight is the file storage. And it depends 100% on the type of files your storing. If it's documents, according to you, you shouldn't be storing them on a filesystem. File storage that isn't documents, pictures, and things you can't redownload again is a slim margin.
Okay that's fair. Our documents are part of our document editing application and are, in deed, on a cloud provider. But that's not storage to us, it's a SaaS that we use much like a wiki. It's not file storage under the hood, it's a database to them. Grey area definitions I realize, but we don't think of that as storage at all because we never see it as such. We don't store any like Word or ODT files, it's all just part of the online application.
And that's one of the apps that we can simply live without if it goes offline for a little bit. Would be annoying, but we'd keep working. And it's been reliable. And we are distributed, so our own access rate isn't an issue. So we can handle that really well.
But for what we call storage, which is where we are dealing with file level data - so it's pics, data transfers, videos, graphics department working files, etc. That's what we call storage internally, it's the only stuff that we see as "files".
-
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
I don't know of anything free that provides what we need,
Without knowing what this means it's hard to know. But off the top of my head there's Slack obviously, Telegram, Zoho's chat, Hangouts chat, Teams, and I'm sure I could find a couple others.
We use Teams, it's not great but it also provides a lot of functionality. I'm curious as to what your "requirements" are that none of these meet.
-
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
Teams is a joke.
I don't understand why this isn't the consensus amongst techs yet.
-
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
Without knowing what this means it's hard to know. But off the top of my head there's Slack obviously, Telegram, Zoho's chat, Hangouts chat, Teams, and I'm sure I could find a couple others.
Right, if that's the list, I'd expect you to be "how could running internal NOT be way better and cheaper." None of those present obvious and common great solutions. All are fine (except Teams), and all have use cases, and all might work for someone.
But really quickly....
Slack: To have storage of your conversations you pay and pay dearly. It's expensive to a point I don't consider it a real product. It's one of those "management saw it in an airport and didn't evaluate anything" products. IT should never really consider it. I've had giant customers move off of it to internal with good success and massive cost savings.
Telegram: Great, I love it. for personal use. It doesn't have any corporate governance capabilities so while I love it as a tool, it's not a tool for the business.
Zoho Cliq: Nice tool. We pay for this for our purely internal needs. It's included with other things that we have. But 100% can't meet our needs with customers and business partners, even those who are also on it. So it's a no go for us right out of the gate. If your needs are pretty simple architecturally and you use Zoho, it's a really good option.
Hangouts: Tried this at a previous business. Absolute total fail. Didn't work at all and Google even tried to kill it. Nothing Google do I consider production ready for a business, that's just not what Google does. I know some people love it, but they pay and arm and a leg and they get screwed all the time.
Teams: I hope you are kidding. We have one customer on it and it's like stepping back to 2003 to a project I would recommend flunking a college student for making. It's amateur at best. Worst tool I've seen in a very, very long time. It's like they never saw IM in the 2000s and just imagined that no one knew how it should work.
WhatsApp: Same as Telegram and I don't trust Facebook. We DO use this for interviews, but we have no governance.
-
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
We use Teams, it's not great but it also provides a lot of functionality. I'm curious as to what your "requirements" are that none of these meet.
Mostly cost and governance. Having a low cost (ours costs us... a couple dollars a year?) IM platform that we can control users, store the data, scale without paying for it, control the users completely, have security, and actually be usable (looking at Teams there.)
We use Slack, Telegram, WhatsApp, Teams, Cliq and Rocket every day for different reasons. Telegram and WhatsApp are personal or pre-employment only. Slack and Teams are "customer systems that we hate". Slack isn't bad, it's really just pricing that makes it ridiculous. If it were free, it would be really nice.
Literally none of them are remotely affordable to do a good job except running our own. Which takes essentially zero effort to maintain, gives us everything we need, and costs effectively nothing. It's not just "slightly better", it's black and white, slam dunk winner with no real competitors (other than like Mattermost that we would also run ourselves.)
-
Just a quick price comparison...
Rocket for us is around $20 a year, give or take? It's soft cost because it runs on excess resources that already exist and uses only trivial admin time that isn't a priority, so resources we already pay for. It has costs, but they are unmeasurably low.
Slack would cost us around $500/mo or $6K a year. That's a lot of money for no noticeable benefits. I mean Slack, overall, might be slightly nicer than Rocket. But not nice enough for me to really clearly know in what ways.
-
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
Teams: I hope you are kidding. We have one customer on it and it's like stepping back to 2003 to a project I would recommend flunking a college student for making. It's amateur at best. Worst tool I've seen in a very, very long time. It's like they never saw IM in the 2000s and just imagined that no one knew how it should work.
I don't love the tool, but how about some real gripes. Factual things it doesn't do that you need.
-
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
Mostly cost and governance. Having a low cost (ours costs us... a couple dollars a year?) IM platform that we can control users, store the data, scale without paying for it, control the users completely, have security, and actually be usable (looking at Teams there.)
So the only real gripe here is store the data because all of the others are available through the other systems. And any hosted solution won't let you store the data so you've got a self fulfilling argument here.
-
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
Teams: I hope you are kidding. We have one customer on it and it's like stepping back to 2003 to a project I would recommend flunking a college student for making. It's amateur at best. Worst tool I've seen in a very, very long time. It's like they never saw IM in the 2000s and just imagined that no one knew how it should work.
I don't love the tool, but how about some real gripes. Factual things it doesn't do that you need.
Real gripes like a slow interface, difficult to find and follow conversations. Eveyrthing needs to be expanded to be read. It constantly says that you have unread messages but doesn't show any. It deploys as malware. Slow and cumbersome, wastes the team's time.
Yes, it integrates with O365 which is nice, if you have O365 which they do with the customer that uses it. They don't like it, though. But they put up with it for the integration and price.
-
@stacksofplates said in Compare Azure to Windows On Prem for Normal Business Workloads:
@scottalanmiller said in Compare Azure to Windows On Prem for Normal Business Workloads:
Mostly cost and governance. Having a low cost (ours costs us... a couple dollars a year?) IM platform that we can control users, store the data, scale without paying for it, control the users completely, have security, and actually be usable (looking at Teams there.)
So the only real gripe here is store the data because all of the others are available through the other systems. And any hosted solution won't let you store the data so you've got a self fulfilling argument here.
Huh? those are really big, very real issues. It's not functional because it doesn't do what is needed. And I don't know many companies that don't need that. It's pretty basic stuff. Poo pooing basic functionality is a pretty bad way to make a point.
Basically the in house system is cheaper and does way more. To get the same functionality from others is either really costly or not available.
Now, to try to make that not sound "real", you act like data storage, cost, or governance don't matter. What exactly would matter then?
-
I prefer Slack myself but I have Teams here and don't see any of those issues you state. Some people like it so that's fine if they do. I think the cost of Slack is worth it. I think it is unrealistic to have a free product that works that well and be free to scale.
-
Only time cloud is cheaper is for intermittent use or if you need less resources than one server can provide.
Even a $5 Vultr VM is expensive in comparison.This of course assuming you want to deal with your own infrastructure and many don't.
Comparing $5 Vultr VM to your own server.
$5 Vultr is 1 vCPU, 1GB RAM, up to 25 GB SSD.
Server specs
Consolidation ratio: 6 vCPU to 1 pCPU.
CPU: 32 cores
Number of Vultr VMs: 32 x 6=192 VMs
RAM: 192 x 1GB = 192 GB
Average Storage Utilization: 20% of 25GB = 5GB
SSD: 192 x 5GB=960 GB
Example of server: 1U Supermicro 32 core AMD Epyc Rome, 192GB RAM, 2x1TB NVMe SSD, 2x10GbE
Cost of server: less than $7K.
Lifespan of hardware: 5 yearsHypervisor management
Monthly cost: $50
Yearly cost: 12 x 50 = $600
5 year cost: 5 x $600 = $3KHosting Costs
1U Colocation America, /24 IP Range
Monthly cost: ~$250/month
Yearly cost: 12 x 250 = $3000
5 year cost: 5 x $3000 = $15KTotal cost server, hosting and management
$7K + $3K + $15K = $25KVultr costs
Number of $5 VMs: 192 VMs
Monthly cost: 192 x $5 = $960/month
Yearly cost: 12 x $960 = $11520/year
5 year cost: 5 x $11520 = ~58KSo $5 VMs @ Vultr is about twice as expensive as your own server in colo - if you have enough workloads to fill one server.
So in this particular case, if you need 100 small VMs or more than it's cheaper to own the server.
With a smaller server the break-even would with fewer VMs.If you are on-prem you don't have the hosting costs but you need to account for power and cooling and other costs instead.
