Re: Single app with multiple processes vs multiple apps with single process
Hey Jonas, The purpose and spirit of the gratis dyno hours per application is to help developers bootstrap new ideas quickly without risk. Distributing your processes across multiple applications to reduce costs won't work. You'll pay for it one way or another -- likely through manual, error-prone work. Off the top of my head, other disadvantages include: Your web processes will not be addressable by a single host. Your deploys will now involve n git pushes and you can't guarantee they will complete at the same time. Schema changes to your databases now become very difficult to orchestrate. Environment changes can't be done atomically across all of your proceses. Changes to your add-on infrastructure (e.g., moving to a bigger postgres instance, adding something like sendgrid) will need to be committed manually in your other applications' environments. Putting your application into maintenance mode involves n number of API commands. -jp On Tue, Apr 16, 2013 at 1:57 AM, Jonas Windey jonas.win...@gmail.com wrote: What are the benefits of putting multiple dyno's (ex. web and worker) on a single app compared to putting each dyno on a separate app? In terms of scalability, it would be the same since each dyno can be scaled no matter how it's setup. The only real advantage I could see is that env variables are shared on the same app, but that is something that can be overruled in the latter setup too. The biggest advantage for the second setup is of course a free dyno/month for each app. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Single app with multiple processes vs multiple apps with single process
Hi Jonas, While I agree with all the points JP made, I still chose multiple processes in order to achieve greater security. I maintain information provided by my users that is sensitive. I have two apps, one that provides all of the front end (web) processing, and a second one that contains all the backend (non-web facing) processing. The only difference between the two is configuration: the backend app contains the private keys used to secure the data while the frontend app does not. If a vulnerability exists that exposes config (environment) variables to the web, then the private key simply would not be available as it does not exist in the front-end environment. I believe that this security enhancement is worth the negatives JP mentioned in his response. I'd like to hear from others if they have used this technique, or if they have an informed opinion on whether this technique has merit. Cheers, Jack On Monday, April 15, 2013 10:57:52 PM UTC-7, Jonas Windey wrote: What are the benefits of putting multiple dyno's (ex. web and worker) on a single app compared to putting each dyno on a separate app? In terms of scalability, it would be the same since each dyno can be scaled no matter how it's setup. The only real advantage I could see is that env variables are shared on the same app, but that is something that can be overruled in the latter setup too. The biggest advantage for the second setup is of course a free dyno/month for each app. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Single app with multiple processes vs multiple apps with single process
Hi, I'm not entirely sure what issues you're trying to work around here. Sure, there's an argument for separation of concerns between two separate codebases/applications, but aside from that simplicity is a huge reason for keeping one app as one app. FWIW, I don't know of anyone using this technique aside from separating logical parts of an application to scale them separately For instance, Heroku split www, dashboard, API and ID up into separate apps N On Tue, Apr 16, 2013 at 3:20 PM, Jack R-G jac...@pobox.com wrote: Hi Jonas, While I agree with all the points JP made, I still chose multiple processes in order to achieve greater security. I maintain information provided by my users that is sensitive. I have two apps, one that provides all of the front end (web) processing, and a second one that contains all the backend (non-web facing) processing. The only difference between the two is configuration: the backend app contains the private keys used to secure the data while the frontend app does not. If a vulnerability exists that exposes config (environment) variables to the web, then the private key simply would not be available as it does not exist in the front-end environment. I believe that this security enhancement is worth the negatives JP mentioned in his response. I'd like to hear from others if they have used this technique, or if they have an informed opinion on whether this technique has merit. Cheers, Jack On Monday, April 15, 2013 10:57:52 PM UTC-7, Jonas Windey wrote: What are the benefits of putting multiple dyno's (ex. web and worker) on a single app compared to putting each dyno on a separate app? In terms of scalability, it would be the same since each dyno can be scaled no matter how it's setup. The only real advantage I could see is that env variables are shared on the same app, but that is something that can be overruled in the latter setup too. The biggest advantage for the second setup is of course a free dyno/month for each app. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Single app with multiple processes vs multiple apps with single process
In addition to those great points, it's worth noting that separating your app into multiple apps *just* for the purposes of avoiding paying for them is against Heroku's Terms of Services and subjects your account to termination. Mark On Apr 16, 2013, at 5:02 AM, John Pignata j...@pignata.com wrote: Hey Jonas, The purpose and spirit of the gratis dyno hours per application is to help developers bootstrap new ideas quickly without risk. Distributing your processes across multiple applications to reduce costs won't work. You'll pay for it one way or another -- likely through manual, error-prone work. Off the top of my head, other disadvantages include: Your web processes will not be addressable by a single host. Your deploys will now involve n git pushes and you can't guarantee they will complete at the same time. Schema changes to your databases now become very difficult to orchestrate. Environment changes can't be done atomically across all of your proceses. Changes to your add-on infrastructure (e.g., moving to a bigger postgres instance, adding something like sendgrid) will need to be committed manually in your other applications' environments. Putting your application into maintenance mode involves n number of API commands. -jp On Tue, Apr 16, 2013 at 1:57 AM, Jonas Windey jonas.win...@gmail.com wrote: What are the benefits of putting multiple dyno's (ex. web and worker) on a single app compared to putting each dyno on a separate app? In terms of scalability, it would be the same since each dyno can be scaled no matter how it's setup. The only real advantage I could see is that env variables are shared on the same app, but that is something that can be overruled in the latter setup too. The biggest advantage for the second setup is of course a free dyno/month for each app. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Single app with multiple processes vs multiple apps with single process
Mark's point is obviously the final nail in the coffin but I'd also ask whether it's really worth all the extra complexity and work on your part simply to save $35. On Tuesday, April 16, 2013 3:28:43 PM UTC+1, Mark Pundsack wrote: In addition to those great points, it's worth noting that separating your app into multiple apps *just* for the purposes of avoiding paying for them is against Heroku's Terms of Services and subjects your account to termination. Mark On Apr 16, 2013, at 5:02 AM, John Pignata jo...@pignata.com javascript: wrote: Hey Jonas, The purpose and spirit of the gratis dyno hours per application is to help developers bootstrap new ideas quickly without risk. Distributing your processes across multiple applications to reduce costs won't work. You'll pay for it one way or another -- likely through manual, error-prone work. Off the top of my head, other disadvantages include: Your web processes will not be addressable by a single host. Your deploys will now involve n git pushes and you can't guarantee they will complete at the same time. Schema changes to your databases now become very difficult to orchestrate. Environment changes can't be done atomically across all of your proceses. Changes to your add-on infrastructure (e.g., moving to a bigger postgres instance, adding something like sendgrid) will need to be committed manually in your other applications' environments. Putting your application into maintenance mode involves n number of API commands. -jp On Tue, Apr 16, 2013 at 1:57 AM, Jonas Windey jonas@gmail.comjavascript: wrote: What are the benefits of putting multiple dyno's (ex. web and worker) on a single app compared to putting each dyno on a separate app? In terms of scalability, it would be the same since each dyno can be scaled no matter how it's setup. The only real advantage I could see is that env variables are shared on the same app, but that is something that can be overruled in the latter setup too. The biggest advantage for the second setup is of course a free dyno/month for each app. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+un...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+un...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+un...@googlegroups.com javascript: For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+un...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Groups Heroku group. To unsubscribe from this group, send email to heroku+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/heroku?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups Heroku Community group. To unsubscribe from this group and stop receiving emails from it, send an email to heroku+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: 502 Bad Gateway, is there a way to discover what Heroku objected to in the response?
Can you include an example curl for the app on Heroku when it receives a
502? This would help verify whether the 502 response was sent by your app
or the Heroku router.
Also, do your app's heroku logs show anything when this happens?
On Monday, April 15, 2013 8:35:35 PM UTC-7, William Billingsley wrote:
Is there a way to find out *what* Heroku's proxy objected to in a response?
I have an app which on its Server Sent Events url gets a 502 Bad Gateway
on Heroku (but for which its other urls work fine, and the app's own log
messages suggest the app did try to respond)
When I run the app on localhost, this is the output from cURL to the event
stream, and I'm trying to work out if there's any part of this response
that Heroku's proxy would object to, that would cause it to 502 Bad
Gateway on Heroku.
$ curl -N -v http://localhost:9000/eventRoom/ssevents
* About to connect() to localhost port 9000 (#0)
* Trying ::1...
* connected
* Connected to localhost (::1) port 9000 (#0)
GET /eventRoom/ssevents HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0
OpenSSL/0.9.8r zlib/1.2.5
Host: localhost:9000
Accept: */*
HTTP/1.1 200 OK
Connection: close
* Negative content-length: -1, closing after transfer
Content-Length: -1
Content-Type: text/event-stream
Set-Cookie:
PLAY_SESSION=c115bf50b75969eeb9b9751b66f481829a1fd5c0-sessionkey%3A516cc2339acb3a6b00380eac;
Path=/; HTTPOnly
data: {type:ignore}
data: {type:connected,listenerName:516cc2339acb3a6b00380eab}
--
--
You received this message because you are subscribed to the Google
Groups Heroku group.
To unsubscribe from this group, send email to
heroku+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/heroku?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups
Heroku Community group.
To unsubscribe from this group and stop receiving emails from it, send an email
to heroku+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
