> Since reading the blog post's mention of Repl.it I went and downloaded their new Iphone app and used Modal.com to spin up 30-40 containers from a script doing sentiment analysis on ~30k movie reviews:

IPhone processors run billions of cycles every second and are capable of running billions of instructions every second. I'm amazed that we've gone from "Run doom on my toaster", to "I can spin up 30-40(!) containers to analyze 30k reviews".

It's laughable. Doom was written for the IBM PC. This PC had a clock speed of 4.77MHz and 64Kb of RAM. The iPhone 12 runs at 3.1GHz, has 4Gb of RAM and has multiple cores. The phone in our pocket is vastly more capable of any piece of hardware we had 30 years ago, and we give accolades to people that can analyze sentiments (which is just running a bunch of matrix math at the end of the day) in under 1 minute using dozens of insanely powerful machines.

We should be able to analyze 30K sentiments in a minute easily on an iPhone. And we should be able to analyze that data in under a few seconds on a single desktop.

> Doom was written for the IBM PC. This PC had a clock speed of 4.77MHz and 64Kb of RAM.

well, not that PC. Doom required a 386 and 4MB of RAM. But you really wanted a 486 or Pentium to run it smoothly. Catacomb 3D, a real early id Software 3D game, actually would run on an 8088 XT.

Also noteworthy, Doom was created on a NeXT computer, which was also a bit ahead of PC at the time. So there was a power differential applied to what they were creating.

Ah thank you for the correction! I should have looked this up more thoroughly beforehand :)

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.

This exactly is what Platform Engineering teams do.

Every business is unique and there isn't a universal generalisable useful solution here which is also simple. Hence why Platform teams exist.

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.

I see what you're saying, but also think it misses the point of where this is all going. An IPhone 12 is an enormously powerful computer, but it's not at all one that is accessibly programmable to Repl.it devs. Similarly, it's possible to run 30k sentiment analysis examples in a minute on a IPhone, but actually doing so would take a skilled dev weeks to implement (because it's not designed to do that!).

Our computer systems have got ludicrously more powerful, and software development has in a sense become ludicrously more inefficient, but computing is a wonderful culture of abundance and _easy and fast enough_ almost always wins over _difficult, faster, and efficient_.