System Initiative: Second Wave DevOps
systeminit.com
System Initiative: Second Wave DevOps
1–10 of 80 posts
Re: System Initiative: Second Wave DevOps
#2At least a couple words about what that might look like?
Re: System Initiative: Second Wave DevOps
#3Check out Adam's "What if infrastructure as code never existed" talk from a month or two ago. Great framing for SI and entertaining.
https://www.youtube.com/watch?v=5lPa2U239C4
Re: System Initiative: Second Wave DevOps
#4At least a couple words about what that might look like?
The homepage has a video demo: https://www.systeminit.com/
Re: System Initiative: Second Wave DevOps
#5Hi! Adam Jacob here. Happy to answer questions!
Re: System Initiative: Second Wave DevOps
#6I applaud the effort here, but just looking at how messy the graph is to deploy one docker image doesn't exactly make me want to try this for anything with a level of complexity beyond that.
Re: System Initiative: Second Wave DevOps
#7After reading this post, I've browsed the site. I'm not sure how this is anything but significantly worse than the current model?
I've been around long enough to know that any "no code" style interface or GUI are typically the _problem_ not the solution. Regardless of the code they export, you end up with fat fingers, misclicks, forgotten UI paths to follow... Taking a software eng approach to shipping infra is a stable, known process that the infra team and the software teams can understand, no specialized GUI tool knowledge required.
I've been using the same basic terraform modules, jenkins pipelines, and infra architecture for nearly 7 years across multiple companies and numerous cloud deployments. It's not fancy but it justworks.jpg. Every time I re-use that code for a new deployment or account I save TONS of time.
Devops doesn't have to be hard. Infrastructure doesn't have to be complex. Deploying every day isn't _that_ difficult. KISS Method is key, especially when you're looking for speed. Using _less_ tools from the CNCF is better, and will let you move faster, not adding a new one.
Re: System Initiative: Second Wave DevOps
#8>Doing “DevOps work” is unquestionably the worst part of building a modern application. It’s full of tiny papercuts, indignities we suffer in our toolchains, our feedback loops, and our software. It’s a city of brutalist buildings filled with sharp-edged couches pretending to be comfortable. Think of all the advances in how we interact with tools in other domains - then take a look at the way you build, deploy, and operate your software, at all the crazy gyrations you use to glue it all together - and ask yourself why you accept it.
I dunno, usually I find databases and migrations to be the hard part. At this point, I have enough examples of app deploys that I can have a new app up and running on a pair of VMs with a robust blue/green deploy and backups inside of an hour or two, with deploy by Github Actions responding to pushes to prod branch.
Even if you don't have my company's half-decade worth of example devops, you can do something easier, like a single instance on a Digital Ocean machine with deploy by "ssh -A server 'cd yourapp && git pull && sudo systemctl restart yourapp'". Sure, you'll have a few seconds of downtime, and you'll expose your SSH keys to anyone on that box for those few seconds, but if you know some Linux and nginx, you can get this working inside of an hour from scratch.
Re: System Initiative: Second Wave DevOps
#9I applaud the effort here, but just looking at how messy the graph is to deploy one docker image doesn't exactly make me want to try this for anything with a level of complexity beyond that.
This is a reasonable reaction! :) There are a lot of ways to make the visual interface scale - examples from things like Blender, Figma, etc. We believe we can use them to make it scale semantically as the complexity climbs.
Re: System Initiative: Second Wave DevOps
#10>Doing “DevOps work” is unquestionably the worst part of building a modern application. It’s full of tiny papercuts, indignities we suffer in our toolchains, our feedback loops, and our software. It’s a city of brutalist buildings filled with sharp-edged couches pretending to be comfortable. Think of all the advances in how we interact with tools in other domains - then take a look at the way you build, deploy, and o…
Fundamentally, I think the “why” is still the fact that DevEx started with devs, and DevOps started as a collaboration with Ops people, who already were not speaking the same language of robustness that we do. Which is a little weird, and probably part of the friction between the groups.
They historically took on the reliability role, if nobody else did, but they were implementing reliability on top of a house of cards, which is a kind of hypocrisy that makes even mediocre devs bristle. Don’t lecture me on robust software, boyo. Your tools are made of string cheese and staples.