search

redbadger / badger-brian

Dapr(y) version of Badger Brain
3 stars 0 forks source link

Can Dapr reduce kustomization / base / overlay incidental complexity #14

Open ceddlyburge opened 3 years ago

ceddlyburge commented 3 years ago

David Laban has this to say about the setup of the repo as at 2021-04-16:

I'm a little bit sad that we had to go down the base+overlays route, because of all the incidental complexity that it involves. After the hard-learned lessons of going over-the-top with infra complexity on the FutureNHS project, I am very wary of complexity creep in kubernetes setups.

The nirvana that I was hoping for with dapr is that everyone in the team knows the runes required to spin up all services locally without docker (in a hot-reloading fashion if desired) and then we have a single production cluster that's configured with flat kubernetes manifests.

I suppose the thing that overlays give is is the ability to test the whole shebang out on a completely separate non-production environment so we're confident that our manifest changes are good before shipping them to prod, so this PR is a net-win, but it is a trade-off.

It's probably worth keeping an eye out to see if there is a third way, that can give us the confidence without the complexity.

ceddlyburge commented 3 years ago

For some context this is Stuarts blog post on reducing infrastructure complexity https://awesome.red-badger.com/stuartharris/platform-revolution/

ceddlyburge commented 3 years ago

Service meshes exist in the network layers. Dapr exosts in the application code layer, and abstracts away the infrastructure concerns needed for things like managing state, publishing messages between microservices, and triggering events through event bindings, so hopefully these things will remove a lot of complexity (even if we still retain some kubernetes complexity) https://go.forrester.com/blogs/dapr-service-mesh-done-right/

ceddlyburge commented 3 years ago

Dapr can run locally, without kubernetes or docker, but obviously doing this means that you don't test the production manifests, which currently are the most complicated things in the repo (although this wouldn't be the case in a real repo, or probably even in this repo once we have finished all the work).

ceddlyburge commented 3 years ago

I think that most of the kustomization / base / overlay complexity comes from the fact that we are forced to use a container registry as an intermediary.

Everything I want is in the repo (for the sake of argument), and I want to be able to deploy it atomically, but I can't, as there are two steps. Step 1 is to deploy things to the container registry, and step 2 is to deploy to a cluster, which then fetches things from the container registry (and we have to be careful that we fetch the thing we just pushed, and not some other version of it, which is a faff, and can easily lead to errors). I think this is the problem that leads to a lot of the incidental base / overlays / kustomization / makefile complexity. It's probably beyond our control, but interesting to think about.

Obviously the container registry is useful for the base images in the dockerfiles though.