by samsquire on 5/20/24, 12:58 PM with 3 comments
If you wanted to build a website that was CRUD but required MINIMAL maintenance forever, what tech stack would you use?
I am a hobbyist DevOps engineer but I don't want to do dependency management or yak shaving for side projects.
From my perspective kubernetes is a full time job.
But a binary that processes data is long lasting.
What's a stack that stays working and is secure against OS upgrades?
Is there a cloud service that should be used?
Should I just use Google Forms?
by solardev on 5/20/24, 2:02 PM
There's still somebody managing all the scaling and uptime and updates and upgrades (which is a necessity, because the internet and www aren't static entities, like browser vendors forcing https on everyone a few years ago). But the important thing is that someone ELSE takes care of all that for you so you can write business logic for your app, not worry about infra.
--------
I work for a headless CMS company, and part of our value prop is that our customers (generally) don't have to maintain their own backends, just a frontend. That's still a lot of work to keep up with npm and browser updates though.
Some of our competitors are working towards first party frontends and widgets too, becoming full stack hosted CRUD composables.
There are also others, like MUI, working towards headless frontends that can be easily attached to any backend.
by taylodl on 5/20/24, 1:54 PM
What prevents us from building and deploying software and running it forever without ever touching it?
- OS patches. Modern OSs are continually patched to address security vulnerabilities. Running on a serverless cloud environment eliminates you having to manage those patches.
- System patches - database systems, web servers, those kinds of things. Just like OSs, these types of systems are also continually patched. Again, a serverless cloud environment eliminates your having to manage those patches.
- Library patches - these are the libraries your system is utilizing, for example, your web framework. You can push a lot of that onto your serverless cloud environment, but not all of it. You need a "push-button" deployment that will grab library patches, build, test, and deploy.
- Stable libraries/frameworks - to minimize your maintenance you need libraries/frameworks that aren't changing every other Tuesday. For a while there the JavaScript space was really bad about the constant changes. Even it has settled down over the past few years. A good rule-of-thumb is to not use a library/framework that hasn't been around and in widespread use for at least 3-5 years. You're balancing modern tooling and frameworks against stability.
Where does that leave us?
- Serverless cloud environment - Fully-automated build, test, and deployment - you can even schedule to run on the first of the month - Using libraries/frameworks that are at least 3-5 years old and have widespread use - Expect every 2-3 years there being enough version drift that you may need to make minor modifications to your implementation
If you do these things, then you can expect to run with MINIMAL maintenance for 10-20 years.
The biggest threat to you is going to be the cloud environment. If you consider OS and System patching to be MINIMAL activities, then you can run your own server. All depends on how you define MINIMAL. Personally, I would use AWS since their serverless platform has been stable for several years now and I can automate running my build/test/deploy script to once a month and not even have to worry about it until the test fails - which I would expect it to every 2-3 years. In other words, it should be 2-3 years before you have to do ANYTHING. That's what I call MINIMAL!