The word simple should never be in close proximity to Kubernetes. They're mutually exclusive when you consider the total cost of devops, maintenance, debugging, and all the time you'll inevitably waste on things that have nothing to do with your business' unique value proposition.<p>With that being said, adaptjs looks interesting for more complex scenarios that actually warrant such complexity. My only gripe is that 95% of companies that use stuff like this use it to satisfy developer's desires as opposed to satisfying a real product / business need.
For anyone looking to deploy a React app, I'd _highly_ recommend Netlify: <a href="https://www.netlify.com/" rel="nofollow">https://www.netlify.com/</a><p>It integrates with GitHub nicely, offering deploy previews for every push and continuous deployment on pushes to master.<p>Their free tier is generous, too - you can set up a custom domain for each of your projects for free and get up to 300 build minutes for free per month.
I love the component based approach of composing backend assets.<p>This feels like the next step up from terraform based systems.<p>Curious if this approach has been tried before?
A tutorial like this is not a valid Show HN. Please see <a href="https://news.ycombinator.com/showhn.html" rel="nofollow">https://news.ycombinator.com/showhn.html</a>.
Kudos for infrastructure as code. Surprisingly many companies, particularly database companies, don’t deliver infrastructure as code yet, which makes it harder for their prospects to become paying customers.<p>One way to make your examples better would be to make one block of code with all the commands at the bottom or top of the page, or a link to a Makefile, so the motivated reader can copy paste everything into their IDE at once. Terraform provider docs are great for this: code at the top ... however the code is often limited to just one resource, when the user goal requires a number of resources.<p>It’s subtle, but declarative programming could mean one of two things: declare the systems to achieve your goal (this is how it usually works right now) or declare the goal. The latter is much better UX for devops folks because the goal is what we care about. You want to host a site, not connect a bucket to a cdn and dns. Declare the purpose, not the mechanism, and everyone saves a lot of time, because there are many micro states (implementation options) per macro state (big picture goal) (entropy 101)