No. The real issue is that these APIs/platforms are closed source. Sooner or later you may need to move a service from appengine to a non-gae environment and you will find that nothing works. If you invest in tools/libs (i.e wrappers/ORM around the GAE APIs) the loss is even bigger.
Hi HN. Canvas lays the foundation for some great long term plans. Long term is great, but why use Canvas today?
- Focused on flow. Folding to merge preview and editing modes. Markdown to keep fingers on keys.
- Absurdly easy sharing. URLs are magic. Start up a meeting, share the URL in Slack
- Hackable. Make it easy to integrate into your workflows and systems. No lock in.
Love for you folks to try it, and give us feedback. The quickest way to get a feel is to hit the try button, share the URL to write with friends, then append .json to the URL and see what happens.
I've read through the OP, and all of the comments here. Our job at Heroku is to make you successful and we want every single customer to feel that Heroku is transparent and responsive. Getting to the bottom of this situation and giving you a clear understanding of what we’re going to do to make it right is our top priority. I am committing to the community to provide more information as soon as possible, including a blog post on http://blog.heroku.com.
Thanks for the response, but I have to admit that the lack of a clear-cut answer here is a little worrisome.
Anyone who wants to like Heroku would hope that the OP is flat out, 100%, wrong. The fact that Heroku's official answer requires a bit of managing implies otherwise.
On a related tangent, I would also encourage future public statements to be a little less opaque than some Heroku has put out previously.
For instance, the cause of the outage last year was attributed to "...the streaming API which connects the dyno manifold to the routing mesh" [1]. While that statement is technically decipherable, it's far from clear.
Maybe it doesn't need "managing", Oren might just want to talk with whoever was responsible for the change and see what the best way forward is. I don't think panicked, knee-jerk reactions like "OMG we were wrong and will revert that commit pronto!" are beneficial in situations as complex as this.
You're assuming that the change was actually made. Until we hear definitively from Heroku, the only evidence is an (admittedly, well documented) blog post.
Yeah, absolutely. I'm just saying we can't expect a to manager to immediately respond to a highly-technical issue questioning subtle changes in internal behaviour which might have been introduced years ago.
What's the point of posting a link to the front page of your blog, where the most recent article is 15 days old (4 hours after the comment above)?
What we want to know:
- is the OP right or wrong? That is, did you switch from smart to naive routing, for all platforms, and without telling your existing or future customers?
- if you did switch from smart to naive routing, what was the rationale behind it? (The OP is light on this point; there must be a good reason to do this, but he doesn't really say what it is or might be)
- if the OP is wrong, where do his problems might come from?
>> I am committing to the community to provide more information as soon as possible, including a blog post onhttp://blog.heroku.com
> What's the point of posting a link to the front page of your blog, where the most recent article is 15 days old (4 hours after the comment above)?
I think OP is saying 'I am going to investigate the situation; when I am finished here [the blog] is where I will post my response', not that there is something there already.
That said, it's all a little too PR-Bot for my taste (although there's probably only so many ways to say the same info without accidentally accepting liability or something).
What's the point of posting a link to the front page of your blog
Well, he promised a detailed blog post, at which point that link will be extremely helpful.
I do not think it is fair to expect an immediate detailed response to those questions. If I were CEO of Heroku, I wouldn't say anything definite until after talking to the engineers and product managers involved--even if I was already pretty sure what happened. The worst thing you could do at this point is say something that's just wrong.
I don't expect an immediate response; I would have been happy with just: "This is Heroku's CEO. I'm on it."
But a link, that doesn't point anywhere useful, introduced by a PR phrase that sounds a little like "Your call is important to us", was a little annoying, esp. after reading the OP where they say they have contacted Heroku multiple times on this issue.
> if you did switch from smart to naive routing, what was the rationale behind it?
Most probable cause: smart routing is hard to scale. Multiple routers, with each one doing random distribution independently of others will still produce a globally random distribution. No need for inter-router synchronization.
If multiple routers try smart routing, they must do quite a bit of state sharing to avoid situations where N routers try to schedule their tasks on a single dyno. And even if you split dynos between routers then you need to move requests between routers in order to balance them.
While I think it is appropriate for Heroku to respond to this thread (and other important social media outlets covering this), linking to a blog without any messaging concerning your efforts might not be the greatest move... This may not be a sink or swim moment for Heroku, but tight management of your PR is key to mitigating damage. Best of luck, Heroku is a helpful product and I want to see you guys bounce back from the ropes on this one.
hint just use a rabbitmq queue or something. Don't have a 'smart' LB that has to know everyone's state; instead, have dynos that get more work as quick as they can.
MQ might be a solution but certainly not in the "just use" class. Unless you want to introduce a bottleneck and a single point of failure, this queue has to be distributed.
Managing a distributed queue is hard, for reasons similar to ones making the original problem hard - DQs require global state in a distributed environment. There are tradeoffs involved - the synchronization cost might become a bottleneck in itself.
Pushing the problem on the distributed brokers is making a big bet on the queuing solution. Nope, definitely not in the "just use" category.
Following the steps in that gist, I have a heroku clojure app up that just created an invoice line item for 1 worker. It was only for a few minutes, but I definitely just got charged for it.
On June 1, 2011, Heroku switched from billing for “dynos” to billing for “dyno-hours”, which is more clear. This brings pricing inline with the new process model, wherein you can run one-off processes as well as manipulate the dynos for each of your app’s process types independently.
The vast majority of apps will see a 1% - 10% reduction in overall monthly dyno charges.
Previously, Heroku included “1 free dyno” with each app, which is equivalent to between 672 and 744 dyno-hours (depending on the length of the month). With this switch to dyno-hours, we are converting the included free dyno to a fixed 750 free dyno-hours. This makes more sense, is more consistent, gives all users additional free dyno-hours, and allows the free dyno-hours to be used for any kind of process (web, workers, one-off admin process, or any other Procfile process).
Ahhhh that would be why, I didn't notice the 'future' billing change that is supposed to happen tomorrow.
I'll edit my original post to clarify.
On a more serious note, thanks for the great work Heroku! Very excited to see you guys turning into a generic service platform with a strong API based addon presence.
