Run your own #kubernetes cluster on #raspberrypi's they said, it will be fun they said. So now once every blue moon there is a leader change in the middle of a #terraform apply 🤣
@wyri
I fought with #Terraform and Helm for a while, but gave up. Feels like TF does not mix well with #Kubernetes operations, but it's great to spin up a cluster.
I found the borders between what should be part of IaC and what should be a service deployment operations to be somewhat blurred yet.
Although I think containers are probably here to stay (in likely a even more "invisible" format), the whole orchestration system is too complex and still looking for itself, just like serverless.
At some point, it's likely that building an application will be the same as deploying it, but infrastructure needs to be more abstract away to happen, while still providing good performance (similar to how memory management, multicpu, and networking have been "abstract away" by higher level constructs like virtual address, sockets, and promises.
@ninoles@badnetmask Hard agree here, the infrastructure under your application and services such as redis/postgres/etc shouldn't be a concern to developers. But they do need to understand network/storage latency and how it impacts them, blue green deployments, non-destructive migrations. Essentially everything that directly matters to their application. But where and how exactly the infrastructure works nah. IaC is IMHO for ops.
@wyri Agree. The existence and usage of higher level concepts don't relieve us as developers the knowledge of the limits, constraints and compromise those systems made in their implementation. Memory is still segmented, cpu are sharded, networking is still packets being transmitted unreliably and out of order, but yet, for most software, this is justifiably taken into account by the underlying abstractions rather than by the higher components.
@wyri I think the same will happen to other complexity unrelated to the business-logic of the application, from storage to network bridges, to proxies and orchestration. Those things would likely not disappear, but be abstracted, and only have to be considered as limitations, like how we need to take into account Nigel algo and lingering when working with TCP, but no longer needs to implement our own reordering and ack packets.
@ninoles Looking forward to that. And cloud companies are working hard on that. Just don't run into weirdly documented issues edge cases because then all of this suddenly start to matter again 🤦♂️
@ninoles@badnetmask Containers are here to stay, k8s as well. But for most teams we need k8saas that abstracts the extra those teams don't need/want away. K8s simplicity is also its complexity.
@wyri@badnetmask Yeh, that's what I meant although I still think that K8S and Containers will still likely to evolve to the point of being transparent. We just haven't found the right abstraction yet for what problem they solved (hence the need to often go deep into their configuration).
And I'm sure some people at that point would still say that you aren't real DevOps if you aren't managing your own ingress controller, but yeh, some devs still think that pointers are real memory addresses.
Add comment