Hi all, Igor & Mo here from Lemon. We believe that developers deserve better than what AWS UI is today. It's incomprehensible, like an airplane cockpit. Whereas Lemon is built to feel more like your phone - no manual needed.
Lemon is easy to use, like Vercel or Heroku. You can deploy containers, webapps, functions, databases, etc. Networking and permissions are automatically configured, CI / CD just works, instrumentation connected. But it's not a PaaS - it manages your AWS account, and you retain full control.
Lemon has first-class support of Terraform, so you can customise every bit. It supports multiple environments and can export Terraform to a dedicated "infrastructure repository" if you connect one. And it will pick up your custom TF from that repo too, so it's a two-way sync.
By default Lemon uses ECS Fargate to deploy your containers. Kubernetes is supported too, as well as Lambda. Static webapps go to S3 and served via CloudFront. Every environment gets independent configuration so you can have high-load production and many short-lived cost-efficient dev environments, even one per branch if you'd like.
One of our fundamental challenges was and to some extent still is to strike the right balance. On the one hand, some high-level concepts are clearly needed because it's got so complex in the last decade. But on the other hand it can't be opague, low-level access and control are still needed because no stack is the same.
We believe we got this somewhat right by combining click-ops and Terraform into one seamless experience.
Very cool! We're also considering building a mac app, that elegantly solves all the access control / compliance concerns
The downside is that in client-only arrangement state is no longer centrally managed; I wonder how do you solve that? Or do you have a "hybrid" model with some parts on the client and others on the server?
So everything is done between the client app and AWS. Under the hood it is using the AWS SDK. We don't store any keys or any of your data on our servers. So, the user has to have access keys, and they can also have their session token. We also have it setup that it can read from your .aws/credentials file, so if you have a process that automatically updates that file, the session token is also automatically updated in the app.
I really don't know what must happen before I give AWS CRUD credentials to a third party.
However, that something didn't happen by reading this website and its value proposition.
I'm saying this as, hopefully, source for inspiration. The amount of trust a third party must inspire before anyone (like me at least?) dares to delegate operation must be overwhelming.
this is probably as close as I'd get to use it, yes, with a little console that displays all the communications as a prove of good faith, welcoming anyone to spoof network and find out there are no home-calls/telemetry involved.
Agreed, I'm not a fan of AWS's online console and its UI/UX, but my distaste isn't enough to login to AWS through another site. I'd rather navigate by CLI/API before I do that.
Furthermore, I'm not really a fan of these closed-source available-for-pricing, enhancement products. They last for a few months in pre-release form, gauge that they don't have the customer numbers to justify their revenue, and then cease development.
Thanks! I couldn't agree with your second point though. You're basically dismissing the entire category of paid-for SaaS developer tools - some of which are clearly very successful. CircleCI, Datadog, Doppler to name a few. Ignoring all of them and only using open source is a very understandable personal choice, but saying that their entire model is broken seems to be a bit of an overstatement.
So a few things. First, I, like many here read your title and took a cursory look at your website, and thought you were literally making an alternative AWS console, which would be a bad idea for many reasons.
But I just looked at your site again, and you're completely misrepresenting yourself by calling yourself an alternative UI for AWS. Youre more like a Kubernetes PaaS on AWS.
There are many similar products, so I don't see a clear differentiation and your product doesn't very clean, but you could maybe possibly have something there.
But your main problem is you're completely mis-selling yourself (or perhaps you're not completely sure what you're building).
This looks cool! I spend half the day in terraform and AWS and I’m looking forward to trying this out later today.
Regardless of how that goes, it’s really nice to see a project that addresses this specific area. Way to go!
The AWS console is (at least for the popular services and API endpoints) super effective.
That said, when you’re deploying a project that has components that span almost a dozen services in AWS that can quickly become a dozen tabs just to assess the state of the project. Not very fun - looking forward to seeing how this handles that.
31 comments
[ 8.5 ms ] story [ 1414 ms ] threadLemon is easy to use, like Vercel or Heroku. You can deploy containers, webapps, functions, databases, etc. Networking and permissions are automatically configured, CI / CD just works, instrumentation connected. But it's not a PaaS - it manages your AWS account, and you retain full control.
Lemon has first-class support of Terraform, so you can customise every bit. It supports multiple environments and can export Terraform to a dedicated "infrastructure repository" if you connect one. And it will pick up your custom TF from that repo too, so it's a two-way sync.
By default Lemon uses ECS Fargate to deploy your containers. Kubernetes is supported too, as well as Lambda. Static webapps go to S3 and served via CloudFront. Every environment gets independent configuration so you can have high-load production and many short-lived cost-efficient dev environments, even one per branch if you'd like.
We've also just launched on ProductHunt: https://www.producthunt.com/posts/lemon-4
I can't imagine adopting this in the companies I've worked for, without that avenue.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
"Be respectful. Anyone sharing work is making a contribution, however modest."
"When something isn't good, you needn't pretend that it is, but don't be gratuitously negative."
https://news.ycombinator.com/showhn.html
One of our fundamental challenges was and to some extent still is to strike the right balance. On the one hand, some high-level concepts are clearly needed because it's got so complex in the last decade. But on the other hand it can't be opague, low-level access and control are still needed because no stack is the same.
We believe we got this somewhat right by combining click-ops and Terraform into one seamless experience.
The downside is that in client-only arrangement state is no longer centrally managed; I wonder how do you solve that? Or do you have a "hybrid" model with some parts on the client and others on the server?
However, that something didn't happen by reading this website and its value proposition.
I'm saying this as, hopefully, source for inspiration. The amount of trust a third party must inspire before anyone (like me at least?) dares to delegate operation must be overwhelming.
What'd be your thoughts on the following options:
- IAM role account-to-account (no credentials sharing)
- Self-hosted webapp that runs in your account
- Mac app so that creds never ever leave your laptop
this is probably as close as I'd get to use it, yes, with a little console that displays all the communications as a prove of good faith, welcoming anyone to spoof network and find out there are no home-calls/telemetry involved.
Furthermore, I'm not really a fan of these closed-source available-for-pricing, enhancement products. They last for a few months in pre-release form, gauge that they don't have the customer numbers to justify their revenue, and then cease development.
But I just looked at your site again, and you're completely misrepresenting yourself by calling yourself an alternative UI for AWS. Youre more like a Kubernetes PaaS on AWS.
There are many similar products, so I don't see a clear differentiation and your product doesn't very clean, but you could maybe possibly have something there.
But your main problem is you're completely mis-selling yourself (or perhaps you're not completely sure what you're building).
Regardless of how that goes, it’s really nice to see a project that addresses this specific area. Way to go!
The AWS console is (at least for the popular services and API endpoints) super effective.
That said, when you’re deploying a project that has components that span almost a dozen services in AWS that can quickly become a dozen tabs just to assess the state of the project. Not very fun - looking forward to seeing how this handles that.