<story><title>Don&apos;t use Kubernetes yet</title><url>https://matt-rickard.com/dont-use-kubernetes-yet/</url></story><parent_chain><item><author>danjac</author><text>The problem I keep seeing in startups is that a lot of startup tech founders and employees don&amp;#x27;t see a startup as an embryonic business that will grow over the long term into a money-making venture requiring calculated risks and priorities, but rather as a personal playground to do all the fun things they were not allowed to do at their old BigCorp.&lt;p&gt;Use cool framework or language X? Use Kubernetes? Microservices? Lambdas? No-SQL? Two fingers to BigCorp, I&amp;#x27;m CTO&amp;#x2F;tech employee #1 at a new startup and I get to do whatever I want. If and when it goes down in flames, I now have these skills on my resume I can leverage into a better opportunity.&lt;p&gt;Ideally your first tech employee&amp;#x2F;CTO should be a seasoned hand who has been burned before, who keeps an open mind to new approaches but knows when and how to adopt it. But it&amp;#x27;s quite rare to have seasoned developers in such startups, they&amp;#x27;re not attracted by the risk and chaos of these environments as they have better options and startups generally can&amp;#x27;t afford them.</text></item><item><author>throwaway787544</author><text>The question of whether to use K8s or not is like wondering what kind of saw you should use to cut wood. There&amp;#x27;s different saws for different purposes. But even with the right saw, you still have to know how to use it correctly. Better to use a hand saw correctly than a table saw incorrectly. (you &lt;i&gt;can&lt;/i&gt; use a table saw incorrectly, but best case the work ends up crap, worst case you lose a finger)&lt;p&gt;After building infrastructure for dozens of teams, I&amp;#x27;m quite convinced of the following:&lt;p&gt;- if your people aren&amp;#x27;t very skilled, they won&amp;#x27;t build anything well. most software engineers i&amp;#x27;ve seen professionally working in the cloud are handymen trying to build a wood cabinet.&lt;p&gt;- if your people can&amp;#x27;t build well, it doesn&amp;#x27;t matter what technology they use. choosing between building a cabinet out of metal or cherry wood doesn&amp;#x27;t make much difference if they&amp;#x27;ve never built a cabinet before.&lt;p&gt;- if the first two holds: then only use the technology which requires the least skill to use well, and where the amount of maintenance is closest to zero. don&amp;#x27;t build a wood cabinet from scratch when you can buy flat pack. don&amp;#x27;t buy flat pack when you can buy an assembled cabinet, get it shipped, and carried into your office.&lt;p&gt;- if using the aforementioned technology requires &amp;#x27;building&amp;#x27; or &amp;#x27;assembling&amp;#x27;, and that is not core to the customer-facing aspect of your product, then you should not be building, you should be buying. if your business doesn&amp;#x27;t involve assembling flat pack furniture, don&amp;#x27;t ask your employees to build their own desks and chairs from Home Depot or Ikea parts. buy the premade desk and chairs, use them to make your actual product.&lt;p&gt;- a software engineer knows as much about cloud architecture as a fine woodworker knows about framing. &amp;quot;it&amp;#x27;s all just wood&amp;quot; until the house takes 10x as long to frame and is 10x as expensive and still doesn&amp;#x27;t meet code.&lt;p&gt;- people &lt;i&gt;will&lt;/i&gt; try to build things they don&amp;#x27;t fully understand and leave the company before anyone realizes the mess they&amp;#x27;ve made. imagine your retail store is accessible by driving a car over a wooden bridge built by a handyman.</text></item></parent_chain><comment><author>throwaway894345</author><text>I think that’s true, but also it’s not clear what tools a startup should use. Even if they stick to a single VM, managing that VM in a way that is reasonably safe and reproducible is somewhat important—the more often you have people manually SSHing onto the VM the more likely you will need to recover functionality from scratch while also making it almost impossible to do so in any timely manner (because the functioning state of the VM is the result of many thousands of manual changes, many of which are undocumented, incompletely documented, or incorrectly documented). So then you can start learning about automating changes on a machine, but now you’re into territory that is about as complex as Kubernetes (or perhaps not “complex” as much as “you have to figure out what combination of tools and practices will work”, while a cloud-provider’s managed Kubernetes makes a lot of these kinds of choices for you out of the box and many others are obvious).&lt;p&gt;Similarly, you might reasonably try to use a PaaS, and it might work at first, but then you need to do something as common as a background task and find that your PaaS doesn’t support things like that (you can try running it in a process in your PaaS’s container and just accept that the background tasks are likely to be interrupted periodically?).&lt;p&gt;I don’t think Kubernetes is the 
answer for a startup, but it’s not obvious what “the answer” is, and much of the discussion ignores the complexity in the alternatives. It’s not helpful to say “Kubernetes is too complex” without articulating a simpler alternative (unless you are hinting at a market opportunity).</text></comment>
<story><title>Don&apos;t use Kubernetes yet</title><url>https://matt-rickard.com/dont-use-kubernetes-yet/</url></story><parent_chain><item><author>danjac</author><text>The problem I keep seeing in startups is that a lot of startup tech founders and employees don&amp;#x27;t see a startup as an embryonic business that will grow over the long term into a money-making venture requiring calculated risks and priorities, but rather as a personal playground to do all the fun things they were not allowed to do at their old BigCorp.&lt;p&gt;Use cool framework or language X? Use Kubernetes? Microservices? Lambdas? No-SQL? Two fingers to BigCorp, I&amp;#x27;m CTO&amp;#x2F;tech employee #1 at a new startup and I get to do whatever I want. If and when it goes down in flames, I now have these skills on my resume I can leverage into a better opportunity.&lt;p&gt;Ideally your first tech employee&amp;#x2F;CTO should be a seasoned hand who has been burned before, who keeps an open mind to new approaches but knows when and how to adopt it. But it&amp;#x27;s quite rare to have seasoned developers in such startups, they&amp;#x27;re not attracted by the risk and chaos of these environments as they have better options and startups generally can&amp;#x27;t afford them.</text></item><item><author>throwaway787544</author><text>The question of whether to use K8s or not is like wondering what kind of saw you should use to cut wood. There&amp;#x27;s different saws for different purposes. But even with the right saw, you still have to know how to use it correctly. Better to use a hand saw correctly than a table saw incorrectly. (you &lt;i&gt;can&lt;/i&gt; use a table saw incorrectly, but best case the work ends up crap, worst case you lose a finger)&lt;p&gt;After building infrastructure for dozens of teams, I&amp;#x27;m quite convinced of the following:&lt;p&gt;- if your people aren&amp;#x27;t very skilled, they won&amp;#x27;t build anything well. most software engineers i&amp;#x27;ve seen professionally working in the cloud are handymen trying to build a wood cabinet.&lt;p&gt;- if your people can&amp;#x27;t build well, it doesn&amp;#x27;t matter what technology they use. choosing between building a cabinet out of metal or cherry wood doesn&amp;#x27;t make much difference if they&amp;#x27;ve never built a cabinet before.&lt;p&gt;- if the first two holds: then only use the technology which requires the least skill to use well, and where the amount of maintenance is closest to zero. don&amp;#x27;t build a wood cabinet from scratch when you can buy flat pack. don&amp;#x27;t buy flat pack when you can buy an assembled cabinet, get it shipped, and carried into your office.&lt;p&gt;- if using the aforementioned technology requires &amp;#x27;building&amp;#x27; or &amp;#x27;assembling&amp;#x27;, and that is not core to the customer-facing aspect of your product, then you should not be building, you should be buying. if your business doesn&amp;#x27;t involve assembling flat pack furniture, don&amp;#x27;t ask your employees to build their own desks and chairs from Home Depot or Ikea parts. buy the premade desk and chairs, use them to make your actual product.&lt;p&gt;- a software engineer knows as much about cloud architecture as a fine woodworker knows about framing. &amp;quot;it&amp;#x27;s all just wood&amp;quot; until the house takes 10x as long to frame and is 10x as expensive and still doesn&amp;#x27;t meet code.&lt;p&gt;- people &lt;i&gt;will&lt;/i&gt; try to build things they don&amp;#x27;t fully understand and leave the company before anyone realizes the mess they&amp;#x27;ve made. imagine your retail store is accessible by driving a car over a wooden bridge built by a handyman.</text></item></parent_chain><comment><author>arinlen</author><text>&amp;gt; &lt;i&gt;The problem I keep seeing in startups is that a lot of startup tech founders and employees don&amp;#x27;t see a startup as an embryonic business that will grow over the long term into a money-making venture requiring calculated risks and priorities, but rather as a personal playground to do all the fun things they were not allowed to do at their old BigCorp.&lt;/i&gt;&lt;p&gt;I don&amp;#x27;t think this is an accurate or realistic take.&lt;p&gt;You&amp;#x27;re actually stating that tech founders, when starting greenfields projects, actually take the time to invest in frameworks that offer advantages over outdated legacy systems adopted way back in the past which are only in place because there is no chance in hell a company will spend resources to pay off their technical debt.&lt;p&gt;There was a point in time where adopting Java+Spring, or even React was something only some silly risk-taker would do when playing around in their personal playground. But as the investment paid off so handsomely, they have become baseline options.&lt;p&gt;If you are free to choose the absolute best tool you have at your reach, why wouldn&amp;#x27;t you?</text></comment>