<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>rlander</author><text>Exactly. There&amp;#x27;s no silver bullet, only trade offs.&lt;p&gt;In this case you&amp;#x27;re only shifting the complexity from &amp;quot;maintaining&amp;quot; to &amp;quot;orchestrating&amp;quot;. &amp;quot;Maintaining&amp;quot; means you build (in a semi-automated way) once and most of your work is spent keeping the services running. In the latter, you spend most of your time building the &amp;quot;orchestration&amp;quot; and little time maintaining.&lt;p&gt;If your product is still small, it makes sense to keep most of your infrastructure in &amp;quot;maintaining&amp;quot; since the number of services is small. As the product grows (and your company starts hiring ops people), you can slowly migrate to &amp;quot;orchestrating&amp;quot;.</text><parent_chain><item><author>beering</author><text>For anyone who&amp;#x27;s not used these &amp;quot;managed&amp;quot; services before, I want to add that it&amp;#x27;s still a fuck ton of work. The work shifts from &amp;quot;keeping X server running&amp;quot; to &amp;quot;how do I begin to configure and tune this service&amp;quot;. You &lt;i&gt;will&lt;/i&gt; run into performance issues, config gotchas, voodoo tuning, and maintenance concerns with any of AWS&amp;#x27;s managed databases or k8s.&lt;p&gt;&amp;gt; I&amp;#x27;ll pay Amazon $N&amp;#x2F;month to do that for me&lt;p&gt;Until you pay Amazon $N&amp;#x2F;month to provide the service, and then another $M&amp;#x2F;month to a human to manage it for you.</text></item><item><author>013a</author><text>The big issue I think we miss when people say &amp;quot;why are you using Dynamo, just use SQL&amp;quot; or &amp;quot;why are you using hadoop, a bash shell would be faster&amp;quot; or &amp;quot;why are you using containers and kubernetes, just host a raspberry pi in your closet&amp;quot;:&lt;p&gt;The former examples are all managed! That&amp;#x27;s amazing for scaling teams.&lt;p&gt;(SQL can be managed with, say, RDS. Sure. But it&amp;#x27;s not the same &lt;i&gt;level&lt;/i&gt; of managed as Dynamo (or Firebase or something like that). It still requires maintenance and tuning and upkeep. Maybe that&amp;#x27;s fine for you (remember: the point of this article was to tell you to THINK, not to just ignore any big tech products that come out). But don&amp;#x27;t discount the advantage of true serverless.)&lt;p&gt;My goal is to be totally unable to SSH into everything that powers my app. I&amp;#x27;m not saying that I want a stack where I don&amp;#x27;t have to. I&amp;#x27;m saying that I literally cannot, even if I wanted to real bad. That&amp;#x27;s why serverless is the future; not because of the massive scale it enables, but because fuck maintenance, fuck operations, fuck worrying about buffer overflow bugs in OpenSSL, I&amp;#x27;ll pay Amazon $N&amp;#x2F;month to do that for me, all that matters is the product.</text></item></parent_chain></comment><story><title>You Are Not Google (2017)</title><url>https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>brobdingnagians</author><text>The general fact of reality is that if you are building anything technical, then knowing and managing the details, whatever the details are, will get you a lot more bang for your buck. Reality isn&amp;#x27;t just a garden variety one-size fits all kind of thing, so creating something usually isn&amp;#x27;t either. If you just want a blog like everyone else&amp;#x27;s, then that comes packaged, but if you want something special, you will always have to put in the expertise.</text><parent_chain><item><author>beering</author><text>For anyone who&amp;#x27;s not used these &amp;quot;managed&amp;quot; services before, I want to add that it&amp;#x27;s still a fuck ton of work. The work shifts from &amp;quot;keeping X server running&amp;quot; to &amp;quot;how do I begin to configure and tune this service&amp;quot;. You &lt;i&gt;will&lt;/i&gt; run into performance issues, config gotchas, voodoo tuning, and maintenance concerns with any of AWS&amp;#x27;s managed databases or k8s.&lt;p&gt;&amp;gt; I&amp;#x27;ll pay Amazon $N&amp;#x2F;month to do that for me&lt;p&gt;Until you pay Amazon $N&amp;#x2F;month to provide the service, and then another $M&amp;#x2F;month to a human to manage it for you.</text></item><item><author>013a</author><text>The big issue I think we miss when people say &amp;quot;why are you using Dynamo, just use SQL&amp;quot; or &amp;quot;why are you using hadoop, a bash shell would be faster&amp;quot; or &amp;quot;why are you using containers and kubernetes, just host a raspberry pi in your closet&amp;quot;:&lt;p&gt;The former examples are all managed! That&amp;#x27;s amazing for scaling teams.&lt;p&gt;(SQL can be managed with, say, RDS. Sure. But it&amp;#x27;s not the same &lt;i&gt;level&lt;/i&gt; of managed as Dynamo (or Firebase or something like that). It still requires maintenance and tuning and upkeep. Maybe that&amp;#x27;s fine for you (remember: the point of this article was to tell you to THINK, not to just ignore any big tech products that come out). But don&amp;#x27;t discount the advantage of true serverless.)&lt;p&gt;My goal is to be totally unable to SSH into everything that powers my app. I&amp;#x27;m not saying that I want a stack where I don&amp;#x27;t have to. I&amp;#x27;m saying that I literally cannot, even if I wanted to real bad. That&amp;#x27;s why serverless is the future; not because of the massive scale it enables, but because fuck maintenance, fuck operations, fuck worrying about buffer overflow bugs in OpenSSL, I&amp;#x27;ll pay Amazon $N&amp;#x2F;month to do that for me, all that matters is the product.</text></item></parent_chain></comment><story><title>You Are Not Google (2017)</title><url>https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb</url></story>