Show HN: Alicorn Cloud – Easily move between AWS, GCP and Azure(alicorncloud.io)
alicorncloud.io
Show HN: Alicorn Cloud – Easily move between AWS, GCP and Azure
https://alicorncloud.io/
45 comments
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.
I created an app. It has been stuck in deploying state for 9 hours now[1]
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.
Anyways, congratulation on your producthunt campaign!
[1] https://ibb.co/vqf3HBm
I created an app. It has been stuck in deploying state for 9 hours now[1]
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.
Anyways, congratulation on your producthunt campaign!
[1] https://ibb.co/vqf3HBm
Thank you!!! Really appreciate it
Yes we did rebrand in a rush, in hindsight we needed to be more thorough
Re deployments stuck - that's not normal, what's your username? Or what did you deploy so that we can locate your project?
hey @debarshri alicorn dev here if you could use the intercom chat on the site to reach out to me with your project name I will help you out to get your stack up. Cheers!
Is this just a rebranding of digger?
https://news.ycombinator.com/item?id=27905922
https://news.ycombinator.com/item?id=27905922
Is it a PaaS on top of kubernetes? I mean if you want to be cloud agnostic, you can use kubernetes.
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.
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.
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.
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.
A bit more complex than that :) PaaS on top of K8S have a problem of serving no one - because for small cases they're too heavy and for large teams too inflexible, they could just as well use K8S directly.
Alicorn actually generates infra-as-code (Terraform) using modular "targets". By default for container it uses managed engine provided by the cloud provider which costs way less than a dedicated K8S cluster (on AWS that'd be Fargate)
But K8S is fully supported too - when you create an environment you can pick a Kubernetes target and get a cluster
Alicorn actually generates infra-as-code (Terraform) using modular "targets". By default for container it uses managed engine provided by the cloud provider which costs way less than a dedicated K8S cluster (on AWS that'd be Fargate)
But K8S is fully supported too - when you create an environment you can pick a Kubernetes target and get a cluster
re data migration: yes, that's hard. we are leaving that to the user for now - but with infra out of the way this still makes it radically easier to move. more importantly, approaches to data migration are few and established, whereas infra is bespoke effort
re monetization / permutation: we think we've solved this by having PaaS as the first step. that means we can provide defaults that we know how to handle end-to-end. the differences in modern SaaS stacks aren't that dramatic, and by making a few established patterns super easy to follow we can achieve high degree of uniformity
re monetization / permutation: we think we've solved this by having PaaS as the first step. that means we can provide defaults that we know how to handle end-to-end. the differences in modern SaaS stacks aren't that dramatic, and by making a few established patterns super easy to follow we can achieve high degree of uniformity
Look, I am not sure if you are trying to be VC backed or not. But I think you can have a decent sized business with 10 people or so. But the market is really really small and it is red ocean. There is lot of people doing the same thing, like porter.dev, quovery, etc.
When we were doing this, what we saw was the moment a company becomes serious they will decide to do all of this themselves. Companies want to own the IaC which you are taking away. Cool aspect of the platform is actually the negative thing from an enterprise point of view. I think it will impact LTV.
They want to own their own terraform script. Scripts you are generating can be written in matter of minutes by seasoned devops engineer. There is not really a moat.
When we were doing this, what we saw was the moment a company becomes serious they will decide to do all of this themselves. Companies want to own the IaC which you are taking away. Cool aspect of the platform is actually the negative thing from an enterprise point of view. I think it will impact LTV.
They want to own their own terraform script. Scripts you are generating can be written in matter of minutes by seasoned devops engineer. There is not really a moat.
Thank you! I really appreciate your take on it. Very valid concerns, and we are well aware. Here's the "map of the ocean" we were able to collate over the last few months: https://www.notion.so/diggerdev/Landscape-around-Digger-2e22...
We are indeed VC backed. And we know that it's a tough market to crack. But we also know that the opportunity is enormously large - because the right product could replace a large chunk of DevOps consulting, and from there expand into the holy grail of the "enterprise core". So worth trying.
Yes it can be written in minutes by a seasoned DevOps engineer. But access to seasoned DevOps engineers means either hiring them full-time or paying a huge consulting premium.
Yes people want to own their Terraform - and we encourage that. You can simply connect your repository with TF and Alicorn will do two-way sync.
We are indeed VC backed. And we know that it's a tough market to crack. But we also know that the opportunity is enormously large - because the right product could replace a large chunk of DevOps consulting, and from there expand into the holy grail of the "enterprise core". So worth trying.
Yes it can be written in minutes by a seasoned DevOps engineer. But access to seasoned DevOps engineers means either hiring them full-time or paying a huge consulting premium.
Yes people want to own their Terraform - and we encourage that. You can simply connect your repository with TF and Alicorn will do two-way sync.
My thought when I saw the name: alicorncloud - alicloud - alibaba cloud
Same. Are you associated with Alicloud?
Oops haven't thought of that :) No, no relation to Alibaba or anything from China for that matter.
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.
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.”
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.”
The same could be said about all the shenanigans involving cloud and being web scale.
For 95% of the companies this will never become a problem and your need to spin up a VM in another part of the world does not justify using an expensive cloud provider like AWS,GCP or Azure.
It's all very relative and depends on your operational complexity. If what you are building is working fine with VMs and you don't see negative impact on your business from operating it yourself, then sure - why fix what's not broken?
But for thousands of small businesses out there, not speaking of medium and large ones, cloud providers replace one or more full time employees who'd otherwise be busy maintaining and supporting their stacks. You can do the math. From that point of view AWS & co are dirt cheap.
But for thousands of small businesses out there, not speaking of medium and large ones, cloud providers replace one or more full time employees who'd otherwise be busy maintaining and supporting their stacks. You can do the math. From that point of view AWS & co are dirt cheap.
We believe we've cracked "the second you want to customise" problem. We offer 3 levels of customisation below the UI: config file options, Terraform overrides and entirely custom Terraform targets. So it really is fully native, not a black box. All the simplifications are completely optional - you can change whatever you want, whenever you want.
[deleted]
Cool concept, but I have a couple of unanswered questions.
- The docs link to digger and I don't really understand what Alicorn is. Is it just a GUI for resources defined using digger?
- The digger docs look unfinished, e.g https://learn.digger.dev/overview/understanding-targets is missing.
- 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?
- Having an example setup would really help to understand.
- The docs link to digger and I don't really understand what Alicorn is. Is it just a GUI for resources defined using digger?
- The digger docs look unfinished, e.g https://learn.digger.dev/overview/understanding-targets is missing.
- 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?
- Having an example setup would really help to understand.
Thank you so much for sharing this!
We launched Alicorn to focus on one thing only: multicloud. Digger value prop was less clear. Under the hood Alicorn uses same Digger engine, but adds PaaS mode as a starting point and Kubernetes to be truly cloud agnostic.
Understanding targets docs fixed- thank you for pointing that out!
The missing bit for cloud agnostic specs is targets. It's essentially a meta-template, collection of "Terraform generators" that take in higher level stack definition aka "infrastructure interface" and producing Terraform specific to a given cloud provider. You don't have to provide it, but you can customise Targets, or built entirely bespoke - it's essentially TF + basic templating on top.
Check out https://github.com/diggerhq/target-fargate as an example
We launched Alicorn to focus on one thing only: multicloud. Digger value prop was less clear. Under the hood Alicorn uses same Digger engine, but adds PaaS mode as a starting point and Kubernetes to be truly cloud agnostic.
Understanding targets docs fixed- thank you for pointing that out!
The missing bit for cloud agnostic specs is targets. It's essentially a meta-template, collection of "Terraform generators" that take in higher level stack definition aka "infrastructure interface" and producing Terraform specific to a given cloud provider. You don't have to provide it, but you can customise Targets, or built entirely bespoke - it's essentially TF + basic templating on top.
Check out https://github.com/diggerhq/target-fargate as an example
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?
Thats a non-trivial task that I don't need to do on Heroku.
This seems to be targeting smaller, one off, services not full stacks? Can I deploy my whole cloud at once?
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?
Does it transfer my DNS listings?
What about auth? Does it translate Cognito to GCP or Firebase auth?
What about the data itself? Does it transfer my data between clouds?
Lots more questions than answers here.
Thats a non-trivial task that I don't need to do on Heroku.
This seems to be targeting smaller, one off, services not full stacks? Can I deploy my whole cloud at once?
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?
Does it transfer my DNS listings?
What about auth? Does it translate Cognito to GCP or Firebase auth?
What about the data itself? Does it transfer my data between clouds?
Lots more questions than answers here.
Thank you so much for sharing this feedback! Super helpful.
It is actually for full stacks, not individual services. The demo isn't doing a great job showing it indeed.
Re Docker - yes, we don't believe there's any practical reason running backend code without containers in 2021, unless it's serverless functions. It's easy to dockerize pretty much any app, takes minutes and makes your code portable, container registry becomes your artifact store, easy rollbacks, consistency etc.
Connection to DB is done via env variables, automatically mapped from Terraform outputs. Secrets are stored in AWS parameter store or equivalent.
Static assets go to block storage (like s3) and served via cdn (like Cloudfront)
DNS / domains: each service gets its own unique URL in every environment via managed DNS (on AWS it's route53). You can also connect your own domain.
Auth - we don't support that yet, on the roadmap for Q4.
Data transfer - no, that's left to the user. We don't anticipate people doing migrations too often though - we just make the infrastructure part simple.
Thanks again for asking these questions!
It is actually for full stacks, not individual services. The demo isn't doing a great job showing it indeed.
Re Docker - yes, we don't believe there's any practical reason running backend code without containers in 2021, unless it's serverless functions. It's easy to dockerize pretty much any app, takes minutes and makes your code portable, container registry becomes your artifact store, easy rollbacks, consistency etc.
Connection to DB is done via env variables, automatically mapped from Terraform outputs. Secrets are stored in AWS parameter store or equivalent.
Static assets go to block storage (like s3) and served via cdn (like Cloudfront)
DNS / domains: each service gets its own unique URL in every environment via managed DNS (on AWS it's route53). You can also connect your own domain.
Auth - we don't support that yet, on the roadmap for Q4.
Data transfer - no, that's left to the user. We don't anticipate people doing migrations too often though - we just make the infrastructure part simple.
Thanks again for asking these questions!
GCP free $300 credit only work for 90 days, so not 3 years - but 2.25 years.
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).
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).
Startups that go through an incubator or that are seed/VC funded typically qualify more free credits. The CSPs offer this in the hope that as the company grows so does their cloud spend. Couple that with the fact that it becomes harder to switch and they more than make up for the initial free credit that was fronted.
Alicorn seems to sidestep the incentive model for CSPs entirely, I wonder if they'll add a clause to their free credit programs.
Alicorn seems to sidestep the incentive model for CSPs entirely, I wonder if they'll add a clause to their free credit programs.
That's exactly what we are aiming at :) We're essentially creating liquidity and making cloud resource a commodity.
Well... These are amounts for individuals. AWS Activate offers $100k to startups and that's just the advertised amount, $200-300k offers are not uncommon. Google and Microsoft do the exact same thing. They compete to lock you in.
The math really starts working when your cloud bill is $5-10k a month or more. Then you can either foot the bill or hire an extra engineer. There are thousands of startups who'd much prefer to hire another engineer instead.
The math really starts working when your cloud bill is $5-10k a month or more. Then you can either foot the bill or hire an extra engineer. There are thousands of startups who'd much prefer to hire another engineer instead.
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?
Things like Dynamo are AWS-specific, it is their way of locking you in. You could use MongoDB or Cassandra (which is right depends on what you use it for) that would work in any cloud provider. Moreover, for 90% of use cases the capabilities of good old PostgreSQL are more than sufficient, even if you store JSON in it and use it like a document DB.
Try Alternator from ScyllaDB to break that lock :)
Thanks for the shout-out Miles!
Yes, for folks who do not know, you can use Scylla, a NoSQL database that has a DynamoDB-compatible API, to deploy to other clouds (GCP) or even on-premises. It's been running in production for some years now. Here's the blog when we announced it, and there's more to be found on ScyllaDB.com — just search for "Alternator."
https://www.scylladb.com/2019/09/11/scylla-alternator-the-op...
Yes, for folks who do not know, you can use Scylla, a NoSQL database that has a DynamoDB-compatible API, to deploy to other clouds (GCP) or even on-premises. It's been running in production for some years now. Here's the blog when we announced it, and there's more to be found on ScyllaDB.com — just search for "Alternator."
https://www.scylladb.com/2019/09/11/scylla-alternator-the-op...
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.
Did someone ran into this? I'd look into it myself, but thought I'd ask first.
Did someone ran into this? I'd look into it myself, but thought I'd ask first.
Thanks for sharing this!! Could you ping us an Intercom message (the button at the bottom-right)? This way we'll be able to look into your project ID
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.
Very valid concern. But we think we cracked this.
Alicorn uses Terraform under the hood and allows you to customise it however you like. You can think of it as "CI for infrastructure" with meaningful defaults. 90% of the most common tasks are automated, but at the same time it's not a black box, you still have full access to native for the remaining 10%
Alicorn uses Terraform under the hood and allows you to customise it however you like. You can think of it as "CI for infrastructure" with meaningful defaults. 90% of the most common tasks are automated, but at the same time it's not a black box, you still have full access to native for the remaining 10%
This might have been great for transition for backend for my sendsimple.app thanks for sharing
We'd be happy to help with moving - ping me at [email protected]
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..
Yeah PaaS like Vercel and Heroku have an inherent limitation - at some point you need to move off them because the industry has moved on and you can only do so much without things like infra-as-code and kubernetes that became industry standard.
At the same time, simplicity is needed more then ever - k8s is cool but now people are spending crazy amounts of time and money to set up the devops goodness to run simple apps
So we thought, why not have both simplicity and power? We're just making the deeper layers of configuration optional, but still accessible.
At the same time, simplicity is needed more then ever - k8s is cool but now people are spending crazy amounts of time and money to set up the devops goodness to run simple apps
So we thought, why not have both simplicity and power? We're just making the deeper layers of configuration optional, but still accessible.
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.
What are your thoughts on serverless?
What are your thoughts on serverless?
We support Serverless too - Alicorn has a concept of Targets which are essentially different ways to run your backend code. You can mix & match Serverless, standalone containers and K8S.
Under the hood Alicorn generates Terraform, which you can also customise. So you get a proper DevOps setup out of the box with the convenienc of Serverless but way more power if you need it
Under the hood Alicorn generates Terraform, which you can also customise. So you get a proper DevOps setup out of the box with the convenienc of Serverless but way more power if you need it
AWS, GCP or Azure – with Alicorn your stack runs anywhere. Switch cloud providers in one click and never run out of free credits!
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.
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!
- 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
Our ProductHunt launch: https://www.producthunt.com/posts/alicorn-cloud