<story><title>How I run my servers (2022)</title><url>https://blog.wesleyac.com/posts/how-i-run-my-servers</url></story><parent_chain><item><author>bob1029</author><text>HTTP triggered cloud functions are my new favorite thing. They can evaporate complexity if you dance around the various vendors carefully enough. This is the only cloud-native abstraction that feels &amp;quot;end game&amp;quot; to me. I still haven&amp;#x27;t been able to deploy a cloud function and get the &amp;quot;runner&amp;quot; into a state where I&amp;#x27;d have to contact support or issue arcane console commands. I&amp;#x27;ve done well over 2000 deploys by now for just one app alone with a 100% success rate.&lt;p&gt;Performance is fantastic (using isolated app service plans in Azure), and I am completely over the ideological principals against per-request billing. Absolutely, you can do it cheaper if you own the literal real estate the servers are running inside of. Paying for flat colo fees makes per-request costs look ludicrous on the surface. But, achieving all of the other attributes of simple HTTP triggered functions in a DIY context is very challenging without also spinning up a billion dollar corporation and hiring 1k more people. Compliance, audits, etc are where it gets real super fast.&lt;p&gt;The &amp;quot;what about lock-in?&amp;quot; argument doesn&amp;#x27;t work for me anymore. HTTP triggers are a pretty natural interface to code against: &amp;quot;I&amp;#x27;ve got a HTTP request for you to review, give me some HTTP response please&amp;quot;. The only stuff that is vendor-specific are the actual trigger method signatures and specific contexts beyond HTTP, such as OIDC or SAML claims. You&amp;#x27;d really have to go out of your way to design an HTTP trigger web app&amp;#x2F;API solution that is impossible to refactor for another vendor within a week or so.&lt;p&gt;If your business is a personal blog, then yeah I get it. It&amp;#x27;s more &lt;i&gt;fun&lt;/i&gt; to buy a VM in Hetzner and get all artisanal about it. Also, if you are operating in a totally unregulated industry, perhaps you can make some stronger arguments against completely outsourcing the servers in favor of splitting hairs on margin vs complexity.</text></item></parent_chain><comment><author>WastingMyTime89</author><text>&amp;gt; But, achieving all of the other attributes of simple HTTP triggered functions in a DIY context is very challenging without also spinning up a billion dollar corporation and hiring 1k more people.&lt;p&gt;I literally rolled my eyes reading that. How do you think we did before cloud computing?&lt;p&gt;I am currently in charge of multiple teams scaling and deploying innovative applications for a large industrial company. We are using Azure for everything. Our cloud costs are insane for our number of users. I used to manage applications with ten times more user for one hundredth of the cost and less complexity. It’s billed to another part of the company which is responsible for this dubious choice (I really hope someone is getting nice business trips paid by MS so it’s not a complete waste) so I don’t care but how people can blindly put faith in the cloud is beside me.</text></comment>
<story><title>How I run my servers (2022)</title><url>https://blog.wesleyac.com/posts/how-i-run-my-servers</url></story><parent_chain><item><author>bob1029</author><text>HTTP triggered cloud functions are my new favorite thing. They can evaporate complexity if you dance around the various vendors carefully enough. This is the only cloud-native abstraction that feels &amp;quot;end game&amp;quot; to me. I still haven&amp;#x27;t been able to deploy a cloud function and get the &amp;quot;runner&amp;quot; into a state where I&amp;#x27;d have to contact support or issue arcane console commands. I&amp;#x27;ve done well over 2000 deploys by now for just one app alone with a 100% success rate.&lt;p&gt;Performance is fantastic (using isolated app service plans in Azure), and I am completely over the ideological principals against per-request billing. Absolutely, you can do it cheaper if you own the literal real estate the servers are running inside of. Paying for flat colo fees makes per-request costs look ludicrous on the surface. But, achieving all of the other attributes of simple HTTP triggered functions in a DIY context is very challenging without also spinning up a billion dollar corporation and hiring 1k more people. Compliance, audits, etc are where it gets real super fast.&lt;p&gt;The &amp;quot;what about lock-in?&amp;quot; argument doesn&amp;#x27;t work for me anymore. HTTP triggers are a pretty natural interface to code against: &amp;quot;I&amp;#x27;ve got a HTTP request for you to review, give me some HTTP response please&amp;quot;. The only stuff that is vendor-specific are the actual trigger method signatures and specific contexts beyond HTTP, such as OIDC or SAML claims. You&amp;#x27;d really have to go out of your way to design an HTTP trigger web app&amp;#x2F;API solution that is impossible to refactor for another vendor within a week or so.&lt;p&gt;If your business is a personal blog, then yeah I get it. It&amp;#x27;s more &lt;i&gt;fun&lt;/i&gt; to buy a VM in Hetzner and get all artisanal about it. Also, if you are operating in a totally unregulated industry, perhaps you can make some stronger arguments against completely outsourcing the servers in favor of splitting hairs on margin vs complexity.</text></item></parent_chain><comment><author>RadiozRadioz</author><text>I work in an extremely highly regulated industry and I don&amp;#x27;t understand your last sentence. It is in our best interest to run all our own hardware. We can&amp;#x27;t even take pictures in the office, there&amp;#x27;s an absolute 0% chance we&amp;#x27;re trusting a cloud provider with anything.</text></comment>