12 ms·

Over the years, I've deployed applications using various combinations of custom RPMs, Chef, Heroku, Docker, ECS and Kubernetes. If you can, you should probably

by ekidd 8y ago

Over the years, I've deployed applications using various combinations of custom RPMs, Chef, Heroku, Docker, ECS and Kubernetes. If you can, you should probably deploy to Heroku. (Or a similar service.) It's far cheaper than spending time on devops. Just run "git push" and you're running. When I've deployed on ECS (or other "simple" orchestrators), I've found that I ultimately wound up re-inventing lots of Kubernetes features. So if you can't use Heroku, but you do know basic Docker, then it's worth considering somebody's fully-managed Kubernetes. Google's is nice. Amazon's is a considerably more work. I hear Microsoft's is still a bit sketchy. And I'd love to take a look at Digital Ocean's. But do not attempt to host your own Kubernetes if you can possibly avoid it. If you do try Kubernetes, then read a book like Kubernetes: Up & Running first. Kubernetes is not self-explanatory, but it's pretty straightforward if you're willing to spend a few days reading. Finally, don't overcomplicate it. Just use the basic stuff for as long as you can before trying to layer all sorts of other tools over it.

nickbauman 8y ago
Managed k8s or Heroku? I don't understand why people don't try to do AppEngine. It's the oldest "Serverless" platform out there and wickedly mature. If you're worried about vendor lock in (and you should be) I have deployed AppEngine apps on the F/OSS AppScale unmodified.
- ngrilly 8y ago
  > I have deployed AppEngine apps on the F/OSS AppScale unmodified. How did you manage secrets on Google App Engine?
  - nickbauman 8y ago
    In the flex environment you can inject secrets at container build time. In App Engine standard I've used a deploy wrapper around ansible vault to do it.
    - ngrilly 8y ago
      > In the flex environment you can inject secrets at container build time. Does it mean your secrets are stored in plain text in the container image? > In App Engine standard I've used a deploy wrapper around ansible vault to do it. What does the deploy wrapper do? Does it produces an app.yaml file with the secrets injected in it, after having been decrypted by Ansible Vault?
      - nickbauman 8y ago
        Q: Does it mean your secrets are stored in plain text in the container image? A: No. It means the secrets are stored as environment variables in the container. Q: What does the deploy wrapper do? A: It prompts the developer to input the ansible vault password , decrypts the vault and injects the secrets into the environment. Generally speaking, I follow the 12-factor approach: https://12factor.net/ https://12factor.net/
        ngrilly 8y ago
        What do you mean by "injecting secrets into the environment"? You mean a section in your app.yaml like this one: env_variables: DB_PASSWORD: "this is a secret" As for as I know, in the Standard and Flex environments, app.yaml is the only way to define environment variables.
- lugg 8y ago
  Why should you be concerned about vendor lock in? I haven't heard a convincing argument why vendor lock in is a problem regarding the cloud. It can be a problem, but all solutions result in you avoiding the things you went there for in the first place. There is exceptions to this obviously but I find most people worried about vendor lock in are no where near big enough to bother running multi cloud.
  - neop1x 8y ago
    because you have to agree with every change vendor make. If they double pricing, you pay twice. If they ban service type you host, you have to stop. If they make an incompatible change in some of the hosted parts, you have to adapt. If you grow too much they refuse to allocate you more resources or it is expensive for you to use them at your scale, it is difficult to migrate away. That is vendor lock in -> loss of freedom and choice.
  - nickbauman 8y ago
    neop1x has a great response. A more concrete example would be a gaming company that started out with AppEngine for its server support for the game. Once the game has a proven revenue stream, the economics of moving from AppEngine to AppScale are a critical next step to maximizing ROI. You have all the code, now you just need to host it somewhere. Can't do that with any other serverless Platform. It's important to note that AppScale is an aPaaS, and API-platform-as-a-service, where you're guaranteed a consistent API with the ability to plug in different implementations. Something even beyond your typical openness in F/OSS software, too.
