Re:Gitlab's Journey from Azure to GCP
by tracker1 on Friday May 03, 2019 @02:28PM
(#19820970)
I might agree that full on kubernetes infrastructure may be overkill... but there are a lot of smaller options for using containers. Simplest that I've used was 3 dokku servers behind a load balancer and all apps were deployed to all three servers in the same way. DB managed outside the containers.
I don't even do development in containers, but run services I'm not actively working on in them locally... this lets me have them nearly always on in the background and work on the piece I need to work on in the foreground. It's simply a matter of automation with a fast reset to zero.
The code that gets exercised the most is the code you can trust the most... by automating it once, you can repeat it. By automating with a container, you can isolate it. You can ensure the boundaries are proper, well defined and enough detail/documentation to repeat again and again. I do containerize the DB locally as well. I can reset and spin up the application stack I'm working on in under a minute total. Generally only resetting the db (around 18 seconds) or api (around 5) when those parts of the application are changed. I can work on the front end locally and just have the background in the background. I can tweak the background without touching shared environments. I can tear it all down and work on a different project without borking my host/local environment.
Yeah, orchestration setup and config in a cluster for hosting can be hard to learn (still learning current kubernetes myself) ... that doesn't mean that containers themselves are overkill.
I don't even do development in containers, but run services I'm not actively working on in them locally... this lets me have them nearly always on in the background and work on the piece I need to work on in the foreground. It's simply a matter of automation with a fast reset to zero.
The code that gets exercised the most is the code you can trust the most... by automating it once, you can repeat it. By automating with a container, you can isolate it. You can ensure the boundaries are proper, well defined and enough detail/documentation to repeat again and again. I do containerize the DB locally as well. I can reset and spin up the application stack I'm working on in under a minute total. Generally only resetting the db (around 18 seconds) or api (around 5) when those parts of the application are changed. I can work on the front end locally and just have the background in the background. I can tweak the background without touching shared environments. I can tear it all down and work on a different project without borking my host/local environment.
Yeah, orchestration setup and config in a cluster for hosting can be hard to learn (still learning current kubernetes myself) ... that doesn't mean that containers themselves are overkill.