3 ms·

Show HN: The cloud is rigged. we're building a better one

8 points by laurci 2y ago

the cloud is a walled garden built for profit [ not efficiency ]. you’re paying for idle, autoscaling is too slow, and serverless is a scam. locked in, overcharged, and out of options. lttle.cloud is different. decentralized, open-source, and built for real performance [ sub-10ms cold start ], true pay-for-what-you-use pricing, and zero vendor lock-in. deploy anything as "serverless" from any docker image, no rewrites, no bullshit. powered by the blockchain and built in public, it’s transparent, efficient, and free from vendor lock-in. run your own private cloud or join the decentralized network. more info here: https://hello.lttle.cloud https://hello.lttle.cloud the cloud game is rigged. but we can try to fix it.

aurareturn 2y ago
no bullshit. powered by the blockchain Oxymoron detected. Adding blockchain to any traditional service means 10x the cost, 10x the complexity, and 10x slower performance.
- laurci 2y ago
  =]] sometimes yes. but the blockchain is never in the hot path. it will be used only for what's designed to. align a set of nodes on the same view of the world. so, for notarization of deployments, node configuration, storage replication configuration, etc.
- laurci 2y ago
  we want to make sure that the users pay exactly what they used and that the nodes participating with compute/storage/network resources get rewards for what they contibute and can't spoof fake workload. given that we don't control the nodes that join the network, they can't be trusted so easily.
triplem1 2y ago
[flagged]
- laurci 2y ago
  the blockchain will never be in the hot path, during the execution. it will be used for notarization.
triplem59 2y ago
[flagged]
- laurci 2y ago
  the blockchain will never be in the hot path, during the execution. it will be used for notarization.
iambib 2y ago
[flagged]
SavianBoroanca 2y ago
we can easily agree on the problems: 1/ the cloud is riddled with inefficiencies -- whether you’re paying for idle resources, struggling with slow and unpredictable autoscaling, or dealing with the hidden complexities of serverless solutions. 2/ vendor lock-in is inevitable -- and the promise of seamless cloud computing remains unfulfilled. 3/ no matter the approach -- you’re locked into a costly, walled-garden ecosystem designed to maximize profit for providers rather than efficiency for users but, how can you mitigate being too dependent on others and their whim when building a new network? can you guarantee that you'll have a distributed internal network fabric that ensures fast, reliable communication between compute nodes, while maintaining security and transparency? godspeed! :-)
- laurci 2y ago
  thanks!
- laurci 2y ago
  coming back to your question, the entire cloud will be split in regions. all the nodes in a region will join a "vpn-like" network and all the traffic between them will be encrypted. there will be different kind of nodes: network, storage, compute and region controller. we will use a proof-of-stake trust mechanism. here's the basics of this: each node will need to put some money at stake to take part in the network (different amounts depending on how crucial it's role is in the network). it can take most of it back when it leaves the network. if the node underperforms or drops workload, we will issue penalties that will be removed from it's staked amount. also every workload (network, compute or storage) will be replicated across at least 2 nodes in the region (storage will be replicate outside the region too).
0x0045 2y ago
How is this different from what unikraft is doing? I fell like this approach has been tried before and didn't catch that well.
- laurci 2y ago
  i don't think it didn't catch. while unikraft (the kernel) is not a new project, the unikraft cloud is very recent (at most one year old i think). we share the same vision for eliminating the idle time costs, but the approach is quite different: - their software is closed source (we have no idea what runs those unikernels; probaly kvm) - they can run linux too, but the focus is on running their other product: the unikraft kernel - other than the cold-start performance, they have the same issues all the other main cloud providers.
doublerabbit 2y ago
Colocation for me. May cost me $5k for four servers in two different DCs. But I own the data, own the hardware and the network in between. Cloud has its purpose but what the cloud can do, I can do too.
- laurci 2y ago
  agree. but until you have enough traffic to justify this, you're eating the costs, and they are not negligible, especially for small businesses and startups. also you have to maintain the software running on these nodes, make sure you can scale with irregular traffic spikes and pack as much useful work on them as you can.
thatboyslim 2y ago
[flagged]
chatgpl 2y ago
Depending on your pricing scheme, I’d be willing to test this when I get around to building a mvp. Let me know where I can see that.
- laurci 2y ago
  thanks! the https://hello.lttle.cloud https://hello.lttle.cloud page is hosted on this runtime right now :) you can deploy it yourself if you want. however, I would give it a few months until hosting your own apps on your own nodes.
best23rhyme 2y ago
True pay-for-what-you-use pricing sounds ideal, but established cloud providers have massive economies of scale that a new decentralized network may struggle to match long-term. How can lttle.cloud remain financially viable while maintaining competitive pricing?
- laurci 2y ago
  indeed building a network to host an entire cloud's worth of apps is not easy. however, it would be even harder without the distributed approach. this way, we don't have to buy all the hosts, instead we can "rent" them from people that want to contribute to the network. during the initial phases we will distribute rewards for proof-of-availability (just being online will earn money for you). this way we can start the economy and we can have hosts join the network before we have workloads. after the initial phases, we will still reward for availability, but less. from all the payments we collect, most of it will go straight to the hosts that provided resources, and from what we take as a fee, 1/3 will go back to the availability pool, from which we will distribute to all available nodes.
p2hari 2y ago
Looks interesting. one question though. how is my data staying in a region. If I am in EU and want my data to be only in EU, how can you guarantee it?
- laurci 2y ago
  we replicate storage both in the same region (on multiple nodes) and in another close region (for redundency). a similar thing is done by aws with EBS. it's replicated in a region in a single availability zones and you pay extra if you want backups to s3 or replication in multiple availability zones.