yukinon 8y ago
>When I've deployed on ECS (or other "simple" orchestrators), I've found that I ultimately wound up re-inventing lots of Kubernetes features. Could you elaborate a little on this part? Our team is looking at ECS/Fargate as a possible container solution and I am curious what you felt was missing from it.
- paulddraper 8y ago
  If you're comparing to Kubernetees, "everything". But I'm using ECS and Fargate right now (orchestrated with Terraform). https://rivethealth.com https://rivethealth.com Probably the biggest thing I would like is native secrets management. "Security groups" are limited as it depends on having an AWS interface per container. ANd I don't know how much longer our time on Fargate will last. It's expensive, but more significantly there are limitations in not having access to the host. Having to install an SSH server in every docker container to be able to debug (simple things, like top) is annoying.
  - ratling 8y ago
    We nixed ECS for the same reason, no secrets through ConfigSet.
- ekidd 8y ago
  [Update: See below, many of these features have been added to ECS since the last time I touched this portion of our infrastructure.] > Could you elaborate a little on this part? Our team is looking at ECS/Fargate as a possible container solution and I am curious what you felt was missing from it. Some typical examples: - Kubernetes allows you to run a monitoring container on every single node using something called a "DaemonSet". On ECS, you'll have to build all your monitoring tools into your base image, or use cloud-init to spawn an ECS task on each machine. - You're probably going to end up writing a bunch of scripts to generate ECS task definition JSON and to update running services, and you'll need to integrate this into your CI system somehow. With Kubernetes, you can get away with "kubectl apply -f" for a fairly long time. - Kubernetes makes it relatively easy to allocate and manage persistent disk volumes. I wouldn't necessarily use them for a production database, but they're great for smaller things. - Kubernetes has autoscaling support, plus the ability to control which containers run on which types of servers. - Kubernetes has basic secret management built-in. It's nothing as nice as Vault, but it's good enough to get started. - Kubernetes has support for a whole bunch of useful minor things that would typically wind up as Terraform scripts on AWS. And so on. None of these is very hard individually, but there's a ton of things like this. So we're slowly migrating pieces of ECS infrastructure over to Kubernetes so that we can stop reinventing so many wheels. Again, for those things which can run on Heroku, either choice is overkill. And I have to admit that ECS is very reliable at the things it does. If you do decide to look at Kubernetes, I highly recommend skimming the O'Reilly books, which provide a solid overview of how it all fits together.
