It's the configuration complexity clock all over again. Code errors cause outages, then we impose a bunch of process and restrictions on code deployment, then we make our code configurable so that business users can easily change the behaviour, then configuration errors cause outages.

The referenced article on Python in banking: https://news.ycombinator.com/item?id=29104047&p=2

> none of the tradeoffs of using a general purpose program language were discussed.

Yep. And particularly the fundamental issue of so-called "general purpose" programming languages:

  They are *not*, in fact, general purpose.

What we call general purpose languages are, in fact, DSLs for the domain of algorithms. See ALGOL, the ALGOrithmic Language. But we think they are general purpose, because that's what we use, lacking other options. And this mistaken categorisation leads us to the incorrect conclusion that things that aren't handled well by these "GPLs" must therefore be handled by DSLs. Or Domain Specific Tooling.

Which in turn leads to the problems described in the article, because it's all far too domain specific.

The answer, IMHO, is to make languages that actually are general purpose and not just algorithm-DSLs. That can handle integration without being integration-DSLs.

My stab at this is http://objective.st/

How do you get time/instances on an no code platform?

This problem was solved in 80ies on most timeshare platforms(read unix) where you would simply let users access an general purpose environment on a shared server and run processes in the background or kick up batch job using some kind of scheduler(crontab).

The old unix "shell account" should really be the benchmark for FaaS to beat and so far i dont think anyone have gotten close for small scale project.

On SaaS providers where Cloud Shell is the new telnet and the browser the X Windows replacement.

Which providers?

My experience is that my first cgi-bin script were about a order of magnitude easier to deploy that anything other then say a traditional php/mysql script. and i had the flexibility to use basically any programming language back then too.

I did not have to learn git, figure out how the cloud router used worked, i just had to place a file in a directory. For crontab it was the same dump the script to a directory edit the crontab file and it worked and it was the same no matter who i bought the service from.

Sure there were scalability issues, and the security was questionable but in terms of ease of use are we really moving forward?

Since you gave a cgi-bin script as example, assuming you have an Azure Cloud account, you can easily do it via , provided it is written in JavaScript, PowerShell, TypeScript, or C# Script.

https://docs.microsoft.com/en-us/azure/azure-functions/funct...

Here is video tutorial

https://www.youtube.com/watch?v=1A7vp3zAB9U

Or in the context of low code tools, Azure Logic Apps

https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps...

And this is the equivalent for cgi-bin "vi ~/public_html/cgi-bin/hello.sh"

And the code itself did not contain 10 lines of vendor specific scaffolding to run either but were straigt onto the business logic.

Where is the platform where i can take an completely standardized scriptfile use my preffered ftp/scp client and upload it into an runtime configured to run inside of the corporate firewall?

You are missing having IT set up a UNIX server instance, with Apache or NGINX on it, configure firewall, public IP DNS entry, and then having the rights to ftp/scp into it before being able to call vi into hello.sh.

So if you want that approach then, IT would set an "static HTML web app" instance for "~/public_html" version, which you can then ssh into.

https://docs.microsoft.com/en-us/azure/app-service/configure...

or have a VSCode like experience editing directly your site files,

https://social.technet.microsoft.com/wiki/contents/articles/...

I feel like you must know this, but the convention back in the day was a UNIX server for an organization, that would handle essential tasks like email, that everyone could log in to and have access to common UNIX tools, and that would automatically serve "/home/$USER/public_html" as static HTML web apps under example.com/~$USER.

So, IT sets the server up once and maintains it and provisions and deprovisions accounts, but everything else is self service. There's no need for IT to be involved when somebody wants to "launch a new web page". It was a pretty nice system for what it was.

Sure and I get from where you are coming, but those days are long gone, in fact by 2004 that wasn't a thing at Nokia any longer.

But is the new way better for all usecases?

From security point of view, yes.

yes but if that's the only way it's approved there is a huge unfilled gap in the current market.

Besides given the near constant issues we see around misconfigured s3 bucket i am not sure the average cloud function meets security standard anyway.