I think related to the article, this would fall under the lift and shift concept the author described.
What the author really wants is a transformative experience around developing in a way that is cloud native.
So don’t apt install packages on your alternative iPhone which has a Linux container option built into the OS.
Instead, tap a few buttons to say you are developing a webapp with a node backend, Postgres db, and redis instance and code anywhere you go without thinking of setting up an environment. Don’t even think of how to connect to your db. The tool knows you want your service to connect to it and knows not to let anyone else connect except for exceptional case debugging. And once you are done with your v0.0.1, you press deploy, wizard your way through, and it’s out on the internet without you having to think about it further. (And for bonus points, everything including the platform config is quietly getting committed to a git repo in the background so you get all the advantages of IAC by default in the event you need it). And you don’t think about scaling or deployment resources or anything like that. It just happens and you go on about your business (hopefully with some thought given to billing). And when you want to connect a service to another one you don’t think of concepts of ip blocks or auth or certificates. Service A communicates with the world and service B. The dev experience is that you call service B from service A and all the auth and TLS and ip addressing and name spacing is handled in the background. The dev experience is you call service B and that’s it. And that deploys 1:1 to production as well.
Even the above scenario feels somewhat uncreative like it only imagines a few steps up from what we have instead of a paradigm shift. But basically it’s not about shifting to different platforms like iOS or remote dev machines. It’s about an experience of development that is tied in deeply with the environment you ship to and in a way that completely frees you of thinking of low level concepts which all happen in the background.
But this forces architectures that may be problematic for certain use cases. Cookie cutter solutions will always end up getting bogged down with more and more options. And options for options.
I hear you. I’ve been lucky to work on dev experience in a platform team so I do agree that this is a platform teams job. I wonder though as our stacks mature and things normalize, if there’s a chance to do some thinking and organize systems from first principles to create a platform that suits the vast majority of app development. If a team outgrows it, maybe that’s a call for a platform team.
I’m trying to imagine though what a platform team might look like in a world like that. A lot of dev ops teams today work around cloud configs and terraform for example instead of bash scripts and hardware. Maybe platform teams of the future think of plugins and modules for these imagined systems instead of building on top of a lot of low level stuff.
What the author really wants is a transformative experience around developing in a way that is cloud native.
So don’t apt install packages on your alternative iPhone which has a Linux container option built into the OS.
Instead, tap a few buttons to say you are developing a webapp with a node backend, Postgres db, and redis instance and code anywhere you go without thinking of setting up an environment. Don’t even think of how to connect to your db. The tool knows you want your service to connect to it and knows not to let anyone else connect except for exceptional case debugging. And once you are done with your v0.0.1, you press deploy, wizard your way through, and it’s out on the internet without you having to think about it further. (And for bonus points, everything including the platform config is quietly getting committed to a git repo in the background so you get all the advantages of IAC by default in the event you need it). And you don’t think about scaling or deployment resources or anything like that. It just happens and you go on about your business (hopefully with some thought given to billing). And when you want to connect a service to another one you don’t think of concepts of ip blocks or auth or certificates. Service A communicates with the world and service B. The dev experience is that you call service B from service A and all the auth and TLS and ip addressing and name spacing is handled in the background. The dev experience is you call service B and that’s it. And that deploys 1:1 to production as well.
Even the above scenario feels somewhat uncreative like it only imagines a few steps up from what we have instead of a paradigm shift. But basically it’s not about shifting to different platforms like iOS or remote dev machines. It’s about an experience of development that is tied in deeply with the environment you ship to and in a way that completely frees you of thinking of low level concepts which all happen in the background.