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.
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.
I do agree that Kubernetes is too complicated an low-level for most needs, especially for small projects. However,
my experience is that while most apps start out really simple, if they are even modestly successful, they'll eventually need something not supported by whatever PaaS/Serverless/whatever they've chosen for deployment.
The hope with Adapt is that you start out with a really simple interface that looks like a PaaS/Serverless (Heroku, Zeit, adapt new/run etc.) but can be tweaked over time without having to throw out everything that was great about the PaaS. And by no means is Adapt limited to Kubernetes, it's just what is there now.
I think that a simple interface to something like Fargate/ECS with Adapt would be pretty nice as it removes the K8s complexity but handles all the container build/repo management stuff for you.
For anyone looking to deploy a React app, I'd _highly_ recommend Netlify: https://www.netlify.com/
It integrates with GitHub nicely, offering deploy previews for every push and continuous deployment on pushes to master.
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'm a big fan of Netlify for simple apps that don't have their own backend API, services, etc. They've done an awesome job of making things really easy.
Our vision with Adapt is to provide that same level of ease of use, but allow it to grow with your app. As your app grows and becomes more complex or as your app's needs change over time, it's easy for Adapt to handle those needs as well, in a way that's independent of any particular cloud or underlying infrastructure technology.
I'm not familiar with Adapt before this post, but in general, yeah, a componentized backend is a very popular approach, particularly on Kubernetes, e.g., with tools like Jsonnet, Kustomize, Helm (umbrella) charts.
"Next gen" alternatives to Terraform like Pulumi also take a different approach to similar ideas.
You might also be interested in Cloud Native Application Bundles [1].
[Update: If I'm understanding Adapt right, it looks like Adapt is going for similar ideas but doing the configuration management in JSX and attempting to automate much of the DevOps details for the end user. It sort of looks like how Create React App insulates one from Webpack for common use cases. If it works as well as it sounds in the tutorial, this could be an easier to get up and running alternative to e.g., a Docker Compose setup, for someone whose skills are more on the frontend side.]
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.
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.
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)
[+] [-] transitivebs|6 years ago|reply
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.
[+] [-] mv1|6 years ago|reply
The hope with Adapt is that you start out with a really simple interface that looks like a PaaS/Serverless (Heroku, Zeit, adapt new/run etc.) but can be tweaked over time without having to throw out everything that was great about the PaaS. And by no means is Adapt limited to Kubernetes, it's just what is there now.
I think that a simple interface to something like Fargate/ECS with Adapt would be pretty nice as it removes the K8s complexity but handles all the container build/repo management stuff for you.
[+] [-] veeralpatel979|6 years ago|reply
It integrates with GitHub nicely, offering deploy previews for every push and continuous deployment on pushes to master.
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.
[+] [-] mterrel|6 years ago|reply
Our vision with Adapt is to provide that same level of ease of use, but allow it to grow with your app. As your app grows and becomes more complex or as your app's needs change over time, it's easy for Adapt to handle those needs as well, in a way that's independent of any particular cloud or underlying infrastructure technology.
[+] [-] sax|6 years ago|reply
This feels like the next step up from terraform based systems.
Curious if this approach has been tried before?
[+] [-] tedmiston|6 years ago|reply
"Next gen" alternatives to Terraform like Pulumi also take a different approach to similar ideas.
You might also be interested in Cloud Native Application Bundles [1].
[Update: If I'm understanding Adapt right, it looks like Adapt is going for similar ideas but doing the configuration management in JSX and attempting to automate much of the DevOps details for the end user. It sort of looks like how Create React App insulates one from Webpack for common use cases. If it works as well as it sounds in the tutorial, this could be an easier to get up and running alternative to e.g., a Docker Compose setup, for someone whose skills are more on the frontend side.]
[1]: https://cnab.io/
[+] [-] dang|6 years ago|reply
[+] [-] mv1|6 years ago|reply
[+] [-] bionhoward|6 years ago|reply
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.
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)