Fork me on GitHub
Martynas Maciulevičius05:05:19

Hey. I have no experience with AWS and currently have my app on Heroku. Why is it so complicated? Is there a basic way to do it? For my development I use docker-compose and I found that I could simply use that to deploy my containers. But even then it's too overwhelming... what do I even choose...?


AWS lightsail is one option to get started. Could you be more specific about what exactly have you tried or looked at ?

Martynas Maciulevičius08:05:06

What I expect is to somehow spin up a couple of docker containers that would see each other (as in a docker network) and then I'd to route network traffic between all of them but I don't yet know how it will work. Also instance names, abbreviations, pricing... Thanks, I'll try to look at lightsail. Maybe they offer to load some containers and could somehow work. I'll try to watch this vid:


Yeah, AWS can be used for what you want to do (you'll need a VPC, ECS cluster with Fargate instances running your apps, all communicating via Application Load Balancer, there's more to it though), but I'd say that unless you're building a business or work at one that uses AWS, pick something more suitable for small projects like or


the whole "how do I run a container image in AWS" thing has become a meme of sorts:

Martynas Maciulevičius17:05:57

I spent today mostly researching how to run containers there and Lightsail works similar to as Heroku does but then I'll need to move away from it into either Kubernetes or Terraform. And in Lightsail I'll be able to have containers that see each other but then I'd need to deploy each container by hand. And I lean towards using ECS (not sure how yet) with Kubernetes. I don't yet know what I'll need to configure but I think that's the setup that I'll need. Are there any things that I should consider in favor of Terraform? I had this guide but it seems that it doesn't actually compare anything: It says that TF can deploy across clouds but so does Kubernetes. So it almost seems as it's comparing two kinds of apples and with Terraform I'd need to bother with running my own node state DB and Kubernetes has its etcd. So I think Kubernetes is simpler here, at least by having less parts that I need to think about. But yes, if I'll need to migrate across cloud providers then I'll need to export that etcd data. I think that is too much thinking.


Terraform and Kubernetes are two different things - one is a generic tool for managing cloud infrastructure, the second is a container orchestrator that happens to be able to manage cloud infrastructure


I'd go with Terraform and use free Terraform Cloud for state storage, forget about K8S and use AWS services like ECS and Fargate (and VPC and IAM and ALB and Security Groups and CloudWatch and whatever data stores you have to use). Very unlikely you'll be moving clouds (says the guy how migrated a system from AWS -> GCP -> AWS 🤷) and the perceived lock-in and working around it are a bit of a straw man: yes you can use K8S everywhere but that's about it: networking, IAM and APIs work differently across clouds so you'll have to learn things anyway, there's no "lift and shift" strategy once you reach a certain level of complexity. My 2 cents of course

Martynas Maciulevičius17:05:08

Can you add to pros and cons of Kubernetes and Terraform? I'm not yet sure how to compare them. What I expect from it is that I'll have a stateful (maybe several-node Raft) cluster and maybe be able to even replicate it in the future. If I understand correctly in K8S I could do it with pods as each pod would be a small "printable" cluster. Because I won't be able to scale horizontally by simply adding more nodes. I'll have a stateful node and it will be more complicated.


I never used Kubernetes in anger but played with it every now and then. I have operational experience of running things on ECS (with Fargate too) and from how things work - you still need to orchestrate some resources with Terraform to get a functional cluster, so at this point why bother with having two systems managing different parts. It just adds complextity, with Terraform you can define everything including your services and tasks in one place, and let AWS take care of the rest. You really don't want to run K8S yourself unless it's a learning/hobby project, otherwise - just leverage managed services as much as possible and save yourself some time

Martynas Maciulevičius17:05:41

Oh, so then I misunderstood how ECS works. Because I thought that ECS would basically give me a Kubernetes cluster where I could simply deploy directly from kubectl. I thought that it was that basic. Some of the tutorials were using aws ECS directly and others were using minikube which is a local single-node kubernetes install. So that's what I wanted - try it out locally and then run it on the real thing.


ah I see the confusion


ECS and EKS are different services, that do the same thing


ECS: managed container orchestrator from AWS, done their way (predates K8S if I remember correctly) EKS: managed K8S offered by AWS: you get the control plane and whatever else it needs Then you have the nodes that actually run your container instances - that can be EC2 or Fargate, you can use either compute types with either ECS or EKS. All of that needs to be created and managed somehow, this is where Terraform comes into play. Or you setup stuff in the AWS console 😉

Martynas Maciulevičius17:05:34

Yeah, I found one vid too: So why is Terraform going to be easier? Because I saw in one tutorial about Kubernetes that I can rollback to a previous service or it can even rollback by itself if something fails. And this comparison says that there is no rollback in Terraform: > No rollback - if the need arises, the user must destroy the managed object and re-apply it. This is kind of bad because if my nodes are stateful yes, I'll have my state in my "colder" storage and some in MQ but it's not an instant reboot. I can't do an immediate reboot (also I'm lazy to do graalvm). So this means that with Terraform it can get unpredictable. If I understand correctly Terraform is focused more on the preparation of the machines themselves (VM, hypervisor things and so on). But if I use EKS instead then I won't need to bother about machine types. Is that correct?


No, Terraform doesn't prepare anything for you - that's a job for Packer. I suggest reading about the tools themselves directly from the source, not comparison articles: You can rollback changes with ECS just fine, it only depends on how you manage your container images and their tags, nothing to do with Terraform per-se.

Martynas Maciulevičius17:05:51

What I didn't think about was that I'll need to choose a database and set up that by hand in the GUI. And then I'll forget what I configured. That I may not be able to do in Kubernetes or then I'll need to deploy my own DB and handle it myself. That would actually be bad. So would this be the main difference?


That's my point: with Terraform you can set up all of that, using infrastructure as code, no manual setup (as in: in AWS console) required. Not sure if K8S can manage AWS resources (it probably can, given how extensible it is)

Martynas Maciulevičius13:05:37

Is it possible to create a terraform config for aws and run it locally as if it would be a dev topology? I like how I can do it with docker-compose and I wanted this kind of workflow. Is there a way? Or is it then coupled to AWS? Edit: Not possible.


No, that's not possible - you can open an account and use the free tier, but you'll be eventually charged. Even Terraform's own tests assume that and incur cost. AWS might be giving some educational credits but I know next to nothing about this

Martynas Maciulevičius16:05:55

Alright. Well that's probably fine.