When I started in software development, I was mostly working on monoliths. All dependencies were vendored or were expected to be dynamically linked on the system where they were deployed.
Next, I started working with Docker and languages with better package management. Dependencies were fetched in CI and were either statically linked or packaged in a container with the application I was working on. Still, these were mostly monoliths or applications with simple API boundaries and a known set of clients.
In the past few years, almost everything I have written has involved cloud services, and when I deploy an application, I do not know what other services may soon depend on the one I just wrote. This type of workflow that depends on runtime systems that I do not own - and where my app may become a runtime dependency of someone else - is what I am referring to as a "modern development workflow".
Thank you. That’s a worthwhile distinction to make. I often hear the word “modern” bandied about by developers trying to advocate for something novel. If you haven’t already it might be rewarding to fully articulate this in long form, including the consequences and implications. I wish I was a better writer or I’d write this myself.
Not sure about the GP, but for me, it's a pretty big difference jumping from tools like docker to ones like buildah, microk8s— I feel like k8s really makes good on many of the original promises of the "container revolution" in terms of automatic provisioning/scaling/image lifecycle management, declaratively defining relationships between containers, adding a much needed upper layer of abstraction in terms of the pod, etc.
I know docker has made it part of the way there over the years with Compose and so on, but it's all felt pretty ad-hoc, whereas k8s feels like a cohesive system designed against a clear vision (which makes sense, since it was designed as borg 2.0)— no one else working in this space had the benefit of having already built a giant system for it and used it at scale for years beforehand.
Next, I started working with Docker and languages with better package management. Dependencies were fetched in CI and were either statically linked or packaged in a container with the application I was working on. Still, these were mostly monoliths or applications with simple API boundaries and a known set of clients.
In the past few years, almost everything I have written has involved cloud services, and when I deploy an application, I do not know what other services may soon depend on the one I just wrote. This type of workflow that depends on runtime systems that I do not own - and where my app may become a runtime dependency of someone else - is what I am referring to as a "modern development workflow".