3 ms·

This looks amazing. When it matures, this is probably going to kill Heroku. This may also mean that I will never have to touch devops again. I may never have t

This looks amazing. When it matures, this is probably going to kill Heroku. This may also mean that I will never have to touch devops again. I may never have to use Terraform, Kubernetes, Docker, CoreOS, and all that other stuff. At least, not for small to medium-sized deployments. It also means that I'll never need to touch Dokku or Flynn. I was about to say that some company just wasted a lot of money on Deis, but then I remembered that it was Microsoft. So maybe that was a good move, although I feel like Azure is the Bing of cloud providers. I'm actually angry that this took so long. This should have been available 5 years ago.

andrewstuart2 10y ago
> I may never have to use Terraform, Kubernetes, Docker, CoreOS, and all that other stuff. True, you may never have to as long as you're okay putting 100% of your faith in the benevolence of a single company. Remember, a good portion of AWS services are completely proprietary and serve as a pretty fancy set of golden, jewel-encrusted handcuffs. Fully open source projects like those you mentioned, on the other hand, are positioning developers who know them to treat the cloud providers of today as just another source of CPU cycles, storage, and networking. For the services I run on Kubernetes in AWS, I can lift and shift those in a day if/when the day comes that Amazon is a little less benevolent with their pricing and service levels. If we were asked to do the same with our services built expecting AWS functionality, it would takes months to years. Guaranteed. Yes, there's a trade-off that I don't get 100% managed services and I have to know a little about the workings of the platform, but I would make that same commitment to AWS the second it didn't do everything for me. In my experience, that moment usually occurs somewhere around the 10-minute mark. Amazon is great today, but Bezos won't live forever and who knows what happens when his successor takes over. It could be great, or it could be a mass exodus of people dumping years of investment. Personally, I'd rather hedge my bets and use their low-cost VMs as my source of compute today, but leave myself plenty of dead-simple exit options and sleep a little more easily at night. That's what open source software is all about.
- meddlepal 10y ago
  The problem is, most people won't work for a company long enough to see your hypothetical doomsday scenario (if it even does). The people who will be screwed are not likely the ones making the decisions today.
  - ademarre 10y ago
    It's not just the doomsday scenario. It's smart to avoid vendor lock-in because eventually a competing cloud vendor could offer better pricing or more reliable service. Or you could run redundant infrastructure on AWS and Google Cloud Platform at the same time to insulate yourself from major vendor outages. Also, not all doomsday scenarios are terribly far fetched. AWS might one day have to discontinue a service after losing an intellectual property lawsuit, for example.
- monkmartinez 10y ago
  You probably have a lot more "hit by bus" deficiencies in your code than you think. Even more so in open source.
  - fillskills 10y ago
    What Amazon has done is created the first DevOps free experience. I am sure Microsoft/Google and others will be on the bandwagon very soon. This product is VERY VERY good for someone like me who hates DevOps
    - tedmiston 10y ago
      Heroku did it 10 years ago
      - wstrange 10y ago
        And Google App Engine 9 years ago
- solatic 10y ago
mark_l_watson 10y ago
I doubt it will kill Heroku. For some developers and some types of projects, the minimal effort to deploy and push new versions of apps to Heroku is worth the $7/month for the smallest paid dyno. Years ago I wrote a blog on how to set up git commit hooks, a sample shell script to update an app, etc. I did that myself for a year or two, then went back to using Heroku and other services. There are a lot of small projects that live inexpensively on Heroku. That said, I would personally not do a large multi "server" deployment there because of cost, but for the small stuff I think that they are the 'best of breed.'
- jeremyjh 10y ago
  The small projects are a loss leader for the whales that spin up thousands of dynos. I would guess a lot of the whales get there without thinking too much about it - each step along the way its way easier to spin up a few more than to actually pay for ops. What this has me thinking now is that a micro beanstalk doesn't cost more than Heroku initially and will scale much more economically if my product takes off; and I can actually achieve `git push` deployment without a lot of yak shaving.