winrid 8y ago
For my side projects I just wrote a simple service that listens for Github events and just checks out the repo, builds it, and ssh's to the target server and runs a "stop and run" script. This way I can even put all of the configuration for the different databases in version control too. It's super dirty, but I can deploy dozens of services without issue. Monitoring is another problem, but I don't need Prometheus for this stuff. (I couldn't use Heroku cost effectively because running graph dbs and some custom stuff, but Heroku is AWESOME)
arp242 8y ago
Isn't Heroku really expensive though? I looked at it a few weeks ago and the cheapest plan was $25/month (there's also a $7 "Hobby" plan though, but that seems just for, well, hobby stuff?) I instead got a Linode VPS at $5/month, which gives me more than the $25 Heroku plan? Setting up a VPS is not very hard either – although this may depend a bit on your environment, my app compiles to a static binary – and a lot more flexible. My devops stack thus far consists of scp and tmux.
- bgorman 8y ago
  Look into Dokku, it is a free Heroku clone that you can run on a cheap VPS. I set it up last week and now all I have to do to deploy is type "git push dokku master".
  - winrid 8y ago
    Thanks! Maybe it would be worth replacing my 100 line nodejs script that does the same thing with this in the future :) (not sarcasm, if this works the same and adds more value I'd use it)
    - rorykoehler 8y ago
      Second dokku. Its essentially a 100 line node js script if u remember correctly. Nice eco system growing around it. No scaling though
  - 52-6F-62 8y ago
    I missed this comment and made a similar one up-thread. I’ll second. I’m ignorant as to whether large projects have run using it, but for smaller ones it’s useful.
  - dyeje 8y ago
    I'll second this. Have had a great experience with dokku, about as simple as Heroku.
- kbar13 8y ago
  i dont get this thinking of how $25/month is considered expensive when heroku has already figured out and abstracted away all the busy work that's required for deploying code
colechristensen 8y ago
Why don't more people just use the native machine imaging built into cloud providers? (I would actually like to know this) Building an AMI on Amazon is not difficult and if you use it you don't have to reinvent so much architecture on top of AWS (or cloud provider of your choice)
- SteveNuts 8y ago
  For us, it's much more economical to binpack multiple apps onto a VM than to run one service per VM. Also it makes it much easier to scale out particular services once they outgrow your chosen VM size.
- AaronM 8y ago
  If your application is 50 microservices, how would you manage that on ec2 instances?
  - DanielBMarkham 8y ago
    Why does the number of microservices have anything to do with where they might live? Wouldn't that be much more related to CPU load?
    - SteveNuts 8y ago
      Because you generally want to deploy them independently. If you have 50 microservices and have to run an AMI build every time that's going to significantly slow you down. With containers you generally only deploy the service that has changes to a VM that doesn't change as often.
      - DanielBMarkham 8y ago
        You want them to be independent, atomic. How they are deployed and the choice of technology you choose to couple them with? That should be driven by load -- and dynamic. The reason everybody's so hot on microservices to begin with is that we kept coupling everything all together and it became a huge mess to manage. You don't want to repeat that mistake, only at cloud scale.
yowlingcat 8y ago
Broadly agree with this. Use K8S at LastCo -- was great so long as I didn't have to manage it, but actively managing our own K8S cluster was a nightmare. Using Heroku at CurrentCo and it's a breeze. I highly recommend it. The only thing I think that could unseat it of its ilk would be Zeit, which looks very promising. I'm skeptical of all things serverless right now but Zeit looks promising and most impressively, extremely (perhaps as much as is possible) cost effective.
api 8y ago
> do not attempt to host your own Kubernetes if you can possibly avoid it. We use Google's Kubernetes and are pretty happy with it, but overall this statement bothers me. It's absolutely true. Don't get me wrong. The problem is what it says about Kubernetes as software. It tells me it's ugly and crufty and in some ways immature. Good software should not require that much babysitting.
- ummonk 8y ago
  Yes. I think Kubernetes has a lot of really useful features but it is needlessly difficult to use and administer. Unfortunately, it seems to have become the de facto standard, so everyone will be forced to deal with it the same way they have to deal with ancient Unixisms (or worse, windowsisms).
- snupples 8y ago
  The statement is bothersome because it says more about the person saying it than anything else. If your job is to manage infrastructure and you have to deal with thousands of snowflake deployments by other teams then k8s is a godsend.
  - api 8y ago
    I just hate unnecessary complexity. I am not sure if the complexity in k8s is necessary or not. Mighy be.
sonnyblarney 8y ago
"Finally, don't overcomplicate it. Just use the basic stuff for as long as you can before trying to layer all sorts of other tools over it." This is I think always the best advice for almost anything. And we all know it. And yet so often, we ... can ... not ... resist.
Thaxll 8y ago
Heroku is really a different solution, I don't know anyone at medium scale project that uses Heroku, Heroku is like the Digital Ocean compare to AWS. You can't really compare DO, Heroku with k8s and AWS, the laters are much much more powerful.
- jacques_chester 8y ago
  I work for an occasional competitor. Heroku are legit.
cdnsteve 8y ago
Was using Heroku and moved to GCP. It's almost as nice but not as dead simple. App Engine Standard is now updated for latest languages, Python 3.7, Node, etc and really good, its also pretty cost effective. Overall would recommend.
ranrotx 8y ago
I’m surprised no one has mentioned AWS ElasticBeanstalk. It supports Docker (ECS behind the scenes) and is very close to Heroku in terms functionality but with EC2 pricing.
- dsmithatx 8y ago
  Beanstalk is nice for rapid development. The problem I is that it doesn't scale for nontrivial architiched apps. I've converted failing beanstalk deployments to real orchestarators a few times.
- switch007 8y ago
  Beanstalk is a joke. You can launch a DB through EB but the docs basically state it's a bad idea (as it gets taken down when you delete your app, which you might find yourself doing if EB gets in to an unrecoverable state). So now you have to manage EB + RDS separately, which should be automated so now you need CloudFormation to add the security groups and manage the vars for the DB connection properties in your EB.
mythz 8y ago
What pain is Heroku saving you to justify being 5x more expensive than Lightsail/Digital Ocean/Linode? All websites I maintain/deploy are either built as a Docker image and published by CI on git check-in or deployed locally with a single rsync/supervisord bash script (or right-click Web Deploy for some older IIS/ASP.NET Apps). I probably have over 50 sites I'm currently hosting so using anything that much more expensive wont enter into consideration. But I'm not seeing what could justify the extra cost? especially as the cost is reoccurring, if it's some kind of effortless/magical scalability I'd rather put that additional cost towards more hardware and buy more headroom.
- sosodev 8y ago
  I agree. You can set up a Heroku like setup pretty easily. Push to GitLab to trigger your pipeline that builds your container. Now your $5 vps with docker compose and watchtower is updated.
  - fulafel 8y ago
    Sounds like you should start a Heroku competitor :) Btw watchtower seems abandoned, anyone know is there a story to it?
