5 ms·

"Notice that the Appfile makes no mention of OS, memory, disk space, etc. Otto has built-in knowledge of best practices and picks smart defaults for you." Soun

by alrs 11y ago

"Notice that the Appfile makes no mention of OS, memory, disk space, etc. Otto has built-in knowledge of best practices and picks smart defaults for you." Sounds like a big bag of "nope."

skorecky 11y ago
Why? This is what I love about Heroku. I get to build the app I want without worrying about all the other aspects of hosting that make me want to never launch an app ever again. I love the idea of focusing on the development part and letting something / someone else worry about hosting.
- whalesalad 11y ago
  Have you ever dealt with a large app deployment on Heroku? Unless you're willing to throw money at the problem it sucks.
  - skorecky 11y ago
    Yes and if you're a small team with limited resources and you don't have an operations person/team throwing money at the problem works. There will come a time when you will need to setup a more customized hosting solution but hopefully by then you can hire someone to do operations that knows what they are doing. I don't think Heroku or Otto are designed for big projects anyways, they're a great way to get up and running and help you grow without having to worry about infrastructure upfront or for a couple years.
    - sanderjd 11y ago
      > I don't think Heroku or Otto are designed for big projects anyways. If you're right about that in Otto's case, that's a bummer. It's frustrating that there is this seemingly intractable divide between things that are great to start with for a new project (Heroku, etc.) and things that scale well as a project grows huge (Kubernetes, etc.). Every time a devops tool comes out, I read about it in hopes that it has both the easy-start and but-scales-as-needed stories, and inevitably find people saying it's actually one or the other.
      - dasil003 11y ago
        I think the truth underlying that observation is that scaling is always hard. It's relatively easy to pick some defaults that work to get 99% of projects off the ground when they are small, but once you approach real scale inevitably hard decisions need to be made, and those decisions will depend on seemingly minute details of your service's workload. Therefore, tools like Kubernetes necessarily have a threshold of expertise required to use them effectively. I think all of these things are all trending towards more scalable and easier to use, but fundamentally there will always be a tension between those two goals.
      - jacques_chester 11y ago
        What works for me is cf scale my-app-name 4 Or 10, or 100, or however many copies I need.
      - derefr 11y ago
        A Heroku-like PaaS layer that serves as a manager for—but crucially, doesn't attempt to abstract away—a set of IaaS components would be interesting. Sort of a convention-over-configuration CLI tool for interacting with some CloudFormation-like API. The "non-abstraction" part doesn't seem to be in any cloud provider's interest to sell, though; even with AWS, when you allocate a database, it doesn't result in a new EC2 instance for the DB being dropped into your bag of instances, such that you just get charged instance fees for the instance. Instead, it all gets packaged up so that you can be charged higher, separate, value-based database fees. It's a bit ridiculous.
  - jbob2000 11y ago
    As opposed to throwing money at a person to solve the problem?
abrahamepton 11y ago
I think that's why they're defaults? Not hardcoded unchangeable values?
- kaonashi 11y ago
  Everything having a default is sometimes not sensible. In such cases, explicit and declarative is much better than implicit and hidden.
  - ohitsdom 11y ago
    I don't understand this sentiment. What's the issue with having defaults that are used if no values are specified? Assuming the documentation is good and you can find a list of all options (and default values).
  - scoates 11y ago
    Indeed. Sometimes it's worth making people do a little bit of extra work so that they can actually start to grok a system. A little (but not quite) like this: https://github.com/eggheads/eggdrop-1.8/blob/master/eggdrop.conf#L543 https://github.com/eggheads/eggdrop-1.8/blob/master/eggdrop....
coldtea 11y ago
Or a huge bag of "finally!"
dragonwriter 11y ago
Note that it appears that the Appfile can (or will be able to before a 1.0 release, at any rate; the documentation is incomplete and not entirely consistent and its not clear if how to do this is just not documented or not yet present) specify these things, but the intent to is to provide basic defaults so that the "get something minimally working" workflow is as simple as possible.

