I wish CDK was fully baked enough to actually use. It's still missing coverage for some AWS services (sometimes you have to do things in cloudformation, which sucks) and integrating existing infra doesn't work consistently. Oh and it creates cloudformation stacks behind the scenes and makes for troubleshooting hell.
You could certainly implement Kamal just with Ansible and Docker Compose. It's just an abstraction that does it for you and handles all the edge-cases. (Kamal doesn't use Ansible, it has its own SSH lib).
Plain Podman systemd integration is way more powerful and secure, as it does not mess with firewall and allows to run rootless containers using services. It's even possible to run healthchecks and enforce building images just before starting service making on-demand containers using systemd-proxyd possible. Check example: https://github.com/Mati365/hetzner-podman-bunjs-deploy
It looks like you don't even care about opening documentation before pressing reply. Podman is a simple hammer without any moving parts, that used properly can be used to build fancy stuff without much knowledge.
Keep an eye on reachability and performance. I’ve seen DO consistently perform terribly and/or drop connections for months (that is, didn’t look like some brief routing glitch somewhere) for some US and Canadian routes (not, like, Sri Lanka or something) on excellent Internet connections. The fix was moving to AWS, problem gone. It felt like a shitty-peering-agreements issue.
What's your issue with EKS? I operate several very simple and small single-tenant clusters, and I have to touch the infrastructure only once a year for updates
You don't choose EKS because it's easy to manage. You choose it because you intend to use the bevy of other AWS hosted services. The clusterfuck of management is directly related to that.
The alternative, which I feel is far too common (and I say this as someone who directly benefits from it): You choose AWS because it's a "Safe" choice and your incubator gets you a bunch of free credits for a year or two. You pay nothing for compute for the first year, but instead pay a devops guy a bunch to do all the setup - In the end it's about a wash because you have to pay a devops guy to handle your CI and deploy anyway, you're just paying a little more in the latter.
I wish CDK was fully baked enough to actually use. It's still missing coverage for some AWS services (sometimes you have to do things in cloudformation, which sucks) and integrating existing infra doesn't work consistently. Oh and it creates cloudformation stacks behind the scenes and makes for troubleshooting hell.
Kubernetes no thanks. Terraform + Kamal [1] on Digital Ocean is the way I deploy/run apps now.
[1] https://kamal-deploy.org/
I've looked into Kamal but it feels so "It's as complex as Kubernetes but isn't so support is going to be nightmarish."
Why is this better then Ansible + Docker Compose?
You could certainly implement Kamal just with Ansible and Docker Compose. It's just an abstraction that does it for you and handles all the edge-cases. (Kamal doesn't use Ansible, it has its own SSH lib).
Plain Podman systemd integration is way more powerful and secure, as it does not mess with firewall and allows to run rootless containers using services. It's even possible to run healthchecks and enforce building images just before starting service making on-demand containers using systemd-proxyd possible. Check example: https://github.com/Mati365/hetzner-podman-bunjs-deploy
> way more powerful and secure
I don't care about powerful. That's the opposite of what I want. I could just use k8s if I cared about that.
It looks like you don't even care about opening documentation before pressing reply. Podman is a simple hammer without any moving parts, that used properly can be used to build fancy stuff without much knowledge.
I'm aware of what Podman and Systemd are. Apparently you are not aware of what Kamal is. Open documentation, then press reply.
Does it support zero downtime deploys?
Why not? Install trafeik or any other load balancer, setup two services, and restart one after one.
Kamal is simply NIH K8s made by an unreliable company with poor leadership. No thanks, not for my prod infra!
Hi everyone,
We've gone through a lot of pain to get this blueprint working since our AWS costs were getting out of hand but we didn't want to part ways with CDK.
We've now got the same stack structure going with Pulumi and Digital ocean, having the same ease of development with at least 60% cost reduction.
Keep an eye on reachability and performance. I’ve seen DO consistently perform terribly and/or drop connections for months (that is, didn’t look like some brief routing glitch somewhere) for some US and Canadian routes (not, like, Sri Lanka or something) on excellent Internet connections. The fix was moving to AWS, problem gone. It felt like a shitty-peering-agreements issue.
People will pretend that this quality difference doesn’t exist in networking, uptime, server quality.
It’s not a drop in replacement. It might be worth it depending on what you’re doing.
Frustratingly, it’s also something that doesn’t meaningfully appear on any features list or comparison sheet.
Pulumi is very neat with straight AWS, too. I suspect this is the primary use case.
Anyone use Garnix? https://garnix.io/
This looks too experimental for me to trust with production deployments.
EKS has become a clusterf*ck to manage and provision. This looks very useful. Bare metal k8s, even running on EC2, might be another option.
What's your issue with EKS? I operate several very simple and small single-tenant clusters, and I have to touch the infrastructure only once a year for updates
You don't choose EKS because it's easy to manage. You choose it because you intend to use the bevy of other AWS hosted services. The clusterfuck of management is directly related to that.
The alternative, which I feel is far too common (and I say this as someone who directly benefits from it): You choose AWS because it's a "Safe" choice and your incubator gets you a bunch of free credits for a year or two. You pay nothing for compute for the first year, but instead pay a devops guy a bunch to do all the setup - In the end it's about a wash because you have to pay a devops guy to handle your CI and deploy anyway, you're just paying a little more in the latter.