- nothrabannosir 8y ago
  Heroku turns a strategical liability ("I have only one employee who understands what rsync is; if he leaves I'm screwed") into a fiscal one. Any company I've ever known will always choose the latter, for anything outside of their core competency. We use Heroku heavily, and we went from 2 full time devops engineers to 0. Everything is now buttons and sliders. There are no "security patches". The CEO could log in and scale if he needed to; it's a slider. We get monitoring for free (labour free, not cost, i.e. the "good" free). Memory usage, CPU usage, HTTP status codes, logging: it's all there. We spend no time thinking about rsync or devops or any of that: we just solve the problems we're good at. Of course, everything is a matter of scale. Legend has it, Deliveroo UK only moved off Heroku after they grew so large, Heroku wasn't willing to offer them more dynos on their account. That sounds like a reasonable time to go in house. But any <100 people company.. why bother? focus on what you're good at, and let other people do devops.
Doubleslash 8y ago
Though, there is a middle ground between running vanilla Kubernetes yourself on your own hardware and tying yourself into the specifics of a cloud provider just to get managed Kubernetes. There are really good Enterprise distros like OpenShift or PKS that relieve you from the hassle of running Kubernetes and focus on using it but don't force you onto a particular platform or cloud.
pathseeker 8y ago
Why is this upvoted? It's just a bunch of rules based on no reasoning or evidence.
crgwbr 8y ago
What parts of Kube did you find yourself reinventing with ECS? It’s not the most complex microservice setup, but I run around 60 services over 3 ECS clusters and have found it pretty easy and solid at this point. Only real pain point we’ve had was the limit on Awsvpc mode service per ec2 instance—never have figured out why instances are limited to just a few NICs.
halbritt 8y ago
GKE is head and shoulders above the rest. EKS is a joke. The only people that use it are those either experimenting, or those that are forced to. AKS is pretty okay. They're definitely way ahead of EKS. They lack a few things, but they've made some pretty good strides in the last year. Kinda suffers from being part of Azure which likely reflects my personal bias.
jordanbeiber 8y ago
The thing is if you keep to the basics Nomad/consul will do the job just fine. As the fine article points out.

by ekidd 8y ago

nickbauman 8y ago

Managed k8s or Heroku? I don't understand why people don't try to do AppEngine. It's the oldest "Serverless" platform out there and wickedly mature. If you're worried about vendor lock in (and you should be) I have deployed AppEngine apps on the F/OSS AppScale unmodified.

ngrilly 8y ago
> I have deployed AppEngine apps on the F/OSS AppScale unmodified. How did you manage secrets on Google App Engine?
- nickbauman 8y ago
  In the flex environment you can inject secrets at container build time. In App Engine standard I've used a deploy wrapper around ansible vault to do it.
  - ngrilly 8y ago
    > In the flex environment you can inject secrets at container build time. Does it mean your secrets are stored in plain text in the container image? > In App Engine standard I've used a deploy wrapper around ansible vault to do it. What does the deploy wrapper do? Does it produces an app.yaml file with the secrets injected in it, after having been decrypted by Ansible Vault?
    - nickbauman 8y ago
      Q: Does it mean your secrets are stored in plain text in the container image? A: No. It means the secrets are stored as environment variables in the container. Q: What does the deploy wrapper do? A: It prompts the developer to input the ansible vault password , decrypts the vault and injects the secrets into the environment. Generally speaking, I follow the 12-factor approach: https://12factor.net/ https://12factor.net/
      - ngrilly 8y ago
        What do you mean by "injecting secrets into the environment"? You mean a section in your app.yaml like this one: env_variables: DB_PASSWORD: "this is a secret" As for as I know, in the Standard and Flex environments, app.yaml is the only way to define environment variables.
