--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/7bbbc3b3-2095-4821-97c0-a928db7d2d9b%40googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/973517e3-0163-49e8-a88b-b8cfcf98ccf4%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "General Open edX discussion" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/2655bd37-1d63-407f-aa51-254bfe1f56c1%40googlegroups.com.
In the POC, we had a complete system rolling out from scratch in under 5 min. Of course, we used a pre-migrated MySQL database. With all due respect to the migration concept of Django, the incremental one is not sustainable when doing multiple rollouts, and completely not necessary.
One area of concern was the location of the auxiliary services such as Memcached and RabbitMQ inside the k8s cluster – to avoid the latency of traffic when placing components across disparate hardware units and data centers. It probably makes sense co-locating Memcached in the same pods with the Django servers. RabbitMQ is a relic from the past. If we keep the LMS and CMS close to each other and put RabbitMQ near-by as well – we end up with huge pods or tight placement rules that defeat the purpose of doing k8s. So, probably, just bite the bullet and place RabbitMQ anywhere and absorb the latency and cross-zone traffic cost.
Lastly, image build can also be hugely optimized to cut down on the deployment effort for minor code fixes, although that involves image updates, which some folks think are anti-docker. Bottom line, adopting VM-centered designs to modern techs is not easy, but possible.