the advantage of older developers is that they have seen the same patterns before. For instance, younger devs might think microservices is the hot thing while an older dev is thinking that it just looks like a poor man's erlang from the 1970s and knows to wait a few years when all the CI/CD and orhestration is integrated and commoditized.
If you are creating a bunch of “dev op scripts”, you’re doing it wrong.
I wrote one parameterized Cloud Formation template that creates our build pipeline for any new service. Most of the time we can use the prebuilt Docker containers (maintained by AWS) for our build environment. We have one or two bespoke Docker containers for special snowflake builds.
And if you haven’t read my other posts, and I get accused of being young and inexperienced, let me just say that my first “internet based application” used the Gopher protocol....
I haven't read any of your other posts and my comments were not directed to you in particular. You're really making my point. If cloud formation templates work then great. I don't know its limitations. I do know that kubernetes has become a standard for orchestration and that it becomes easier over time to manage. A couple years ago there was no support from AWS so maybe not the time to jump in. Likewise with Kafka. Cool tech but really expensive to manage. Now AWS and Confluent will manage so the costs have come way down.
But we really don't care about the lock in boogeyman. Out of all of a typical business's risk, lock in is the least of them. We use lambda where feasible, Fargate (serverless Docker) when necessary. Why waste time doing the "undifferentiated heavy lifting"?