lugg 8y ago
Why should you be concerned about vendor lock in? I haven't heard a convincing argument why vendor lock in is a problem regarding the cloud. It can be a problem, but all solutions result in you avoiding the things you went there for in the first place. There is exceptions to this obviously but I find most people worried about vendor lock in are no where near big enough to bother running multi cloud.
- neop1x 8y ago
  because you have to agree with every change vendor make. If they double pricing, you pay twice. If they ban service type you host, you have to stop. If they make an incompatible change in some of the hosted parts, you have to adapt. If you grow too much they refuse to allocate you more resources or it is expensive for you to use them at your scale, it is difficult to migrate away. That is vendor lock in -> loss of freedom and choice.
- nickbauman 8y ago
  neop1x has a great response. A more concrete example would be a gaming company that started out with AppEngine for its server support for the game. Once the game has a proven revenue stream, the economics of moving from AppEngine to AppScale are a critical next step to maximizing ROI. You have all the code, now you just need to host it somewhere. Can't do that with any other serverless Platform. It's important to note that AppScale is an aPaaS, and API-platform-as-a-service, where you're guaranteed a consistent API with the ability to plug in different implementations. Something even beyond your typical openness in F/OSS software, too.

yukinon 8y ago

>When I've deployed on ECS (or other "simple" orchestrators), I've found that I ultimately wound up re-inventing lots of Kubernetes features. Could you elaborate a little on this part? Our team is looking at ECS/Fargate as a possible container solution and I am curious what you felt was missing from it.

paulddraper 8y ago
If you're comparing to Kubernetees, "everything". But I'm using ECS and Fargate right now (orchestrated with Terraform). https://rivethealth.com https://rivethealth.com Probably the biggest thing I would like is native secrets management. "Security groups" are limited as it depends on having an AWS interface per container. ANd I don't know how much longer our time on Fargate will last. It's expensive, but more significantly there are limitations in not having access to the host. Having to install an SSH server in every docker container to be able to debug (simple things, like top) is annoying.
- ratling 8y ago
  We nixed ECS for the same reason, no secrets through ConfigSet.
ekidd 8y ago
[Update: See below, many of these features have been added to ECS since the last time I touched this portion of our infrastructure.] > Could you elaborate a little on this part? Our team is looking at ECS/Fargate as a possible container solution and I am curious what you felt was missing from it. Some typical examples: - Kubernetes allows you to run a monitoring container on every single node using something called a "DaemonSet". On ECS, you'll have to build all your monitoring tools into your base image, or use cloud-init to spawn an ECS task on each machine. - You're probably going to end up writing a bunch of scripts to generate ECS task definition JSON and to update running services, and you'll need to integrate this into your CI system somehow. With Kubernetes, you can get away with "kubectl apply -f" for a fairly long time. - Kubernetes makes it relatively easy to allocate and manage persistent disk volumes. I wouldn't necessarily use them for a production database, but they're great for smaller things. - Kubernetes has autoscaling support, plus the ability to control which containers run on which types of servers. - Kubernetes has basic secret management built-in. It's nothing as nice as Vault, but it's good enough to get started. - Kubernetes has support for a whole bunch of useful minor things that would typically wind up as Terraform scripts on AWS. And so on. None of these is very hard individually, but there's a ton of things like this. So we're slowly migrating pieces of ECS infrastructure over to Kubernetes so that we can stop reinventing so many wheels. Again, for those things which can run on Heroku, either choice is overkill. And I have to admit that ECS is very reliable at the things it does. If you do decide to look at Kubernetes, I highly recommend skimming the O'Reilly books, which provide a solid overview of how it all fits together.

winrid 8y ago

For my side projects I just wrote a simple service that listens for Github events and just checks out the repo, builds it, and ssh's to the target server and runs a "stop and run" script. This way I can even put all of the configuration for the different databases in version control too. It's super dirty, but I can deploy dozens of services without issue. Monitoring is another problem, but I don't need Prometheus for this stuff. (I couldn't use Heroku cost effectively because running graph dbs and some custom stuff, but Heroku is AWESOME)

arp242 8y ago

