Looking to Buy a SAN
-
@stacksofplates said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@bnrstnr said in Looking to Buy a SAN:
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@coliver said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
@ScottyBoy said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
I've recognized an IPOD and witnessed it play out.
In the end the business decided it made more financial sense to put 200 VMs in Azure.
This is for a TV station cloud simply isn't an option to run this stuff unfortunately.
My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.
The other solution is to not design an IPOD.
Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.
Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.
Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.
Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.
This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?
There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.
Invoicing and Accounts Payable is a big use of it
I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.
Yes there is a server on the backend but it's abstracted away so you don't see it. The only thing you see is either the JSON payload, the actual HTTP request, or some message queue object. Then you interact with that. It's all run in containers and only spins up when there is a request. So it's not good for very time sensitive requests because you have the latency of spinning up cold containers if there haven't been requests for whatever the timeout period is.
So it's webcode/api waiting for a request? so it's basically a webserver? So how is the webserver setup serverless? what keeps your webcode waiting for an incoming request from getting mix with someone else's? the IP and port? OK - and us admins setting that stuff up - we just have a logon to some ethereal portal where we dump code? I'm guessing, as I type more, that the admin's portal to the 'cloud/serverless' setup is more like it's own server interface, where we configure services, etc, but that's really just an abstration from whatever's actually happening on the backend, because on the backend it's not really separate instances like we have in a typical server environment -
oh man - I'm going going to be made fun of for that bunch of shit I just posted
-
@Dashrender said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@bnrstnr said in Looking to Buy a SAN:
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@coliver said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
@ScottyBoy said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
I've recognized an IPOD and witnessed it play out.
In the end the business decided it made more financial sense to put 200 VMs in Azure.
This is for a TV station cloud simply isn't an option to run this stuff unfortunately.
My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.
The other solution is to not design an IPOD.
Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.
Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.
Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.
Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.
This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?
There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.
Invoicing and Accounts Payable is a big use of it
I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.
Yes there is a server on the backend but it's abstracted away so you don't see it. The only thing you see is either the JSON payload, the actual HTTP request, or some message queue object. Then you interact with that. It's all run in containers and only spins up when there is a request. So it's not good for very time sensitive requests because you have the latency of spinning up cold containers if there haven't been requests for whatever the timeout period is.
So it's webcode/api waiting for a request? so it's basically a webserver? So how is the webserver setup serverless? what keeps your webcode waiting for an incoming request from getting mix with someone else's? the IP and port? OK - and us admins setting that stuff up - we just have a logon to some ethereal portal where we dump code? I'm guessing, as I type more, that the admin's portal to the 'cloud/serverless' setup is more like it's own server interface, where we configure services, etc, but that's really just an abstration from whatever's actually happening on the backend, because on the backend it's not really separate instances like we have in a typical server environment -
oh man - I'm going going to be made fun of for that bunch of shit I just posted
You know the ML telegram bot I have there? That is built solely on Azure Function App.
The web form I have on my static HTML sites are processed by an Azure Function App.
The equivalent on AWS is Lambda. There are many other serverless providers as well, and it's not just Azure Functions or Lambda, those are 2 easy examples to use.
-
@Dashrender said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@bnrstnr said in Looking to Buy a SAN:
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@coliver said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
@ScottyBoy said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
I've recognized an IPOD and witnessed it play out.
In the end the business decided it made more financial sense to put 200 VMs in Azure.
This is for a TV station cloud simply isn't an option to run this stuff unfortunately.
My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.
The other solution is to not design an IPOD.
Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.
Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.
Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.
Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.
This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?
There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.
Invoicing and Accounts Payable is a big use of it
I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.
Yes there is a server on the backend but it's abstracted away so you don't see it. The only thing you see is either the JSON payload, the actual HTTP request, or some message queue object. Then you interact with that. It's all run in containers and only spins up when there is a request. So it's not good for very time sensitive requests because you have the latency of spinning up cold containers if there haven't been requests for whatever the timeout period is.
So it's webcode/api waiting for a request? so it's basically a webserver? So how is the webserver setup serverless? what keeps your webcode waiting for an incoming request from getting mix with someone else's? the IP and port? OK - and us admins setting that stuff up - we just have a logon to some ethereal portal where we dump code? I'm guessing, as I type more, that the admin's portal to the 'cloud/serverless' setup is more like it's own server interface, where we configure services, etc, but that's really just an abstration from whatever's actually happening on the backend, because on the backend it's not really separate instances like we have in a typical server environment -
oh man - I'm going going to be made fun of for that bunch of shit I just posted
It kind of is a big webserver but your code isn't waiting to be run. It's not running at all until the request gets passed to your function and then your function is spun up and starts to work with the request. Your stuff only runs when a request comes in. That's why it's billed per request and per second. You might only get one request but your function may run for 5 seconds. So they cover both ends.
Here's a real life example: https://gitlab.com/hooksie1/hookiescookies-api
If you go to
https://cookies.hookiescookies.com/api/ingredients/cocoa
it will return all cookies with the ingredients cocoa. That is running in a serverless architecture. All I wrote was the functions to get data and return it. I don't manage any of the infrastructure or containers. It's all built automatically through a pipeline. And the data lives in hosted FaunaDB which means I don't manage any of my database infrastructure either.It's more abstracted than a PaaS because with a PaaS you have to manage the container infrastructure. With serverless all I do is write code and deploy it.
-
@stacksofplates said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@bnrstnr said in Looking to Buy a SAN:
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@coliver said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
@ScottyBoy said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
I've recognized an IPOD and witnessed it play out.
In the end the business decided it made more financial sense to put 200 VMs in Azure.
This is for a TV station cloud simply isn't an option to run this stuff unfortunately.
My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.
The other solution is to not design an IPOD.
Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.
Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.
Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.
Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.
This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?
There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.
Invoicing and Accounts Payable is a big use of it
I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.
Yes there is a server on the backend but it's abstracted away so you don't see it. The only thing you see is either the JSON payload, the actual HTTP request, or some message queue object. Then you interact with that. It's all run in containers and only spins up when there is a request. So it's not good for very time sensitive requests because you have the latency of spinning up cold containers if there haven't been requests for whatever the timeout period is.
So it's webcode/api waiting for a request? so it's basically a webserver? So how is the webserver setup serverless? what keeps your webcode waiting for an incoming request from getting mix with someone else's? the IP and port? OK - and us admins setting that stuff up - we just have a logon to some ethereal portal where we dump code? I'm guessing, as I type more, that the admin's portal to the 'cloud/serverless' setup is more like it's own server interface, where we configure services, etc, but that's really just an abstration from whatever's actually happening on the backend, because on the backend it's not really separate instances like we have in a typical server environment -
oh man - I'm going going to be made fun of for that bunch of shit I just posted
It kind of is a big webserver but your code isn't waiting to be run. It's not running at all until the request gets passed to your function and then your function is spun up and starts to work with the request. Your stuff only runs when a request comes in. That's why it's billed per request and per second. You might only get one request but your function may run for 5 seconds. So they cover both ends.
Here's a real life example: https://gitlab.com/hooksie1/hookiescookies-api
If you go to
https://cookies.hookiescookies.com/api/ingredients/cocoa
it will return all cookies with the ingredients cocoa. That is running in a serverless architecture. All I wrote was the functions to get data and return it. I don't manage any of the infrastructure or containers. It's all built automatically through a pipeline. And the data lives in hosted FaunaDB which means I don't manage any of my database infrastructure either.It's more abstracted than a PaaS because with a PaaS you have to manage the container infrastructure. With serverless all I do is write code and deploy it.
Also, the trigger doesn't have to be an HTTP trigger, it could be a number of other things, and doesn't have to be a web related function either.
-
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@bnrstnr said in Looking to Buy a SAN:
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@coliver said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
@ScottyBoy said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
I've recognized an IPOD and witnessed it play out.
In the end the business decided it made more financial sense to put 200 VMs in Azure.
This is for a TV station cloud simply isn't an option to run this stuff unfortunately.
My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.
The other solution is to not design an IPOD.
Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.
Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.
Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.
Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.
This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?
There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.
Invoicing and Accounts Payable is a big use of it
I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.
Yes there is a server on the backend but it's abstracted away so you don't see it. The only thing you see is either the JSON payload, the actual HTTP request, or some message queue object. Then you interact with that. It's all run in containers and only spins up when there is a request. So it's not good for very time sensitive requests because you have the latency of spinning up cold containers if there haven't been requests for whatever the timeout period is.
So it's webcode/api waiting for a request? so it's basically a webserver? So how is the webserver setup serverless? what keeps your webcode waiting for an incoming request from getting mix with someone else's? the IP and port? OK - and us admins setting that stuff up - we just have a logon to some ethereal portal where we dump code? I'm guessing, as I type more, that the admin's portal to the 'cloud/serverless' setup is more like it's own server interface, where we configure services, etc, but that's really just an abstration from whatever's actually happening on the backend, because on the backend it's not really separate instances like we have in a typical server environment -
oh man - I'm going going to be made fun of for that bunch of shit I just posted
It kind of is a big webserver but your code isn't waiting to be run. It's not running at all until the request gets passed to your function and then your function is spun up and starts to work with the request. Your stuff only runs when a request comes in. That's why it's billed per request and per second. You might only get one request but your function may run for 5 seconds. So they cover both ends.
Here's a real life example: https://gitlab.com/hooksie1/hookiescookies-api
If you go to
https://cookies.hookiescookies.com/api/ingredients/cocoa
it will return all cookies with the ingredients cocoa. That is running in a serverless architecture. All I wrote was the functions to get data and return it. I don't manage any of the infrastructure or containers. It's all built automatically through a pipeline. And the data lives in hosted FaunaDB which means I don't manage any of my database infrastructure either.It's more abstracted than a PaaS because with a PaaS you have to manage the container infrastructure. With serverless all I do is write code and deploy it.
Also, the trigger doesn't have to be an HTTP trigger, it could be a number of other things, and doesn't have to be a web related function either.
Right. I mentioned before you could use things like a message queue, but I was going for a simple explanation.
-
Here's a list of the GCP triggers: https://cloud.google.com/functions/docs/calling
Not sure what Azure has
-
@Dashrender said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@bnrstnr said in Looking to Buy a SAN:
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@coliver said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
@ScottyBoy said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
I've recognized an IPOD and witnessed it play out.
In the end the business decided it made more financial sense to put 200 VMs in Azure.
This is for a TV station cloud simply isn't an option to run this stuff unfortunately.
My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.
The other solution is to not design an IPOD.
Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.
Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.
Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.
Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.
This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?
There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.
Invoicing and Accounts Payable is a big use of it
I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.
Yes there is a server on the backend but it's abstracted away so you don't see it. The only thing you see is either the JSON payload, the actual HTTP request, or some message queue object. Then you interact with that. It's all run in containers and only spins up when there is a request. So it's not good for very time sensitive requests because you have the latency of spinning up cold containers if there haven't been requests for whatever the timeout period is.
oh man - I'm going going to be made fun of for that bunch of shit I just posted
Actually you asked some fair questions.
There are two concepts to understand with serverless.
1.) It expands dynamically (like a container). Big dogs like AWS and Azure have the ability to basically expand and contract endlessly (elasticity)
2.) The actual function of a service like lambda itself. For example how queuing and messaging work -
The last time that I solved this problem, I built 2 Starwind SANs on site with a third off site. Medical data is important!
It was all torn down for a single EMC system that failed inside of a year and much data was lost. I laughed since I was long gone from the company that made the poor decisions.
-
@Dashrender said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@bnrstnr said in Looking to Buy a SAN:
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@coliver said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
@ScottyBoy said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
I've recognized an IPOD and witnessed it play out.
In the end the business decided it made more financial sense to put 200 VMs in Azure.
This is for a TV station cloud simply isn't an option to run this stuff unfortunately.
My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.
The other solution is to not design an IPOD.
Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.
Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.
Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.
Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.
This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?
There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.
Invoicing and Accounts Payable is a big use of it
I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.
It's not the best terminology. But it's the standard now. It's like "API only" processing, getting as light as you reasonably can.
-
Keep in mind that serverless itself doesn't imply cloud or hosted or third party. You can run serverless on your own server. It requires containers to run in, just like any other workload. If you feel that serverless is a critical part of your design, but don't want a dependency on third parties, you can always run your own.
I presume that this allows you to control latency issues common with serverless by enforcing what stays hot, although I've not tested that theory.
-
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@bnrstnr said in Looking to Buy a SAN:
@Obsolesce said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
@Dashrender said in Looking to Buy a SAN:
@coliver said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
@ScottyBoy said in Looking to Buy a SAN:
@flaxking said in Looking to Buy a SAN:
I've recognized an IPOD and witnessed it play out.
In the end the business decided it made more financial sense to put 200 VMs in Azure.
This is for a TV station cloud simply isn't an option to run this stuff unfortunately.
My point is that putting a bunch of VMs in Azure is a pretty expensive solution, but dealing with an IPOD ends up costing the business enough that the cost is acceptable.
The other solution is to not design an IPOD.
Exactly. Buy a correctly sized Scale box - no IPOD... sure, huge upfront cost, but who knows over the long term compared to Azure. etc etc etc.. We don't have any of the other needed information to know if going to Azure was the right move or not... but it's done, so we move on.
Literally everything is cheap compared to Azure. LOL. Even with all their specialty serverless whatever, never seen it cost close to what running your own would do. The cost is just so absurd per workload.
Their serverless offering is on par with the rest. It's a million requests per month and 400,000 seconds of compute for free. After that it's only $0.20 per million executions and $0.000016 per second. That's not really expensive at all.
Exactly. I'm using in a lot of places in production with ~10k users and twice as many devices that is using the serveless functions in many areas... basically for free. And, that's just the start (one example) of it... Having a VM with enough power to process that as frequently as it's getting done now along with all the other benefits around it, there's truly no comparison. Scaling it down to how a typical SMB would use it, well that's a no-brainer, as it'd be totally free and 100% beneficial. I don't think one's ignorance of a technology justifies it's disqualification of use in the real world.
This should probably be it's own topic, but here we are... I'm totally ignorant to Azure and serverless concepts in general. What types of real world services/processes are SMBs using (or could/should be using) serverless Azure for?
There's a few different scenarios. Anything reactionary essentially. Send a message/email based on an event, do some kind of work based on messages in a message queue, transform or modify data, etc. You can even use it to build and define APIs. I have an API running in Vercel (not Azure but another serverless offering) and I don't have to run the service in a VM full time.
Invoicing and Accounts Payable is a big use of it
I don't understand how those are serverless? There is software running - right? where is that software running? This is something I completely don't understand - and I'm guessing @bnrstnr likely doesn't either - but he'll correct me if I'm wrong and he does.
It's not the best terminology. But it's the standard now. It's like "API only" processing, getting as light as you reasonably can.
API processing is just one of many.
If you want to bother to learn more about serverless tech and use cases, give this PDF a read:
https://docs.microsoft.com/en-us/dotnet/architecture/serverlessI think if you read it without bias, you'll better understand and grasp it.
-
@scottalanmiller said in Looking to Buy a SAN:
Keep in mind that serverless itself doesn't imply cloud or hosted or third party. You can run serverless on your own server. It requires containers to run in, just like any other workload. If you feel that serverless is a critical part of your design, but don't want a dependency on third parties, you can always run your own.
I presume that this allows you to control latency issues common with serverless by enforcing what stays hot, although I've not tested that theory.
I assume you're talking about OpenFaaS. You can control cold starts but the complexity of setting that up along with maintaining it is light years above deploying to a provider.
As with anything, people not leveraging public cloud offerings (specifically serverless in this case and not just the big 3) is because of FUD. There are very few real cases where it can't be leveraged. As you said in another thread, don't avoid the best because it fails to be perfect.
-
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
Keep in mind that serverless itself doesn't imply cloud or hosted or third party. You can run serverless on your own server. It requires containers to run in, just like any other workload. If you feel that serverless is a critical part of your design, but don't want a dependency on third parties, you can always run your own.
I presume that this allows you to control latency issues common with serverless by enforcing what stays hot, although I've not tested that theory.
I assume you're talking about OpenFaaS. You can control cold starts but the complexity of setting that up along with maintaining it is light years above deploying to a provider.
As with anything, people not leveraging public cloud offerings (specifically serverless in this case and not just the big 3) is because of FUD. There are very few real cases where it can't be leveraged. As you said in another thread, don't avoid the best because it fails to be perfect.
Doesn't have the same cost benefits running on your own hardware either.
-
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
Keep in mind that serverless itself doesn't imply cloud or hosted or third party. You can run serverless on your own server. It requires containers to run in, just like any other workload. If you feel that serverless is a critical part of your design, but don't want a dependency on third parties, you can always run your own.
I presume that this allows you to control latency issues common with serverless by enforcing what stays hot, although I've not tested that theory.
I assume you're talking about OpenFaaS. You can control cold starts but the complexity of setting that up along with maintaining it is light years above deploying to a provider.
As with anything, people not leveraging public cloud offerings (specifically serverless in this case and not just the big 3) is because of FUD. There are very few real cases where it can't be leveraged. As you said in another thread, don't avoid the best because it fails to be perfect.
Doesn't have the same cost benefits running on your own hardware either.
Def not, especially if you are within the free tier every month. The cost in electricity alone is higher let alone maintenance, patching (server and k8s and OpenFaaS), troubleshooting, etc.
-
The reason cloud is so expensive for most is because they simply try to move existing workloads to it without redevelopment of the workloads to a server less design.
-
@stacksofplates said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
Keep in mind that serverless itself doesn't imply cloud or hosted or third party. You can run serverless on your own server. It requires containers to run in, just like any other workload. If you feel that serverless is a critical part of your design, but don't want a dependency on third parties, you can always run your own.
I presume that this allows you to control latency issues common with serverless by enforcing what stays hot, although I've not tested that theory.
I assume you're talking about OpenFaaS. You can control cold starts but the complexity of setting that up along with maintaining it is light years above deploying to a provider.
As with anything, people not leveraging public cloud offerings (specifically serverless in this case and not just the big 3) is because of FUD. There are very few real cases where it can't be leveraged. As you said in another thread, don't avoid the best because it fails to be perfect.
Doesn't have the same cost benefits running on your own hardware either.
Def not, especially if you are within the free tier every month. The cost in electricity alone is higher let alone maintenance, patching (server and k8s and OpenFaaS), troubleshooting, etc.
That assumes that you can do everything that you need in serverless. I know literally zero companies that can do that. You have to include the cost of moving to bespoke software built purely around this with a team of devs that understand it. The cost, in the real world, is staggering.
-
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
Keep in mind that serverless itself doesn't imply cloud or hosted or third party. You can run serverless on your own server. It requires containers to run in, just like any other workload. If you feel that serverless is a critical part of your design, but don't want a dependency on third parties, you can always run your own.
I presume that this allows you to control latency issues common with serverless by enforcing what stays hot, although I've not tested that theory.
I assume you're talking about OpenFaaS. You can control cold starts but the complexity of setting that up along with maintaining it is light years above deploying to a provider.
As with anything, people not leveraging public cloud offerings (specifically serverless in this case and not just the big 3) is because of FUD. There are very few real cases where it can't be leveraged. As you said in another thread, don't avoid the best because it fails to be perfect.
Doesn't have the same cost benefits running on your own hardware either.
If it doesn't, then it's cloud vs. premises that is being compared, and serverless is a distraction.
-
@stacksofplates said in Looking to Buy a SAN:
I assume you're talking about OpenFaaS. You can control cold starts but the complexity of setting that up along with maintaining it is light years above deploying to a provider.
Except a problem with the providers is cold starts. So if that's needed, it's needed either way.
-
@stacksofplates said in Looking to Buy a SAN:
As with anything, people not leveraging public cloud offerings (specifically serverless in this case and not just the big 3) is because of FUD. There are very few real cases where it can't be leveraged. As you said in another thread, don't avoid the best because it fails to be perfect.
That's actually the opposite. I see loads and loads of people going TO cloud because of FUD. Then getting there and finding out that they can't afford it - either because it costs more (generally a LOT more) or because they can't afford what it costs holistically to make that piece of it cost less.
It sounds good, but we're talking real world here. Outside of a few unique enterprises with crazy deep pockets, or isolated workloads, even big companies can't move to 100% bespoke workloads with all of their investment being driven not by total cost, but by a desire to just say that they are 100% in on cloud.
It doesn't even begin to cover issues like companies that can't have that latency or can't be online. There is zero excuse for pushing cloud as the single answer, it isn't. Period. No ifs, ands, or buts. And calling "basic business decision making" around cost "FUD" is not fair, it's anything but FUD. It's cold, hard math.
-
@scottalanmiller said in Looking to Buy a SAN:
@thecreaitvone91 said in Looking to Buy a SAN:
@stacksofplates said in Looking to Buy a SAN:
@scottalanmiller said in Looking to Buy a SAN:
Keep in mind that serverless itself doesn't imply cloud or hosted or third party. You can run serverless on your own server. It requires containers to run in, just like any other workload. If you feel that serverless is a critical part of your design, but don't want a dependency on third parties, you can always run your own.
I presume that this allows you to control latency issues common with serverless by enforcing what stays hot, although I've not tested that theory.
I assume you're talking about OpenFaaS. You can control cold starts but the complexity of setting that up along with maintaining it is light years above deploying to a provider.
As with anything, people not leveraging public cloud offerings (specifically serverless in this case and not just the big 3) is because of FUD. There are very few real cases where it can't be leveraged. As you said in another thread, don't avoid the best because it fails to be perfect.
Doesn't have the same cost benefits running on your own hardware either.
If it doesn't, then it's cloud vs. premises that is being compared, and serverless is a distraction.
What? Serverless isn't billed or tracked at all unless your function is running. It's not a distraction, it's very much dependent on that architecture for his point.