[hiou]

I would strongly recommend first making sure you are comfortable with the concepts and architecture of decoupled systems and services. The biggest pain I see in practice are groups that come from monolithic software development backgrounds.

This article is a great example where in using docker for the first time they chose to attempt to run the state layer(database) in a container. State layers tend to be always available and difficult to scale horizontally anyway. This cancels out a decent chunk of the benefits of containers in production. If that team had more experience with service based architecture they would have known to use an third party database service provider(RDS) or host their own on a persistent server. Especially on their first experience with containers.

[kossae]

Echoing the above, this is extremely important. Before jumping into any of the container orchestration tools you should familiarize yourself with terminology of Docker and it's concepts. I made the mistake of jumping in to Swarm (still unstable IMO) and Docker Compose before fully grasping how containers talked to each other, along with many other concepts I should have read up on first. (Un)fortunately, Docker is changing rapidly and the documentation doesn't always keep up. If something in the official docs doesn't make sense, Google around to gain better context.

[allochthon]

> This article is a great example where in using docker for the first time they chose to attempt to run the state layer(database) in a container.

One question I've had as I evaluate moving a Rails/Postgres app to GKE is whether I should abandon the thought and go with AWS/RDS, or containerize Postgres on GKE, or some third option. Has anyone else been part of a similar migration onto GKE, and how did it go?