fangg19 2y ago
when can we expect something to play with? looks great and would be really nice to get rid of the vendor lock
- laurci 2y ago
  thanks! the https://hello.lttle.cloud https://hello.lttle.cloud page is hosted on this runtime right now :) you can deploy it yourself if you want. however, I would give it a few months until hosting your own apps on your own nodes.

8 points by laurci 2y ago

aurareturn 2y ago

no bullshit. powered by the blockchain Oxymoron detected. Adding blockchain to any traditional service means 10x the cost, 10x the complexity, and 10x slower performance.

laurci 2y ago
=]] sometimes yes. but the blockchain is never in the hot path. it will be used only for what's designed to. align a set of nodes on the same view of the world. so, for notarization of deployments, node configuration, storage replication configuration, etc.
laurci 2y ago
we want to make sure that the users pay exactly what they used and that the nodes participating with compute/storage/network resources get rewards for what they contibute and can't spoof fake workload. given that we don't control the nodes that join the network, they can't be trusted so easily.

triplem1 2y ago

[flagged]

laurci 2y ago
the blockchain will never be in the hot path, during the execution. it will be used for notarization.

triplem59 2y ago

[flagged]

laurci 2y ago
the blockchain will never be in the hot path, during the execution. it will be used for notarization.

iambib 2y ago

[flagged]

SavianBoroanca 2y ago

we can easily agree on the problems: 1/ the cloud is riddled with inefficiencies -- whether you’re paying for idle resources, struggling with slow and unpredictable autoscaling, or dealing with the hidden complexities of serverless solutions. 2/ vendor lock-in is inevitable -- and the promise of seamless cloud computing remains unfulfilled. 3/ no matter the approach -- you’re locked into a costly, walled-garden ecosystem designed to maximize profit for providers rather than efficiency for users but, how can you mitigate being too dependent on others and their whim when building a new network? can you guarantee that you'll have a distributed internal network fabric that ensures fast, reliable communication between compute nodes, while maintaining security and transparency? godspeed! :-)

laurci 2y ago
thanks!
laurci 2y ago
coming back to your question, the entire cloud will be split in regions. all the nodes in a region will join a "vpn-like" network and all the traffic between them will be encrypted. there will be different kind of nodes: network, storage, compute and region controller. we will use a proof-of-stake trust mechanism. here's the basics of this: each node will need to put some money at stake to take part in the network (different amounts depending on how crucial it's role is in the network). it can take most of it back when it leaves the network. if the node underperforms or drops workload, we will issue penalties that will be removed from it's staked amount. also every workload (network, compute or storage) will be replicated across at least 2 nodes in the region (storage will be replicate outside the region too).

0x0045 2y ago

How is this different from what unikraft is doing? I fell like this approach has been tried before and didn't catch that well.

laurci 2y ago
i don't think it didn't catch. while unikraft (the kernel) is not a new project, the unikraft cloud is very recent (at most one year old i think). we share the same vision for eliminating the idle time costs, but the approach is quite different: - their software is closed source (we have no idea what runs those unikernels; probaly kvm) - they can run linux too, but the focus is on running their other product: the unikraft kernel - other than the cold-start performance, they have the same issues all the other main cloud providers.

doublerabbit 2y ago

Colocation for me. May cost me $5k for four servers in two different DCs. But I own the data, own the hardware and the network in between. Cloud has its purpose but what the cloud can do, I can do too.

laurci 2y ago
agree. but until you have enough traffic to justify this, you're eating the costs, and they are not negligible, especially for small businesses and startups. also you have to maintain the software running on these nodes, make sure you can scale with irregular traffic spikes and pack as much useful work on them as you can.

thatboyslim 2y ago

[flagged]

chatgpl 2y ago

Depending on your pricing scheme, I’d be willing to test this when I get around to building a mvp. Let me know where I can see that.

laurci 2y ago
thanks! the https://hello.lttle.cloud https://hello.lttle.cloud page is hosted on this runtime right now :) you can deploy it yourself if you want. however, I would give it a few months until hosting your own apps on your own nodes.

best23rhyme 2y ago

True pay-for-what-you-use pricing sounds ideal, but established cloud providers have massive economies of scale that a new decentralized network may struggle to match long-term. How can lttle.cloud remain financially viable while maintaining competitive pricing?

laurci 2y ago
indeed building a network to host an entire cloud's worth of apps is not easy. however, it would be even harder without the distributed approach. this way, we don't have to buy all the hosts, instead we can "rent" them from people that want to contribute to the network. during the initial phases we will distribute rewards for proof-of-availability (just being online will earn money for you). this way we can start the economy and we can have hosts join the network before we have workloads. after the initial phases, we will still reward for availability, but less. from all the payments we collect, most of it will go straight to the hosts that provided resources, and from what we take as a fee, 1/3 will go back to the availability pool, from which we will distribute to all available nodes.

p2hari 2y ago

Looks interesting. one question though. how is my data staying in a region. If I am in EU and want my data to be only in EU, how can you guarantee it?

laurci 2y ago
we replicate storage both in the same region (on multiple nodes) and in another close region (for redundency). a similar thing is done by aws with EBS. it's replicated in a region in a single availability zones and you pay extra if you want backups to s3 or replication in multiple availability zones.

fangg19 2y ago

when can we expect something to play with? looks great and would be really nice to get rid of the vendor lock

laurci 2y ago
thanks! the https://hello.lttle.cloud https://hello.lttle.cloud page is hosted on this runtime right now :) you can deploy it yourself if you want. however, I would give it a few months until hosting your own apps on your own nodes.