Dockerize & deploy tickets queue on AWS

eladg commented 7 years ago

In the past, Midburn's Ticket queue was deployed and managed on Heroku for convenience and ease of use with our little resources at the time - yet using Heroku was never the plan.

We would like to create a .dockerfile and a docker image so deploying the application will be swift and easy on any PaaS, focusing mainly on AWS.

eyalrosen commented 7 years ago

Why would you prefer Docker over Heroku?

yules commented 7 years ago

+1 for it. If we're moving the q, might as well rewrite it with node/mongo for better performance/cost. otherwise just leave as is

omerpines commented 7 years ago

Eyal, I've already explained this to you. We are not using Heroku since it costs money. We have AWS credit and we'll use their services instead.

omerpines commented 7 years ago

Eyal, Elad and Yuval, can you get this ready by end of November for testing so we don't have to do it last minute?

eyalrosen commented 7 years ago

Since the queue is standalone from the profiles system (correct me if I wrong) and It's being used only on for short periods of times (few hours for each sell) wouldn't it be smarted to keep it in Heroku which is he most mature, stable and easy to use tool for this kind of needs?

On Thu, Nov 3, 2016 at 11:57 AM, Omer Pines notifications@github.com wrote:

Eyal, Elad and Yuval, can you get this ready by end of November for testing so we don't have to do it last minute?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Midburn/midburn-queue/issues/26#issuecomment-258101555, or mute the thread https://github.com/notifications/unsubscribe-auth/AED1NQHit6C3SAQdDBE338Akk0J7PBXjks5q6bAmgaJpZM4Kn2B4 .

yules commented 7 years ago

You're not wrong. @omerpines how much did it cost us last year?

omerpines commented 7 years ago

About $50 a month.

yules commented 7 years ago

@omerpines then my suggestion would be to get midburn's approval and keep it for the coming sales.

omerpines commented 7 years ago

@yules + @eyalrosen + @eladg, What are the benefits of remaining in Heroku instead of moving to AWS? How difficult will it be to implement it on AWS? Do you really see us using the system on Heroku and doing the current queue implementation in the long run (next few years)? I am not saying no, I'm just saying this is not a sustainable long-term solution. We need a plan here, preferably on AWS.

yules commented 7 years ago

@omerpines :

It's already working. So why change it?
It's already working. Less risky.
It's already working. If we do AWS now we need to retest the whole scale and load, iterate, maybe even rewrite some of it.
It's already working. So we can invest the time in developing spark and not the queue.
$50/ Mo = $300 for this year's sales (Overestimating). It's not that much, unless we're totally broke.
AWS big server for the sales and testing process will cost us just as much. Not to mention the fact that scaling needs to happen hours before rather than just a click.

eyalrosen commented 7 years ago

So the benefits of Heroku vs AWS would be:

The entire cloud environment (load balancer, servers maintains, logging etc.) is ran by Heroku, not by us.
Much more easy to use, therefore possibly much less mistakes.
Much faster adding of new servers (about 30 seconds rather than 5-10 minutes on AWS).

I think that the possible damage from having a human error on the sales is much bigger than the extra $30-$40 bucks we'll pay, so I think we should keep it as our long-term solution.

The other systems which runs all year long should be moved to AWS.

On Sun, Nov 6, 2016 at 10:10 AM, Eyal Chloe Rosen eyal@madfairy.org wrote:

I had a few months experience with Heroku alternatives (PaaS providers) and to my knowledge I don't think there's currently a good alternative to Heroku.

There are many reasons why Heroku would be the best choice but the primary one would be that other with PaaS providers (like Elastic Beanstalk, Deis, etc.) you need to wait a 5-10 minutes for each increase of servers because you need start a new machine. In Heroku starting a new machine is instant because they have a huge pool of running servers and for every dyno increase they fire up a new container on one of there machines.

Also, most of the competitors for Heroku are in beta (whether they admit it or not) and they really buggy. Not to say that Heroku is bug-free, but other one's are really terrible and slow.

The one exception (I found) would be EngineYard but it's much more expensive than Heroku and has less add-on's.

On Sun, Nov 6, 2016 at 1:54 AM, Omer Pines notifications@github.com wrote:

@yules https://github.com/yules + @eyalrosen https://github.com/eyalrosen + @eladg https://github.com/eladg, What are the benefits of remaining in Heroku instead of moving to AWS? How difficult will it be to implement it on AWS? Do you really see us using the system on Heroku and doing the current queue implementation in the long run (next few years)? I am not saying no, I'm just saying this is not a sustainable long-term solution. We need a plan here, preferably on AWS.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Midburn/midburn-queue/issues/26#issuecomment-258650408, or mute the thread https://github.com/notifications/unsubscribe-auth/AED1NTwHHsNU9wxG3fsM5LGWuh53O5ZIks5q7RcfgaJpZM4Kn2B4 .

eyalrosen commented 7 years ago

BTW, we can ask Heroku for funds like we did with AWS.

eladg commented 7 years ago

As for the discussion above and in person, we will not Dockerize the queue at this point.

kaplanlior / midburn-queue

Dockerize & deploy tickets queue on AWS #26