Isn't Heroku really expensive though? I looked at it a few weeks ago and the cheapest plan was $25/month (there's also a $7 "Hobby" plan though, but that seems just for, well, hobby stuff?) I instead got a Linode VPS at $5/month, which gives me more than the $25 Heroku plan? Setting up a VPS is not very hard either – although this may depend a bit on your environment, my app compiles to a static binary – and a lot more flexible. My devops stack thus far consists of scp and tmux.

bgorman 8y ago
Look into Dokku, it is a free Heroku clone that you can run on a cheap VPS. I set it up last week and now all I have to do to deploy is type "git push dokku master".
- winrid 8y ago
  Thanks! Maybe it would be worth replacing my 100 line nodejs script that does the same thing with this in the future :) (not sarcasm, if this works the same and adds more value I'd use it)
  - rorykoehler 8y ago
    Second dokku. Its essentially a 100 line node js script if u remember correctly. Nice eco system growing around it. No scaling though
- 52-6F-62 8y ago
  I missed this comment and made a similar one up-thread. I’ll second. I’m ignorant as to whether large projects have run using it, but for smaller ones it’s useful.
- dyeje 8y ago
  I'll second this. Have had a great experience with dokku, about as simple as Heroku.
kbar13 8y ago
i dont get this thinking of how $25/month is considered expensive when heroku has already figured out and abstracted away all the busy work that's required for deploying code

colechristensen 8y ago

Why don't more people just use the native machine imaging built into cloud providers? (I would actually like to know this) Building an AMI on Amazon is not difficult and if you use it you don't have to reinvent so much architecture on top of AWS (or cloud provider of your choice)

SteveNuts 8y ago
For us, it's much more economical to binpack multiple apps onto a VM than to run one service per VM. Also it makes it much easier to scale out particular services once they outgrow your chosen VM size.
AaronM 8y ago
If your application is 50 microservices, how would you manage that on ec2 instances?
- DanielBMarkham 8y ago
  Why does the number of microservices have anything to do with where they might live? Wouldn't that be much more related to CPU load?
  - SteveNuts 8y ago
    Because you generally want to deploy them independently. If you have 50 microservices and have to run an AMI build every time that's going to significantly slow you down. With containers you generally only deploy the service that has changes to a VM that doesn't change as often.
    - DanielBMarkham 8y ago
      You want them to be independent, atomic. How they are deployed and the choice of technology you choose to couple them with? That should be driven by load -- and dynamic. The reason everybody's so hot on microservices to begin with is that we kept coupling everything all together and it became a huge mess to manage. You don't want to repeat that mistake, only at cloud scale.

yowlingcat 8y ago

Broadly agree with this. Use K8S at LastCo -- was great so long as I didn't have to manage it, but actively managing our own K8S cluster was a nightmare. Using Heroku at CurrentCo and it's a breeze. I highly recommend it. The only thing I think that could unseat it of its ilk would be Zeit, which looks very promising. I'm skeptical of all things serverless right now but Zeit looks promising and most impressively, extremely (perhaps as much as is possible) cost effective.

api 8y ago

> do not attempt to host your own Kubernetes if you can possibly avoid it. We use Google's Kubernetes and are pretty happy with it, but overall this statement bothers me. It's absolutely true. Don't get me wrong. The problem is what it says about Kubernetes as software. It tells me it's ugly and crufty and in some ways immature. Good software should not require that much babysitting.

ummonk 8y ago
Yes. I think Kubernetes has a lot of really useful features but it is needlessly difficult to use and administer. Unfortunately, it seems to have become the de facto standard, so everyone will be forced to deal with it the same way they have to deal with ancient Unixisms (or worse, windowsisms).
snupples 8y ago
The statement is bothersome because it says more about the person saying it than anything else. If your job is to manage infrastructure and you have to deal with thousands of snowflake deployments by other teams then k8s is a godsend.
- api 8y ago
  I just hate unnecessary complexity. I am not sure if the complexity in k8s is necessary or not. Mighy be.

sonnyblarney 8y ago

"Finally, don't overcomplicate it. Just use the basic stuff for as long as you can before trying to layer all sorts of other tools over it." This is I think always the best advice for almost anything. And we all know it. And yet so often, we ... can ... not ... resist.

Thaxll 8y ago

Heroku is really a different solution, I don't know anyone at medium scale project that uses Heroku, Heroku is like the Digital Ocean compare to AWS. You can't really compare DO, Heroku with k8s and AWS, the laters are much much more powerful.

jacques_chester 8y ago
I work for an occasional competitor. Heroku are legit.

cdnsteve 8y ago

Was using Heroku and moved to GCP. It's almost as nice but not as dead simple. App Engine Standard is now updated for latest languages, Python 3.7, Node, etc and really good, its also pretty cost effective. Overall would recommend.

ranrotx 8y ago

I’m surprised no one has mentioned AWS ElasticBeanstalk. It supports Docker (ECS behind the scenes) and is very close to Heroku in terms functionality but with EC2 pricing.

dsmithatx 8y ago
Beanstalk is nice for rapid development. The problem I is that it doesn't scale for nontrivial architiched apps. I've converted failing beanstalk deployments to real orchestarators a few times.
switch007 8y ago
Beanstalk is a joke. You can launch a DB through EB but the docs basically state it's a bad idea (as it gets taken down when you delete your app, which you might find yourself doing if EB gets in to an unrecoverable state). So now you have to manage EB + RDS separately, which should be automated so now you need CloudFormation to add the security groups and manage the vars for the DB connection properties in your EB.

mythz 8y ago

What pain is Heroku saving you to justify being 5x more expensive than Lightsail/Digital Ocean/Linode? All websites I maintain/deploy are either built as a Docker image and published by CI on git check-in or deployed locally with a single rsync/supervisord bash script (or right-click Web Deploy for some older IIS/ASP.NET Apps). I probably have over 50 sites I'm currently hosting so using anything that much more expensive wont enter into consideration. But I'm not seeing what could justify the extra cost? especially as the cost is reoccurring, if it's some kind of effortless/magical scalability I'd rather put that additional cost towards more hardware and buy more headroom.

sosodev 8y ago
I agree. You can set up a Heroku like setup pretty easily. Push to GitLab to trigger your pipeline that builds your container. Now your $5 vps with docker compose and watchtower is updated.
- fulafel 8y ago
  Sounds like you should start a Heroku competitor :) Btw watchtower seems abandoned, anyone know is there a story to it?