tootie 10y ago
Elastic Beanstalk already solved most of that for me. CodeStar looks like it's there to go after Jenkins and Bitbucket too.
obiefernandez 10y ago
You are way underestimating how many of us really, really love Heroku for our small clients and projects that run just fine on one or two little dynos. Oh and their add-ons marketplace is amazing--I can't see AWS replicating anything like it, since they have their own competing product offerings.
cdnsteve 10y ago
I highly doubt that, Heroku is a great product. Very reliable in my experience and requires zero management. Under the hood of CodeStar, EC2 services in particular, still need management, patching, etc. So it feels like a quick way to spin up your app but after that there's still overhead to keep it going.

andrewstuart2 10y ago

> I may never have to use Terraform, Kubernetes, Docker, CoreOS, and all that other stuff. True, you may never have to as long as you're okay putting 100% of your faith in the benevolence of a single company. Remember, a good portion of AWS services are completely proprietary and serve as a pretty fancy set of golden, jewel-encrusted handcuffs. Fully open source projects like those you mentioned, on the other hand, are positioning developers who know them to treat the cloud providers of today as just another source of CPU cycles, storage, and networking. For the services I run on Kubernetes in AWS, I can lift and shift those in a day if/when the day comes that Amazon is a little less benevolent with their pricing and service levels. If we were asked to do the same with our services built expecting AWS functionality, it would takes months to years. Guaranteed. Yes, there's a trade-off that I don't get 100% managed services and I have to know a little about the workings of the platform, but I would make that same commitment to AWS the second it didn't do everything for me. In my experience, that moment usually occurs somewhere around the 10-minute mark. Amazon is great today, but Bezos won't live forever and who knows what happens when his successor takes over. It could be great, or it could be a mass exodus of people dumping years of investment. Personally, I'd rather hedge my bets and use their low-cost VMs as my source of compute today, but leave myself plenty of dead-simple exit options and sleep a little more easily at night. That's what open source software is all about.

meddlepal 10y ago
The problem is, most people won't work for a company long enough to see your hypothetical doomsday scenario (if it even does). The people who will be screwed are not likely the ones making the decisions today.
- ademarre 10y ago
  It's not just the doomsday scenario. It's smart to avoid vendor lock-in because eventually a competing cloud vendor could offer better pricing or more reliable service. Or you could run redundant infrastructure on AWS and Google Cloud Platform at the same time to insulate yourself from major vendor outages. Also, not all doomsday scenarios are terribly far fetched. AWS might one day have to discontinue a service after losing an intellectual property lawsuit, for example.
monkmartinez 10y ago
You probably have a lot more "hit by bus" deficiencies in your code than you think. Even more so in open source.
- fillskills 10y ago
  What Amazon has done is created the first DevOps free experience. I am sure Microsoft/Google and others will be on the bandwagon very soon. This product is VERY VERY good for someone like me who hates DevOps
  - tedmiston 10y ago
    Heroku did it 10 years ago
    - wstrange 10y ago
      And Google App Engine 9 years ago
solatic 10y ago

mark_l_watson 10y ago

I doubt it will kill Heroku. For some developers and some types of projects, the minimal effort to deploy and push new versions of apps to Heroku is worth the $7/month for the smallest paid dyno. Years ago I wrote a blog on how to set up git commit hooks, a sample shell script to update an app, etc. I did that myself for a year or two, then went back to using Heroku and other services. There are a lot of small projects that live inexpensively on Heroku. That said, I would personally not do a large multi "server" deployment there because of cost, but for the small stuff I think that they are the 'best of breed.'

jeremyjh 10y ago
The small projects are a loss leader for the whales that spin up thousands of dynos. I would guess a lot of the whales get there without thinking too much about it - each step along the way its way easier to spin up a few more than to actually pay for ops. What this has me thinking now is that a micro beanstalk doesn't cost more than Heroku initially and will scale much more economically if my product takes off; and I can actually achieve `git push` deployment without a lot of yak shaving.

tootie 10y ago

Elastic Beanstalk already solved most of that for me. CodeStar looks like it's there to go after Jenkins and Bitbucket too.

obiefernandez 10y ago

You are way underestimating how many of us really, really love Heroku for our small clients and projects that run just fine on one or two little dynos. Oh and their add-ons marketplace is amazing--I can't see AWS replicating anything like it, since they have their own competing product offerings.

cdnsteve 10y ago

I highly doubt that, Heroku is a great product. Very reliable in my experience and requires zero management. Under the hood of CodeStar, EC2 services in particular, still need management, patching, etc. So it feels like a quick way to spin up your app but after that there's still overhead to keep it going.