by alrs 11y ago

"Notice that the Appfile makes no mention of OS, memory, disk space, etc. Otto has built-in knowledge of best practices and picks smart defaults for you." Sounds like a big bag of "nope."

skorecky 11y ago

Why? This is what I love about Heroku. I get to build the app I want without worrying about all the other aspects of hosting that make me want to never launch an app ever again. I love the idea of focusing on the development part and letting something / someone else worry about hosting.

whalesalad 11y ago
Have you ever dealt with a large app deployment on Heroku? Unless you're willing to throw money at the problem it sucks.
- skorecky 11y ago
  Yes and if you're a small team with limited resources and you don't have an operations person/team throwing money at the problem works. There will come a time when you will need to setup a more customized hosting solution but hopefully by then you can hire someone to do operations that knows what they are doing. I don't think Heroku or Otto are designed for big projects anyways, they're a great way to get up and running and help you grow without having to worry about infrastructure upfront or for a couple years.
  - sanderjd 11y ago
    > I don't think Heroku or Otto are designed for big projects anyways. If you're right about that in Otto's case, that's a bummer. It's frustrating that there is this seemingly intractable divide between things that are great to start with for a new project (Heroku, etc.) and things that scale well as a project grows huge (Kubernetes, etc.). Every time a devops tool comes out, I read about it in hopes that it has both the easy-start and but-scales-as-needed stories, and inevitably find people saying it's actually one or the other.
    - dasil003 11y ago
      I think the truth underlying that observation is that scaling is always hard. It's relatively easy to pick some defaults that work to get 99% of projects off the ground when they are small, but once you approach real scale inevitably hard decisions need to be made, and those decisions will depend on seemingly minute details of your service's workload. Therefore, tools like Kubernetes necessarily have a threshold of expertise required to use them effectively. I think all of these things are all trending towards more scalable and easier to use, but fundamentally there will always be a tension between those two goals.
    - jacques_chester 11y ago
      What works for me is cf scale my-app-name 4 Or 10, or 100, or however many copies I need.
    - derefr 11y ago
      A Heroku-like PaaS layer that serves as a manager for—but crucially, doesn't attempt to abstract away—a set of IaaS components would be interesting. Sort of a convention-over-configuration CLI tool for interacting with some CloudFormation-like API. The "non-abstraction" part doesn't seem to be in any cloud provider's interest to sell, though; even with AWS, when you allocate a database, it doesn't result in a new EC2 instance for the DB being dropped into your bag of instances, such that you just get charged instance fees for the instance. Instead, it all gets packaged up so that you can be charged higher, separate, value-based database fees. It's a bit ridiculous.
- jbob2000 11y ago
  As opposed to throwing money at a person to solve the problem?

abrahamepton 11y ago

I think that's why they're defaults? Not hardcoded unchangeable values?

kaonashi 11y ago
Everything having a default is sometimes not sensible. In such cases, explicit and declarative is much better than implicit and hidden.
- ohitsdom 11y ago
  I don't understand this sentiment. What's the issue with having defaults that are used if no values are specified? Assuming the documentation is good and you can find a list of all options (and default values).
- scoates 11y ago
  Indeed. Sometimes it's worth making people do a little bit of extra work so that they can actually start to grok a system. A little (but not quite) like this: https://github.com/eggheads/eggdrop-1.8/blob/master/eggdrop.conf#L543 https://github.com/eggheads/eggdrop-1.8/blob/master/eggdrop....

coldtea 11y ago

Or a huge bag of "finally!"

dragonwriter 11y ago

Note that it appears that the Appfile can (or will be able to before a 1.0 release, at any rate; the documentation is incomplete and not entirely consistent and its not clear if how to do this is just not documented or not yet present) specify these things, but the intent to is to provide basic defaults so that the "get something minimally working" workflow is as simple as possible.