Hi HN! We've built Alicorn to allow startups escape vendor lock-in with their cloud providers.<p>AWS, GCP or Azure – with Alicorn your stack runs anywhere.
Switch cloud providers in one click and never run out of free credits!<p>For a while it's been possible to build "portable" stacks that are easy to move across cloud providers. AWS, GCP and Azure nowadays are almost identical; they just don't want you to think this way. Docker, Kubernetes, functions, Redis, Postgres, Kafka, ElasticSearch – the building blocks are exactly the same. The problem is, it takes more work.<p>Alicorn does the plumbing on AWS, GCP or Azure for you – so that your stack runs anywhere. This means you are no longer tied to your cloud provider!<p>- Escape vendor lock-in – switch cloud providers in one click
- Use free credits from all 3 major providers. This means 3 years free
- Deploy containers, webapps, functions, databases, storage, etc
- Get DevOps best practices out of the box, like Terraform and CI / CD
- Best in class hosted free tier with 8gb RAM - you can actually run production on it<p>Our ProductHunt launch: <a href="https://www.producthunt.com/posts/alicorn-cloud" rel="nofollow">https://www.producthunt.com/posts/alicorn-cloud</a>
I signed up for your service - two things I noticed. One, the github was authenticating with app called digger.dev by motatoes and not alicorn, the page I landed on. Also, it took me to app.digger.dev, felt like bait and switch.<p>I created an app. It has been stuck in deploying state for 9 hours now[1]<p>You can't say that I didn't give your product a fair shot. I might conclude that I have trust issues with your product.<p>Anyways, congratulation on your producthunt campaign!<p>[1] <a href="https://ibb.co/vqf3HBm" rel="nofollow">https://ibb.co/vqf3HBm</a>
Is this just a rebranding of digger?<p><a href="https://news.ycombinator.com/item?id=27905922" rel="nofollow">https://news.ycombinator.com/item?id=27905922</a>
Is it a PaaS on top of kubernetes? I mean if you want to be cloud agnostic, you can use kubernetes.<p>Having tried to build a PaaS like experience, the value proposition that you are proposing is actually a self fulfilling prophecy. Just moving containers and apps is not enough. Large scale data migration from buckets to databases is super expensive and non trivial. One of situations that is quite commons is canary migration, where they would like to run both cloud providers and slowly phase one out. That is non-trivial too. Certificates starts become invalid, the migration is also dictated by how the apps are written too.<p>Also, startup are fairly easy to acquire but very hard to monetize for the amount of effort that would go into building everything resilient. I think biggest problem is the sheer amount of permutation and combination of things.
The biggest problem with these sorts of “cloud agnostic” approaches is that one is limited to only fairly basic architectures on broadly monolithic apps. The second you want to do something more in depth or customized then this model falls apart quite quickly and you’re back to square one real fast.<p>If you really just want a basic website and that’s all you’ll ever do this might work but outside that pick a platform and build natively to get the full benefits of that platform. People like to talk about wanting to be cloud agnostic so they can switch workloads quickly etc. In practice few really do that since the pain imposed by building to the least common denominator is vastly worse than the “benefit” of mitigating some perceived “risk.”
Cool concept, but I have a couple of unanswered questions.<p>- The docs link to digger and I don't really understand what Alicorn is. Is it just a GUI for resources defined using digger?<p>- The digger docs look unfinished, e.g <a href="https://learn.digger.dev/overview/understanding-targets" rel="nofollow">https://learn.digger.dev/overview/understanding-targets</a> is missing.<p>- From my understanding, to achieve cloud-agnostic infrastructure specification, digger abstracts the individual pieces of the infrastructure to things like Components and Resources. It then uses these abstractions to generate Terraform (and k8s) files for a given cloud provider. But where is this mapping between, say, a resource and a piece of terraform config for AWS? Do I have to provide it? What's the point, then? Does digger offer some already-prepared Resources? If yes, where?<p>- Having an example setup would really help to understand.
In theory this sounds awesome but I have to say that demo was pretty underwhelming. It looks like there's a bunch of configuration that needs to be done to ensure this is set up properly, not the least of which is that the app needs to be running in a Docker container?<p>Thats a non-trivial task that I don't need to do on Heroku.<p>This seems to be targeting smaller, one off, services not full stacks? Can I deploy my whole cloud at once?<p>Not to mention no talk of how does your app connect to your database? Or caching? Or static assets? Do I need to translate paths in my apps to new domains?<p>Does it transfer my DNS listings?<p>What about auth? Does it translate Cognito to GCP or Firebase auth?<p>What about the data itself? Does it transfer my data between clouds?<p>Lots more questions than answers here.
GCP free $300 credit only work for 90 days, so not 3 years - but 2.25 years.<p>Azure free $200 credit only work for 30 days, so not 2.25 years - but 1.33 years (if you need credit instead of free 12-month services).
Do you also offer some kind of abstraction libraries when e.g. working with DynamoDB on AWS and then switching to GCP? Or would I still have to prepare my code for that?
Deploying an example backend "a-nodeapp", it fails for me with the "[Sun, 15 Aug 2021 12:58:53 GMT] unable to prepare context: path "./app/" not found" message.<p>Did someone ran into this? I'd look into it myself, but thought I'd ask first.
I suspect anyone using this is making a trade off. The downside being that by putting something in between you and the cloud provide you can only use a subset, and any problem could be in two places: the cloud or the middle layer and you have to figure out which.
Really cool, that's exactly what I would except the next generation after Heroku to look like. It's weird that Heroku is still so popular while being so expensive and with a product that hasn't improved in years..
Sounds interesting. Currently, we provide TiloDB on AWS serverless, and could also port it to GCP fairly easily. We cannot yet go to Azure, as they lack some equivalent technologies.<p>What are your thoughts on serverless?