51–57 of 57 posts
Earlier quoted context omitted.
What I was getting at was, maybe K8s folks should look ahead (serverless) and not back (PaaS).
Serverless is not a strict upgrade to containerized service deploys in any sense.
It takes containers to their logical conclusion by generalizing them to a function while removing quite some operational overhead on the way.
Earlier quoted context omitted.
Thank you for catching this. We are resolving this now
Just a quick update. We have disabled oAuth2 logins (Github, GitLab and BitBucket) temporarily while we update our configuration settings.
What makes developers to lean towards YAML when JSON and JSON5 are more developer friendly? I personally hate YAML config files.
foo: |
bar
baz
It's not massively useful for k8s outside of config maps, but for other uses of YAML, it's great for embedding snippets of other languages that would otherwise need quoting.
What makes developers to lean towards YAML when JSON and JSON5 are more developer friendly? I personally hate YAML config files.
foo: | bar baz This quote style in YAML is its best feature, IMO. It's not massively useful for k8s outside of config maps, but for other uses of YAML, it's great for embedding snippets of other languages that would otherwise need quoting.
Developers directly touching k8s are hardly low/no code targets. So this doesn’t seem well placed. Unless this imagines a world where devs throw over the fence and ops team is bunch of citizen users.
A company called QualiSystems made some software called CloudShell that was basically a web UI to creating architectural diagrams and hooking each component up to code. There's drivers pre-made for each piece. You connect the pieces, click "Deploy app", and it builds everything you need, deploys your app, runs tests, tears it all down after, etc. The devs literally assemble the whole system in a UI and then just "run" the whole thing. Ops is essentially no longer needed except to write drivers and define policy/governance. This is what we need more of.
Instead, we have Ops teams who are in charge of infrastructure, and spend weeks writing custom Terraform modules and CI/CD solutions just to get some basic infrastructure up. Oh, you need a change? Sure, it'll just be another day full of writing and testing code for me to make that one tiny change in infra. It's ridiculous. Devs should be able to do this work themselves as needed, without waiting for someone else to do it for them. The same idea applies to K8s.
Personally I think "deploying to K8s without YAML" is not a challenging problem for most teams as there are lots of different solutions to that. Where they actually need help is in gaining agency and independence, and to do that we need friendly user interfaces to automated guide-rails, so if the dev wants to deploy a new stack, nothing is getting in their way, but the end result is according to a corporate standard.
Earlier quoted context omitted.
foo: | bar baz This quote style in YAML is its best feature, IMO. It's not massively useful for k8s outside of config maps, but for other uses of YAML, it's great for embedding snippets of other languages that would otherwise need quoting.
Keeping up with indenion is a pain the ass when your config file is large
I use yafolding minor mode in Emacs, it folds based on indentation level, and it handles indentation-oriented syntaxes like Python and YAML as well as block-oriented syntaxes like C, Java, JS and Ruby.
yaml-mode in Emacs highlights :| text in the quoted string highlight colour, so it's easy to see you're still in the block, or whether you've unindented your way out to the YAML again.
I generally try and split out my yaml such that the quoted blocks don't need to be enormous, though. So, single SQL statements, rather than a whole SQL script, to take one motivating example.
I also use highlight-indentation-current-column mode, for an extra visual aid.
Developers directly touching k8s are hardly low/no code targets. So this doesn’t seem well placed. Unless this imagines a world where devs throw over the fence and ops team is bunch of citizen users.
I mean, in an ideal world, it should be a low/no-code target. In the sense that you should be able to manipulate K8s as a dumb user to make it do what you need to do, when you need it, without somebody in your way. A company called QualiSystems made some software called CloudShell that was basically a web UI to creating architectural diagrams and hooking each component up to code. There's drivers pre-made for each pi…
And still, LC/NC isn’t convincing here. Deployment is one piece. Day 2 ops another.
Deployment: shouldn’t be over complex for devs. K8s declarative design is actually supportive of this. Any team which creates undue complexity here is incompetent or has wrong leadership in place.
Day 2 ops is another beast. You get errors, things break, unexpected happens. You can minimize that by architecting a healing, resilient sub-system. But never eliminate it entirely. Expert humans need to step in when it breaks. Not dumb users.
Need of ops team doesn’t go away. And if this team exists, LCNC is not a fit.
If you have to abstract something, do it darn good. If you can’t, don’t step in my way.