Hi everyone, I’m trying to wrap my head around dev ops but struggling with the whole continuous integration workflow. From my understanding it goes something like the following:
1. pushing a change to some repository (git)
2. Some tool (Jenkins) tries to build it and if it’s succeed, creates a image /container (docker).

These containers are hosted on some cloud service (aws)

Some workflow, walkthrough, or examples would be very appreciate.

That's about right, each of those are topics that take time to get comfortable with, but there are shortcuts.

For example, if you use bitbucket for git, you can set up the pipelines to deploy your build to the container of your choice

Good ol' days were when you only needed an ftp client and some PHP (okay I'm happier now tho)

How does tools such as elastic beanstalk and cloud foundry is related to the devops workflow? Is it that these tool skip the git building process and push the application directly to the cloud (aws)?@ananaszjoe

@newguy1974929 git shouldn't be skipped and these won't help you to skip it if you wanted to.
Elastic beanstalk is great because it takes the pain out of scaling.
When your product gets popular, like with shops on cyber monday, your hosting solution needs to be able to handle that. You either pay a dedicated devops engineer and have them on-call 24/7, or pay an agency to do it, or trust elastic beanstalk that scales automatically.

As with cloud foundry, I have no experience with that but it seems robust.

@ananaszjoe thanks for all the helpful feedback. One last question. I did a little research and was looking into kubernetes vs elastic beanstack. So to me it looks like elastic beanstack is for 1 projects while kubernetes is for managing many containers. Is this correct?

I Iike kuberneties. There are docker containers and lxc/lxd. Short term and long running. Docker works for most, but not everything.

Never used beanstalk. Do others know?

@tamusjroyce care to share some examples of bad cases of using docker containers?

Highly concurrent Databases that require a stable environment. Legacy software not designed to be spun up and down. Or work within such a thin environment. Data lake, warehouse tools, and reporting. Development (vagrant).