Honestly I never understood why Docker stopped at where it's at.
Imagine a world where a "docker push aws.io production" leads to an automatically updated docker remote, and where the endpoint is automatically NATed, scaled and shutdown if not needed anymore.
Could have been so convenient. Instead there's this pile of networking glue code that's so custom for each platform that nobody wants to deal with load balancers.
In my opinion the biggest "innovation" in the cloud space was heroku back then, where code deployment was fully integrated to the dev workflow via git.
The issue I had with the EC2 deployment workflow was that it needed the AWS CLI configured, so it relied totally on AWS'es locked in workflow.
I was thinking more of the lines as a standard API/set of protocols that works on the NAT-scale automatically.
Humans are bad at guessing resources, and having people tweak all their VMs all the time with crappy code and crappy APIs is kinda the weakness of all dyno based workflows nowadays.
All the "web scale" jokes have a core truth in them, and are actually not so funny for a reason :-/
But relying on a standard set of NAT rules and relationships, which the Dockerfile already provides, could make this an advantage instead.
Cloud is difficult because it stiched together from fragments of old applications and approaches.
Cloud will be easy with consistent approach. One or very few languages for everything, from configuring resources, to configuring policies and writing code.
Cloud will be easy with opinionated tooling. No Dockerfile and supporting of miriads languages. Just file with dependencies and folder with source code.
Cloud will be easy with opinionated approach to configuration. No need to support PASSWORD env, PASSWORD_FILE env, some secret access service. Only one secure and simple way.
Basically rebuild cloud from the ground up. Remove Linux from equation, we don't need it. Remove filesystem from equation. You have a source code which executex somewhere. You can declare that your service needs database and it'll get it. You can declare that your service needs to access another service and you'll be able to use API to access another service, without thinking about URLS, auth tokens and all this nonsense. Just RPC.
Lambdas are good idea, but very convoluted. Lots of abstractions over abstractions. Terraform which calls AWS API.
Things could be so much simpler and faster. There's nothing that prevents you from redeploying your service in microsecond, just as you hit "Save" button in vscode.
It might have better chances with some common language runtime, than declaring One True Language. No matter what language you pick or invent, it's gonna be hated by many. Intermediate representations? Sure, but much less so.
But you are absolutely right that clouds need a fundamentally different runtime, built on different ideas and principles - not virtual machines running containers pretending to be functions, all completely separate from resource declarations (which are in turn all individual nuanced messes).
> Cloud will be easy with opinionated approach to configuration.
This is really true. AND in no time at all, it will turn from "easy" into "steady, reliable" and then FOMO-derived cognitive dissonance will set in for either engineers, developers, sales team, or users, or some set of those. You'll get people inviting you back to FOMO-squirrel-duct-tape-emergencies-cloud.
At that point I'm convinced you have to find a way to act like you are FOMO+ while keeping easy-cloud well-maintained, if you wish to keep the squirrel cloud difficulties at bay. If you are part of a team then I wish you the best of luck.
There’s a good chance this is realised within 5 years, built on WebAssembly.
While it’s not on the metal performance like native compilation, it’s close. I wouldn’t be surprised to see CPU instructions for WASM to get to native performance, if it got popular enough as a runtime.
Cloud applications don't need 99% of all device drivers and the desired ones need to be tuned for cloud anyways. Cloud applications need a persistent store but not necessarily a filesystem. Cloud applications don't want to think about process scheduling they want to assume they have the CPU and memory they need. etc.
You don't really need any OS to run, say, BEAM VM (just an example). Language runtime could be an OS of its own, as long as it has all the necessary primitives so you can have your concurrency, messaging and persistence in a distributed fashion. All you need is a thin HAL (or a hypervisor, e.g. consider https://data-room-software.org/erlangonxen/ - just a first result I've found searching for running BEAM on bare metal) that's just enough to support the hardware.
> Or that in order to be able to publish a message to SNS, my IAM policy must have a statement that allows the sns:Publish action on the topic's ARN.
Like, sure … it's "annoying", in a sense, to need to understand what permissions your program requires.
> Can we get rid of it?
This is the thesis the article ought to have dug into. It seems innately obvious that there is no removing the need for understanding that your program requires sns:Publish, and then writing an IAM policy to that effect. (Well … short of just removing authorization outright, but good luck convincing the security team that IAM is silly?)
AFAICT glacing at the repo, it derives the policy from the code, and proposes that as "PoLP". In a sense … "yes", it's PoLP as to what the code literally requires … but it ignores the number of times an IAM policy has been proposed to me that is trivially not PoLP in what the code should require, and you ask "what do you need these permissions for?" and first round trip is through "well, the code does $thing that requires that permission" and well, okay, but what possibly for? since you tend to know the rough design of the thing being built, and the implementing the design shouldn't require anywhere near as many perms as what are being requested … and then you suss out the bugs in the code for that.
S3 is notorious in my book for this: devs will merrily call "GetBucket" on a bucket that by design you know exists, and boto's API encourages this. (And then you have legions of devs who think S3 is slow, and … well, yes, when you make network API calls whose result is entirely discarded!)
I've seen "Publish" on a topic requested by the service that's the consumer. The bucket thing about. Requesting a permission against all resources, not a specific one.
Elad here (the author). That's a very good point. If a developer decides to use `bucket.list().filter(x => x == myFile)` instead of `bucket.get(myFile)` the result will be fundamentally different both from a security perspective (e.g. `ListObjects` instead of `GetObject` on AWS), but also from a performance perspective (`list` is O(n) but `get` is O(1)).
If you think about this is primarily an issue of software engineering quality. The fact that today we are forcing the developer to go their devops team to request these permissions creates an organizational workflow that increases quality. That's why most of the teams I worked at requires code reviews.
I believe the right approach is to enable devops teams to put up boundaries and rules that will get enforced downstream (build => deployment => production). This will allow both developers and devops teams to be be more independent but still be in control.
Let me declare permissions inside the service and not in some completely unrelated cdk repo. OpenBSD pledge style. Yes privileges should be the least necessary but effort to actually declare them should also be the least necessary.
As someone with more than a little bit of PLs: That's the wrong approach. Doing PLs is hard it's the ultimate naysayer's profession. Modern programming languages are built around a dozen or so major design decisions, or dimensions for the machine learning crowd, (that's why there are so many) - and many combinations, if not most of them, are simply incompatible. Like, you-end-up-with-undecidable-problems incompatible.
So doing a PL should focus solely on expressing computations. A different platform, even a very different platform like the cloud, does hardly justify the effort necessary to design and implement a language. In the end you won't do neither a good language nor good platform support.
Instead, develop a dialect using as much of the parent language as possible and only restrict the parts that are indeed incompatible with your goal.
> By the way all of the complaints in this post can be solved if OP uses a PaaS solution.
This statement is untrue. PaaS offerings just trade one set of problems for a maybe slightly smaller but mostly the same set of problems. I actually can't find a single complaint in the article that is solved by PaaS solutions.
If you're looking for something that fits the motivation (including "give me the developer experience of the 90s"), but uses a language you probably know already (JavaScript), check out https://www.convex.dev/.
I remember when early 2000s enterprise web development had J2EE, a convoluted mess of over-abstraction oversold by Sun, presumably so they could sell more servers. I recall a Sun consultant telling us that this was the "one true way". Meanwhile, we got the job done with PHP (albeit the kind of PHP that got written in the early 2000s could be its own convoluted mess).
Now you hear consultants telling you Kubernetes on top of whatever cloud service they are shilling is the one true way, or some other convoluted mess built on top of a Jenga tower of Cloud Formation and Terraform configuration files. JSON has replaced XML but otherwise, same old.
It is a modern alternative to Meteor, Firebase, Supabase and similar, but it should be much easier to work with, especially from React. Unlike Meteor it has a relational DB and data is accessed via server-side functions. It's got some cool properties like automatic realtime updates and ACID transactionality for any server write.
I'm not buying it(yet). Yes, cloud (especially if you want to use serverless and not pay an arm and a leg)is relatively difficult for devs used to traditional model or just new devs period. But that's what devops is for. Not just to write infrastructure as code, test and scale, but to help devs get to know cloud services. I found the source of this perceived difficulty is the vastness of documentation and the fact lots of stuff is not documented. The services themselves are fairly easy to understand in a conversation with someone who knows them well.
However, then the author complains about how long it takes to redeploy cloud infrastructure. So I'm thinking, sure. I too had cloudformation stacks that took 45min to run, but that can be resolved by not tearing all resources down and recreating, but by intelligent updates, container use and so on.
So then, we learn a solution is a new provider agnostic programming language for the cloud... But we already have terraform for python that is provider agnostic, but don't imagine you'll have the same infrastructure as code run on aws one say and gcloud the next. There will always be tweaks required per provider.
Still,personally I prefer to either use tools like ansible, terraform(for future readability) or straight python with boto(an aws specific framework). I see no need for an entire new programming language.
Pretty much, yes. An application developer should be able to focus on data model, business logic and user interface, and everything else at a minimum. If you are burning your available hours working on issues with your infrastructure - whether it's cloud or hosted or on-prem - that's not delivering business value.
As long as it's part of the required steps to delivering business value, it doesn't matter that much if it's application code or infrastructure (as code). Both are required, hence both are delivering business value.
I want a total chad Heroku at good prices, not this weak ass 0.04vCPU crap for $120/month.
Give me 8vCPU 16GB ram machine at Hetzner prices that has Heroku-like devops layer. The marginal cost of Heroku software layer should IMO get ammortized into nothingness.
I may have something for you in the works actually. A team I consult with is working on a bare-metal as a service based service offering that provides a Heroku-like experience. Storage is network-attached on a low latency network and customers can select dedicated disk pools if they want. One of the interfaces to the infra is a Heroku-like interface.
Readit News
Imagine a world where a "docker push aws.io production" leads to an automatically updated docker remote, and where the endpoint is automatically NATed, scaled and shutdown if not needed anymore.
Could have been so convenient. Instead there's this pile of networking glue code that's so custom for each platform that nobody wants to deal with load balancers.
In my opinion the biggest "innovation" in the cloud space was heroku back then, where code deployment was fully integrated to the dev workflow via git.
[0] https://docs.docker.com/cloud/ecs-integration/
I was thinking more of the lines as a standard API/set of protocols that works on the NAT-scale automatically.
Humans are bad at guessing resources, and having people tweak all their VMs all the time with crappy code and crappy APIs is kinda the weakness of all dyno based workflows nowadays.
All the "web scale" jokes have a core truth in them, and are actually not so funny for a reason :-/
But relying on a standard set of NAT rules and relationships, which the Dockerfile already provides, could make this an advantage instead.
They originally wanted to build docker swarm, which was to compete with kubernetes. Direction 360-ed after that fizzed.
Cloud will be easy with consistent approach. One or very few languages for everything, from configuring resources, to configuring policies and writing code.
Cloud will be easy with opinionated tooling. No Dockerfile and supporting of miriads languages. Just file with dependencies and folder with source code.
Cloud will be easy with opinionated approach to configuration. No need to support PASSWORD env, PASSWORD_FILE env, some secret access service. Only one secure and simple way.
Basically rebuild cloud from the ground up. Remove Linux from equation, we don't need it. Remove filesystem from equation. You have a source code which executex somewhere. You can declare that your service needs database and it'll get it. You can declare that your service needs to access another service and you'll be able to use API to access another service, without thinking about URLS, auth tokens and all this nonsense. Just RPC.
Lambdas are good idea, but very convoluted. Lots of abstractions over abstractions. Terraform which calls AWS API.
Things could be so much simpler and faster. There's nothing that prevents you from redeploying your service in microsecond, just as you hit "Save" button in vscode.
I knew someone would find some merit to my PHP + SSHFS setup someday
It might have better chances with some common language runtime, than declaring One True Language. No matter what language you pick or invent, it's gonna be hated by many. Intermediate representations? Sure, but much less so.
But you are absolutely right that clouds need a fundamentally different runtime, built on different ideas and principles - not virtual machines running containers pretending to be functions, all completely separate from resource declarations (which are in turn all individual nuanced messes).
> Cloud will be easy with opinionated tooling.
> Cloud will be easy with opinionated approach to configuration.
This is really true. AND in no time at all, it will turn from "easy" into "steady, reliable" and then FOMO-derived cognitive dissonance will set in for either engineers, developers, sales team, or users, or some set of those. You'll get people inviting you back to FOMO-squirrel-duct-tape-emergencies-cloud.
At that point I'm convinced you have to find a way to act like you are FOMO+ while keeping easy-cloud well-maintained, if you wish to keep the squirrel cloud difficulties at bay. If you are part of a team then I wish you the best of luck.
the problem is people, not tech.
the solution is taste and discipline, same as its always been.
While it’s not on the metal performance like native compilation, it’s close. I wouldn’t be surprised to see CPU instructions for WASM to get to native performance, if it got popular enough as a runtime.
Adopting a PHB-friendly name won't make the problems go away.
> There's nothing that prevents you from redeploying your service in microsecond, just as you hit "Save" button in vscode.
Yeah, we had that 20 years ago with PHP. It had its downsides too, let me tell you.
"Linux" is huge overkill for a cloud abstraction.
Cloud applications don't need 99% of all device drivers and the desired ones need to be tuned for cloud anyways. Cloud applications need a persistent store but not necessarily a filesystem. Cloud applications don't want to think about process scheduling they want to assume they have the CPU and memory they need. etc.
Deleted Comment
Linux itself might be fine as a HAL.
But at this point there might be better alternatives.
it even lets you pass the zip data as the post body when less than 50mb. otherwise it points to a zip in s3 or a container uri.
Like, sure … it's "annoying", in a sense, to need to understand what permissions your program requires.
> Can we get rid of it?
This is the thesis the article ought to have dug into. It seems innately obvious that there is no removing the need for understanding that your program requires sns:Publish, and then writing an IAM policy to that effect. (Well … short of just removing authorization outright, but good luck convincing the security team that IAM is silly?)
AFAICT glacing at the repo, it derives the policy from the code, and proposes that as "PoLP". In a sense … "yes", it's PoLP as to what the code literally requires … but it ignores the number of times an IAM policy has been proposed to me that is trivially not PoLP in what the code should require, and you ask "what do you need these permissions for?" and first round trip is through "well, the code does $thing that requires that permission" and well, okay, but what possibly for? since you tend to know the rough design of the thing being built, and the implementing the design shouldn't require anywhere near as many perms as what are being requested … and then you suss out the bugs in the code for that.
S3 is notorious in my book for this: devs will merrily call "GetBucket" on a bucket that by design you know exists, and boto's API encourages this. (And then you have legions of devs who think S3 is slow, and … well, yes, when you make network API calls whose result is entirely discarded!)
I've seen "Publish" on a topic requested by the service that's the consumer. The bucket thing about. Requesting a permission against all resources, not a specific one.
If you think about this is primarily an issue of software engineering quality. The fact that today we are forcing the developer to go their devops team to request these permissions creates an organizational workflow that increases quality. That's why most of the teams I worked at requires code reviews.
I believe the right approach is to enable devops teams to put up boundaries and rules that will get enforced downstream (build => deployment => production). This will allow both developers and devops teams to be be more independent but still be in control.
Curious what people think about winglang's compiler plugin system as a way to help streamline these boundaries (https://www.winglang.io/docs/tools/compiler-plugins).
They also have broad permissions in their own, isolated AWS account.
There are some tradeoffs, but one pro is that they don't need to request permissions from a devops teams.
So doing a PL should focus solely on expressing computations. A different platform, even a very different platform like the cloud, does hardly justify the effort necessary to design and implement a language. In the end you won't do neither a good language nor good platform support.
Instead, develop a dialect using as much of the parent language as possible and only restrict the parts that are indeed incompatible with your goal.
“Cloud” is nothing but a bunch of virtualized resources (computer, network, storage, etc) that you can manage on demand through an API.
You could write a post about “Computer, Why So Difficult?”.
By the way all of the complaints in this post can be solved if OP uses a PaaS solution.
This statement is untrue. PaaS offerings just trade one set of problems for a maybe slightly smaller but mostly the same set of problems. I actually can't find a single complaint in the article that is solved by PaaS solutions.
Now you hear consultants telling you Kubernetes on top of whatever cloud service they are shilling is the one true way, or some other convoluted mess built on top of a Jenga tower of Cloud Formation and Terraform configuration files. JSON has replaced XML but otherwise, same old.
I found only frontend related code https://github.com/get-convex , is backend somewhere there?
Meteor has all of frontend and backend Open Source.
However, then the author complains about how long it takes to redeploy cloud infrastructure. So I'm thinking, sure. I too had cloudformation stacks that took 45min to run, but that can be resolved by not tearing all resources down and recreating, but by intelligent updates, container use and so on.
So then, we learn a solution is a new provider agnostic programming language for the cloud... But we already have terraform for python that is provider agnostic, but don't imagine you'll have the same infrastructure as code run on aws one say and gcloud the next. There will always be tweaks required per provider.
Still,personally I prefer to either use tools like ansible, terraform(for future readability) or straight python with boto(an aws specific framework). I see no need for an entire new programming language.
Give me 8vCPU 16GB ram machine at Hetzner prices that has Heroku-like devops layer. The marginal cost of Heroku software layer should IMO get ammortized into nothingness.