nothrabannosir 8y ago
Heroku turns a strategical liability ("I have only one employee who understands what rsync is; if he leaves I'm screwed") into a fiscal one. Any company I've ever known will always choose the latter, for anything outside of their core competency. We use Heroku heavily, and we went from 2 full time devops engineers to 0. Everything is now buttons and sliders. There are no "security patches". The CEO could log in and scale if he needed to; it's a slider. We get monitoring for free (labour free, not cost, i.e. the "good" free). Memory usage, CPU usage, HTTP status codes, logging: it's all there. We spend no time thinking about rsync or devops or any of that: we just solve the problems we're good at. Of course, everything is a matter of scale. Legend has it, Deliveroo UK only moved off Heroku after they grew so large, Heroku wasn't willing to offer them more dynos on their account. That sounds like a reasonable time to go in house. But any <100 people company.. why bother? focus on what you're good at, and let other people do devops.

Doubleslash 8y ago

Though, there is a middle ground between running vanilla Kubernetes yourself on your own hardware and tying yourself into the specifics of a cloud provider just to get managed Kubernetes. There are really good Enterprise distros like OpenShift or PKS that relieve you from the hassle of running Kubernetes and focus on using it but don't force you onto a particular platform or cloud.

pathseeker 8y ago

Why is this upvoted? It's just a bunch of rules based on no reasoning or evidence.

crgwbr 8y ago

What parts of Kube did you find yourself reinventing with ECS? It’s not the most complex microservice setup, but I run around 60 services over 3 ECS clusters and have found it pretty easy and solid at this point. Only real pain point we’ve had was the limit on Awsvpc mode service per ec2 instance—never have figured out why instances are limited to just a few NICs.

halbritt 8y ago

GKE is head and shoulders above the rest. EKS is a joke. The only people that use it are those either experimenting, or those that are forced to. AKS is pretty okay. They're definitely way ahead of EKS. They lack a few things, but they've made some pretty good strides in the last year. Kinda suffers from being part of Azure which likely reflects my personal bias.

jordanbeiber 8y ago

The thing is if you keep to the basics Nomad/consul will do the job just fine. As the fine article points out.