Sazbean: Will you be supporting DNS redirects for users who want to use their domain instead of heroku.com?
James: That’s already available. You can add your own custom DNS at any time. There are a bunch of applications that are hosted right now, where you can’t tell at all that they have anything to do with Heroku.
Sazbean: One of the services you have tackled is authentication. How does this work in Heroku?
James: Yeah, so user authentication is a long-standing area of challenge. It is something that tends to be very similar for most applications and no one enjoys constantly rewriting it, but on the other hand everyone always needs something slightly different and no one has yet come up with a good model that works across all applications. So when you come into Heroku you have a couple of ways you can go. You can always build user authentication how you normally do, use a plugin like acts_as_authenticated, and you can switch your application to public. We have a public vs private toggle and when you switch your application to public anyone can access it and you can implement your own authentication. Or we also provide something to try to make people’s lives easier as a bootstrap to get started right away. Since your application can be private so that users have to authenticate through Heroku to get to it, you can leave it like that and we pass the authentication information in with the request, so that you can access that easily with some code we provide that is automatically loaded with your application. So you could not write your own, and rely on Heroku authentication. A place where that’s really useful is when you wake up one day and want to build something really light weight, like something to gather some information from some other system. You don’t want to make it public, and you want to avoid writing your own authentication, so you can just add some of your co-workers as collaborators. Then you can tap into user information like email if your app needs to associate some information with comments or whatnot. We have some much more interesting things coming down the road for built-in authentication, but this can get you started quickly today.
Sazbean: You mentioned elasticity earlier, and I’ve also heard the phrase liquid scaling used elsewhere. What are these terms?
James: So there are a couple things. The term ‘elastic’ has to do with being able to expand up and then contract down. The key there is to be able to decrease, not just scale up but to also scale down so you can minimize the amount of resources you are using. That way you only use what you need. Liquid scaling is about making the chunk size smaller. With Amazon you have instances. You have an entire machine for one hour. That’s the smallest chunk size. Those are your units and you can use more or less of those, but we think that’s not granular enough. We think people should be able to think about it on a per-request basis. Our scaling is per-request, so that we actually can scale up and down fluidly without having these large step sizes.