Back to the '70s with Serverless

I haven't worked with an API that uses XML in a long time, but does it express the difference between "0123" and 123 well? I think that it either doesn't, or you add some really awkward schema language with XML namespaces ...

I just translated my .travis.yml to JSON, and I learned that

    deploy:
      on:
        branch: master

Also, all of the languages are often used with say Go templates, which makes them more unstructured. They're no longer statically parsable, which is "table stakes" for doing anything else (validation or static analysis).

I took some pains to make shell statically parsable [2], and I think it's now a better foundation than these config languages, per my other comment here: https://news.ycombinator.com/item?id=25483270

I think HCL is probably a lot better, but it also seems to be the least used! It's structured, and has its own mechanism for expressing duplication that's not the equivalent of a 70's-style #include.

[1] https://github.com/oilshell/oil/blob/master/.travis.yml

[2] http://www.oilshell.org/blog/2019/02/07.html

https://faq.nearlyfreespeech.net/q/ResourceAccountUnit

So basically if your website doesn't get any hits, you don't get charged.

This is the best description of modern software development I have ever seen.

> It seems that, contrary to what everybody is saying, software developers are in plentiful and cheap supply so wasting a lot of their talent makes economic sense over the perceived cost of adapting more powerful programming systems.

> but we just throw more bodies at the problem because Gartner tells us this is the future.

This last part is the real reason for it: executives are blind morons who have no idea how to run technology-dependent companies, and their poor leadership bleeds down because hierarchical organization.

I used to blame executives because it seemed like they were making terrible decisions that everybody knew were terrible. But now I realize that the reason they're making the terrible decisions is they just have absolutely no concept of how the organization should run. They don't understand the customer, the employee, or the product, but they have generic ideas of how to make generic things, so they just do that and hope the people under them will fix everything.

So of course we're managing everything as tiny little components that get glued together. They're "Fordisming". And "Globalizing" is already here too. Many companies already have one microservice made in India, another in Romania, a third in Spain. Who cares if they barely talk? Who cares if they reinvent the wheel and use conflicting technology? It's all just a game of "reduce cost and increase profit".

The next big hotness is going to be the API-gateway-service-mesh-distributed-tracing monolith that every service will be plugged into. Developers will be given more power to turn on and off things that are connected to this monolithic service frontend. They will thus be able to have faster feedback, but nobody will be coordinating the changes they are making, so actually things will break more often due to conflicting changes.

Finally, some time after that, the developers will figure out that it would be better if, instead of depending on all the external Infrastructure/Configuration-as-Code, they should be using frameworks that have everything built into them, and have their application tell the framework what to do, so a dedicated person won't need to write it all using external tools and weird DSLs. This will persist as a sort of "Java framework for Kubernetes-native Applications", although it'll extend into all the thousands of shitty extension apps that plug all the holes in K8s. And then we'll truly have a new monolith, but a distributed one.

As an indie, lone dev, I can run my site, email and a basic web app for about 10 USD a month and, if my app kicks off, I can scale it to a million users without breaking a sweat.

To me, that is the true power of the modern cloud computing paradigm. An influx of great apps and services enabled by cheap scalable and sweet competitive cloud services.

Was this even possible in 2000?