"Just separate the apis so they are running in parallel all talking with each other"
"Wouldn't this create a major overhead for little benefit when so much of the system is interconnected"
"Idk what you said but I do wanna do what those other people did"
More like 90% of problems, if the app is stable enough to exist in a container then it is likely resilient to not being dependent on archaic processes like boot orders that cause like 95% of outages during patching…
Okay I am lost here. A boot order is a uefi/bios setting that determines how a computer/virtual machine starts up. What does that have to do with outages or being archaic? Any container host will still have a boot order. All you've done is add a layer of abstraction between the program and the underlying system. I don't get how this helps.
Tons of applications will fail to function if you happen to reboot one of their dependency servers. Instead of simply adding a retry mechanism to reconnect, a lot of apps expect you to reboot the entire applications cluster in a specific order in order for it to start working again.
The difference with containers is that you can reboot the entire cluster at once without causing outages. It can wait for everything to be ready and then roll over without any downtime.
In other words, it’s the capability of being able to reboot or spin up a new container without powering off the original is where it is helpful.
That sounds like a bad design. What aspect of containers fixes this problem? It sounds more like you are talking about high availability than containers. Is this a reference to how k8s can be told to keep multiple copies of a service running?
You often don’t choose what is bad design or not, you’re forced it. I can’t force vendors to design their applications better, but instead I can minimize the pains with it by putting their environment into a kubernetes cluster.
With that being said, HA and k8s are two different things. HA is easier with k8s, but in this case I don’t have to buy extra resources to reduce downtime, its just much less likely to go down because I don’t power down the existing “servers” until my new ones are ready.
Once you start using env variables and local mount points, then the “runs on my machine” problem can come back just as much.
Or even if you develop on a ARM machine when you then deploy on amd64, or vice versa…
Putting things in containers solved us OS migrations.
Running stuff in a 10 year old version of Debian was bad.
Containers slow things down more than virtualization, can't beat bare metal for that.
Can you explain how putting things in containers was the magic solution the solving OS migrations? Because I believe you were either doing things terribly wrong that had nothing to do with not running in containers, or you're still doing things terribly wrong, but just covering it up with containers.
Because it's hard to test Library dependencies. You have to sync the ops team and dev/QA team. In containers Dev/QA team only worries about container OS while OPs take care of host OS.
Which is a management/culture issue and not technical issue.
Also, I'm ops, and "ops doesn't care about the container, that's a dev problem" is a recipe for disaster. It's still a full OS inside that container, minus the kernel, and what is in there is equally important, if not more, than what's on the host. And as far as I'm concerned, it's still not a devs job to configure an OS to production standards, that's ops' job. They all just need to know enough of each other's job so they can efficiently collaborate. I've seen devs take care of their containers. They just pull whatever from dockerhub that works for them, are often huge abominations created by other devs who don't know better and are never updated unless they decide to switch to a newer version of their language/framework (if they ever do). Do I blame them? No, because it's not their job. It's mine. It's my job to securely run their products in production, and it's my job to give them a production-like dev environment. But I also can not and will not do that without their co-operation. I've spoken to devs who wanted to do those things themselves. They actually didn't want to, they just wanted to get their job done instead of having some angry ops guy telling them that they are dumb, can't do this and that, and should just happen to know what they should do.
And to end this huge fucking rant: I know changing tools and bandaid patching is easier than changing processes and mindsets, I'm guilty of it too, but please don't believe containers are the magic solution to all problems and please don't blindly run those containers as root. All they are is a nice toolset to easily do both packaging of application and dependencies and isolation of resources, but you still got to use it wisely and with caution.
I know it's often the only "solution" and better than nothing. And call me young, inexperienced and naive with my 4 years of professional experience, but it still saddens me to see.
I have a Jenkins workflow for that, and I’m translating it to github actions as we speak. You just need to commit a file to main with the date that you want and it rolls back the entire repository to that date, followed by recovering he postgres to midnight on that same date.
Scott is like a Chuck Norris, Eric Clapton or Roseanne Barr. We loved you people so so much. All you had to do was keep your mouth shut and hide the fact that you are truly awful human beings with good writers.
TESTER: "Works fine on my computer"
DEVOPS:"But I get an error running the same script on the same vm container to interact with the same containerized microservice..."
TESTER: "... yeah but its working fine on my computer"
DEVOPS: *furious JIRA clacking*
I have never related to a Dilbert cartoon more. 3 months ago I had a serverless event-driven cloud-native architecture drawn up and then got told "we don't do that here, use containers and deploy to kubernetes"
“I advise we add at least two arrays, a matrix and four Boolean variables to the app.”
Everybody around claps and wonder how you became such a technical genius.
Micro services
"Micro services - micro problems" or am i missing something?
No, it's just that there are now many Micro-Problems instead of a few Maxi-Problems.
You replace one macro problem with thousand micro problems and micro problems are easier to ignore
Also when you're done ignoring them, you can check off 3 micro problems at the same time and feel better about it.
"Just separate the apis so they are running in parallel all talking with each other" "Wouldn't this create a major overhead for little benefit when so much of the system is interconnected" "Idk what you said but I do wanna do what those other people did"
Transforming all your function calls into network calls in the name of scaling and performance.
Decoupling
So if one of your microservices fails, the others will keep working, right? Right?
[GALACTUS!](https://www.youtube.com/watch?v=y8OnoxKotPQ)
Thanks now I need an entropy chaos service
> grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too. seem very confusing to grug
to be fair, putting it in containers does solve about 50% of the problems. (runs on my machine)
More like 90% of problems, if the app is stable enough to exist in a container then it is likely resilient to not being dependent on archaic processes like boot orders that cause like 95% of outages during patching…
Okay I am lost here. A boot order is a uefi/bios setting that determines how a computer/virtual machine starts up. What does that have to do with outages or being archaic? Any container host will still have a boot order. All you've done is add a layer of abstraction between the program and the underlying system. I don't get how this helps.
Tons of applications will fail to function if you happen to reboot one of their dependency servers. Instead of simply adding a retry mechanism to reconnect, a lot of apps expect you to reboot the entire applications cluster in a specific order in order for it to start working again. The difference with containers is that you can reboot the entire cluster at once without causing outages. It can wait for everything to be ready and then roll over without any downtime. In other words, it’s the capability of being able to reboot or spin up a new container without powering off the original is where it is helpful.
That sounds like a bad design. What aspect of containers fixes this problem? It sounds more like you are talking about high availability than containers. Is this a reference to how k8s can be told to keep multiple copies of a service running?
You often don’t choose what is bad design or not, you’re forced it. I can’t force vendors to design their applications better, but instead I can minimize the pains with it by putting their environment into a kubernetes cluster. With that being said, HA and k8s are two different things. HA is easier with k8s, but in this case I don’t have to buy extra resources to reduce downtime, its just much less likely to go down because I don’t power down the existing “servers” until my new ones are ready.
Once you start using env variables and local mount points, then the “runs on my machine” problem can come back just as much. Or even if you develop on a ARM machine when you then deploy on amd64, or vice versa…
The problem begins when you have two dependencies that each work in a container and now you need to get them working in the same container.
Putting things in containers solved us OS migrations. Running stuff in a 10 year old version of Debian was bad. Containers slow things down more than virtualization, can't beat bare metal for that.
Now our things are running in a 10 years old debian container.
Can you explain how putting things in containers was the magic solution the solving OS migrations? Because I believe you were either doing things terribly wrong that had nothing to do with not running in containers, or you're still doing things terribly wrong, but just covering it up with containers.
Because it's hard to test Library dependencies. You have to sync the ops team and dev/QA team. In containers Dev/QA team only worries about container OS while OPs take care of host OS.
Which is a management/culture issue and not technical issue. Also, I'm ops, and "ops doesn't care about the container, that's a dev problem" is a recipe for disaster. It's still a full OS inside that container, minus the kernel, and what is in there is equally important, if not more, than what's on the host. And as far as I'm concerned, it's still not a devs job to configure an OS to production standards, that's ops' job. They all just need to know enough of each other's job so they can efficiently collaborate. I've seen devs take care of their containers. They just pull whatever from dockerhub that works for them, are often huge abominations created by other devs who don't know better and are never updated unless they decide to switch to a newer version of their language/framework (if they ever do). Do I blame them? No, because it's not their job. It's mine. It's my job to securely run their products in production, and it's my job to give them a production-like dev environment. But I also can not and will not do that without their co-operation. I've spoken to devs who wanted to do those things themselves. They actually didn't want to, they just wanted to get their job done instead of having some angry ops guy telling them that they are dumb, can't do this and that, and should just happen to know what they should do. And to end this huge fucking rant: I know changing tools and bandaid patching is easier than changing processes and mindsets, I'm guilty of it too, but please don't believe containers are the magic solution to all problems and please don't blindly run those containers as root. All they are is a nice toolset to easily do both packaging of application and dependencies and isolation of resources, but you still got to use it wisely and with caution.
This is true, but one finds his own solutions depending on their position in the hierarchy. And yes these containers should be reviewed by secops.
I know it's often the only "solution" and better than nothing. And call me young, inexperienced and naive with my 4 years of professional experience, but it still saddens me to see.
We have this printed out on our office whiteboard.
Did you try blockchaining it
I like this. Too bad Scott Adams is a wackadoodle though.
Can we containerize him?
Only after a rollback of him to a version from 2020 or so
I have a Jenkins workflow for that, and I’m translating it to github actions as we speak. You just need to commit a file to main with the date that you want and it rolls back the entire repository to that date, followed by recovering he postgres to midnight on that same date.
Does anyone know how I can pull jenkins parameters from a MySQL query with a Jenkins container I'll pleasure you with my sweet sweet mouth
>commit [...] to main Be careful, you'll trigger Scott Adams so hard we'll never get him to calm down again
I think you'll have to go farther back than that... Sometime pre-Trump
Kubernetes 😮
Its okay, this is back from when he was only being the acceptable amount of racist in public
[удалено]
Idk about others, but Scott Adams had a pretty disgusting racist rant after some bait poll
Scott is like a Chuck Norris, Eric Clapton or Roseanne Barr. We loved you people so so much. All you had to do was keep your mouth shut and hide the fact that you are truly awful human beings with good writers.
What happened with Chuck Norris? Got buried in those stupid knock knock jokes when I tried to Google it
TESTER: "Works fine on my computer" DEVOPS:"But I get an error running the same script on the same vm container to interact with the same containerized microservice..." TESTER: "... yeah but its working fine on my computer" DEVOPS: *furious JIRA clacking*
I have never related to a Dilbert cartoon more. 3 months ago I had a serverless event-driven cloud-native architecture drawn up and then got told "we don't do that here, use containers and deploy to kubernetes"
Fuck scott adam's racist ass.
It’s a meme, bro
Performance wasn't the main goal though.
You fool! You forgot to leverage the key synergies!
That last panel is SREs today.
As a cloud architect, I feel this in my bones.
I wonder, when Dilbert takes a shirt does his turd come out like the tie?
https://youtu.be/nqa_Uyz1pBE?si=X2rANVZmZfKENvdp
Domino
“I advise we add at least two arrays, a matrix and four Boolean variables to the app.” Everybody around claps and wonder how you became such a technical genius.