4 ms·

Yeah Beanstalk was pretty simple and decent for it's time. I told anyone that wasn't comfortable with Cloudformation + Packer and wanted to be on AWS to use it

by jpgvm 3y ago

Yeah Beanstalk was pretty simple and decent for it's time. I told anyone that wasn't comfortable with Cloudformation + Packer and wanted to be on AWS to use it during that era. At that time things were pretty binary, you used PaaS like Beanstalk or Heroku or you were off in the wild west where there was no standards at all. People were doing immutable AMIs on ASGs at the high end and then everything down to pet AWS instances w/Capistrano or similar tools at the low end. These days things are different, containers were a big deal. If you target k8s your application is pretty portable, can be run locally in something like kind to integration test the infra components, etc. You can take it to the 3 major clouds and bring most of your ingress, secrets, volume, etc configuration with you. For me k8s has been a godsend because for once I haven't had to learn a whole new set of idioms each new place that are all equivalent but different in their own special snowflake ways.

emodendroket 3y ago
> You can take it to the 3 major clouds and bring most of your ingress, secrets, volume, etc configuration with you. How often have you seen someone actually do this, and was it ever actually as "easy" as they imagined? I feel like the advantages of "going with the flow" and using the stuff specific to the cloud environment you're in are substantial and I feel like the efforts to avoid vendor lock-in start to look insufficient once you try to actually execute most of the time.
- jpgvm 3y ago
  I have done one massive AWS + kops > GKE migration and several smaller migrations between AWS/GCP/Azure. My experience leads me to believe the main problems stem from adopting IaaS/PaaS specific stuff outside of k8s. If you aren't doing that they are very portable and even if you are if you are using standard stuff like managed PostgreSQL/MySQL then it's still easy. Where that breaks down is very vendor specific stuff, ala Spanner, queues/logs like SQS/PubSub etc. If you are using those and your architecture is tied to specific semantics of them you are in for a rough time. I personally try to avoid any and all of those. Not for vendor lock-in reasons but because I greatly dislike not being able to run everything locally in exactly the same configuration it will be deployed in. So I run PostgreSQL in k8s using Patroni, Kafka or Pulsar for queue/log, etc and that is about it usually. I generally don't need/use other things. Maybe memcached if there is a good need for it over say Caffiene (in-memory cache). This is awesome because it means it's super super easy to have staging/UAT environment or even preview environments on PRs and I can run integration tests against the whole stack E2E without spinning up/manipulating cloud provider resources.
noduerme 3y ago
One nice thing about Beanstalk was that you didn't (don't) have to deal with containers on the toolchain at all. You basically zip the directory structure you'd normally serve and it just gets rolled out to all the instances. What I figured out early (the hard way) was that it wasn't worth the time trying to screw around with leader instances that installed and ran cron jobs or anything like that. I just have an little separate ec2 instance that acts as a heartbeat for cleaning up the DB and buckets, rather than trying to get Beanstalk to do that consistently. I think it's extremely well suited for one layer, the API; and counterintuitively I find it easier not to containerize that, because it gives me more flexibility to switch DBs or storage engines without touching the API, and without having to rework a container and redeploy the API itself.

by jpgvm 3y ago

emodendroket 3y ago

> You can take it to the 3 major clouds and bring most of your ingress, secrets, volume, etc configuration with you. How often have you seen someone actually do this, and was it ever actually as "easy" as they imagined? I feel like the advantages of "going with the flow" and using the stuff specific to the cloud environment you're in are substantial and I feel like the efforts to avoid vendor lock-in start to look insufficient once you try to actually execute most of the time.

jpgvm 3y ago
I have done one massive AWS + kops > GKE migration and several smaller migrations between AWS/GCP/Azure. My experience leads me to believe the main problems stem from adopting IaaS/PaaS specific stuff outside of k8s. If you aren't doing that they are very portable and even if you are if you are using standard stuff like managed PostgreSQL/MySQL then it's still easy. Where that breaks down is very vendor specific stuff, ala Spanner, queues/logs like SQS/PubSub etc. If you are using those and your architecture is tied to specific semantics of them you are in for a rough time. I personally try to avoid any and all of those. Not for vendor lock-in reasons but because I greatly dislike not being able to run everything locally in exactly the same configuration it will be deployed in. So I run PostgreSQL in k8s using Patroni, Kafka or Pulsar for queue/log, etc and that is about it usually. I generally don't need/use other things. Maybe memcached if there is a good need for it over say Caffiene (in-memory cache). This is awesome because it means it's super super easy to have staging/UAT environment or even preview environments on PRs and I can run integration tests against the whole stack E2E without spinning up/manipulating cloud provider resources.

noduerme 3y ago

One nice thing about Beanstalk was that you didn't (don't) have to deal with containers on the toolchain at all. You basically zip the directory structure you'd normally serve and it just gets rolled out to all the instances. What I figured out early (the hard way) was that it wasn't worth the time trying to screw around with leader instances that installed and ran cron jobs or anything like that. I just have an little separate ec2 instance that acts as a heartbeat for cleaning up the DB and buckets, rather than trying to get Beanstalk to do that consistently. I think it's extremely well suited for one layer, the API; and counterintuitively I find it easier not to containerize that, because it gives me more flexibility to switch DBs or storage engines without touching the API, and without having to rework a container and redeploy the API itself.