8 ms·
Rack: Open-Source PaaS on AWS
- ShaneOG 10y agoIt seems naming things is still one of the hard things in Comp Sci: http://rack.github.io http://rack.github.io
- koolba 10y ago> It seems naming things is still one of the hard things in Comp Sci: http://rack.github.io http://rack.github.io I think rack is a pretty good name for something that is meant to be the infrastructure for running services. Not sure of the etymology for this project, but to me it conveys images of a server rack in a datacenter.
- drizze 10y agoI believe he referencing the fact that a well known technology called 'Rack' already exists.
- vidarh 10y agoIt's not a bad name. The point is it's a name of a very well established, years old open source project used as the near-universal interface points between web servers and Ruby web frameworks.
- jdubs 10y agoCompanies too... Rackspace comes to mind.
- leesalminen 10y agoRackspace also has a CLI tool called rack
- benatkin 10y agoWhere do you draw the line? I find using the same term just barely acceptable right now. If ruby was as hot as it was three years ago, maybe I wouldn't. http://www.indeed.com/jobtrends/q-rails-q-ruby.html?relative=1 http://www.indeed.com/jobtrends/q-rails-q-ruby.html?relative...
- heartbreak 10y agoWow three whole years ago? Pack it up ladies and gentlemen we're heading to the Ruby funeral. Sorry for the snark, but tens of thousands of developers are using the real Rack every day. It's a mature component in widely used web frameworks. Next up a JavaScript framework called Rake because who uses Ruby anymore.
- ddollar 10y agoWe picked Rack because we like the conceptual analogy. The naming conflict is unfortunate but there are a limited set of good words available. We hope that context will make the meaning clear. Thank you for commenting :)
- jhall1468 10y ago3 years is a life time in web dev. More importantly, who cares? It was a common 4 letter word used to describe an item that holds stuff a hell of a long time before it was a Ruby thing. Ruby programmers are a... dedicated bunch.
- vidarh 10y agoThose spikes are curious, so let's add a couple of other languages: http://www.indeed.com/jobtrends/q-rails-q-ruby-q-javascript-q-php.html?relative=1 http://www.indeed.com/jobtrends/q-rails-q-ruby-q-javascript-... Seems like this is likely to reflect something other than changes in language popularity. Frankly the data doesn't seem very interesting without correcting for other factors such as total volume of jobs. Overall, Ruby looks pretty much as popular today as 3 years ago to me from that data, though perhaps with Rails in a downwards trend (awesome - I love Ruby, but finding Ruby work that doesn't imply Rails is harder, and I don't like Rails). But it's besides the point anyway. I simply explained why someone mentioned Rack, I don't particularly care either way (probably because I don't really care about Convox Rack - I'd never use a single vendor solution like this, and haven't exactly hidden how overpriced I find AWS in past comments).
- parent5446 10y agoIt is also the name for physical pieces of metal in which you place servers to store them while they are online. I don't see a problem with two items have the same name provided the functionality they provide is substantially different. Nobody is going to get confused over whether they are referring to the PaaS application or a Ruby library in everyday conversation.
- mwmanning 10y agoThat's exactly the etymology. We were thinking about datacenters and servers. The original name was convox/kernel, but we thought it wasn't very descriptive. The naming collision with the Ruby interface is unfortunate, but we figured it was pretty easy to tell them apart from context.
- ShaneOG 10y agoTbh I agree that as a descriptive name it works quite well. However, it will muddy the waters for people trying to solve problems in future. For example, this tag on StackOverflow: http://stackoverflow.com/questions/tagged/rack http://stackoverflow.com/questions/tagged/rack
- nzoschke 10y agoA datacenter rack is indeed the etymology of the name. Naming is hard. "Convox" is the company and platform. Rack is a project code name but it is a noun you come across when using the platform too. For example the 'convox rack update' command delivers API and infrastructure improvements.
- sciurus 10y agoPrevious discussions of Convox Rack: https://hn.algolia.com/?query=convox&sort=byPopularity&prefix&page=0&dateRange=all&type=story https://hn.algolia.com/?query=convox&sort=byPopularity&prefi...
- mwmanning 10y agoHi, Matt from Convox here. I'm happy to answer any questions you have about Rack or any of Convox's other offerings. To join a discussion with our user community please join our Slack! https://invite.convox.com https://invite.convox.com
- shimon 10y agoWhat's Convox's business/funding model? Not skeptical, just genuinely curious and can't tell from browsing the site. Also, what are your other offerings? If everything between AWS and my site is free, what else is there to offer?
- mwmanning 10y agoWe were in the Summer 2015 YC batch and we've taken some VC funding. Our other main offering is a web console for managing your team's access to rack(s) and integrations with 3rd party services. https://console.convox.com https://console.convox.com We charge a subscription fee for that and we also sell support and services packages.
- nzoschke 10y agoOne of the maintainers of Convox/rack here... A few important differences between Convox and other options in the space. AWS only. We use lots of AWS services to piggy back on all the reliability AWS has baked in. For example we use DynamoDB to record all your builds because none of us want to manage a Postgres for record keeping. Open source. The layer between you and your AWS account is open, transparent, and modifiable. Simple. I want to remove as many moving parts as possible, not add a heavy middleware.
- nzoschke 10y agoDocker. Docker is working incredibly well in production and in development, particularly if you use only a subset of its features. We're relying on Docker as much as possible for building and deploying your apps.
- nzoschke 10y agoWorkflow / app / developer focused. With convox you deal with `apps`, `certs`, `builds` and `logs`. All the low level details are hidden. I think most people dont want to or shouldn't worry about "containers".
- derefr 10y agoThe thing with "containers" is that they're portable. I want, ideally, to assemble and test my app build in a sort of local micro-copy of the production infrastructure, then push something bit-for-bit identical to that build to the real production infrastructure. Containers easily enable that; source-code-push services leave it an open question. Though, really, if your app uses a lot of fancy IaaS service APIs, even the container-oriented approach still isn't a full answer to enabling dev-time local testability with production parity. (Personally, I'm waiting for a "mock AWS in a box"—a single binary that presents itself as many IaaS service machines on a virtual network interface it creates, without actually doing any of the heavyweight computation required to run e.g. OpenStack's DevStack. So the VMs wouldn't be VMs but just network-IO-level mocks, etc. I'd love to plug that some application Docker containers into that.)
- bizzleDawg 10y agoI'd be really interested to know more about how this compares and contrasts to Elastic Beanstalk (EBS)? particularly the docker flavours of EBS. I've looked through a couple of the previous threads and didn't find much on this.
- avitzurel 10y agoUsing ElasticBeanstalk you still need to "handle" environments, applications. This is a level of abstraction above ECS, which Beanstalk uses behind the scenes for multi-container installations. If you think about it, it's like Heroku for docker, you handle "apps", and the rest is handled by Rack. This is how I understand it.
- nzoschke 10y agoI'd say Elastic Beanstalk is the most direct "competition" because it his the same points: * Simple * Configures AWS resources uniformly run your app * Uses Docker Some advantages to using Convox instead of Elastic Beanstalk: * More flexibility in the experience. Convox has a simpler API and CLI for end users. * More flexibility in the infrastructure. We can pick and choose the best infrastructure components and constantly evolve. * Less lock in. This is speculative but having a thin layer between you and AWS could help with portability.
- kolanos 10y agoI also consider use of docker's own toolchain (docker-compose, docker-machine) to a be a big plus as well. EB has very much an NIH feel with all the JSON manifests and such.
- nzoschke 10y agoThe biggest difference is that Convox is Convox... AWS is awesome but their values might not exactly align with your organization. There are general advantages to letting the Convox team and community guide you through your cloud journey. We value developer experience where AWS simply doesn't. Our plans include things AWS will never add to EBS like automating dashboards, monitoring and alerts. We are moving a lot faster. Convox has swap and CloudWatch Logs integration where ECS doesn't.
- kolanos 10y agoWhat will a newly created rack cost on AWS? Trying this out now, but want to get an idea of what it will cost me. Is there a list of all the AWS services this uses?
- tedmiston 10y agoCame to ask a similar question, or rather, how plug and play are the different services? I'm often thinking of the use case of a hobby app where I might want to run a local database, and for example, using KMS might be overkill. Is that a use case you guys think about or not as much?
- mwmanning 10y agoThe base cost for a rack is about $85/mo. Convox is extremely cost effective for small businesses and up, but would be expensive for running a single, low-traffic hobby app.
- tomc1985 10y agoOy! The name 'rack' is already taken, referring to abstracted-out request-handling glue code that Rails et al are built on top of :/
- hk__2 10y agoWell that’s not the first time two pieces of software have the same name.
- tomc1985 10y agoI know, it's just painful to see two projects so close together sharing a name, esp. after a project is shown to the public
- zeckalpha 10y agoNot unchartered waters for the Convox folks: https://github.com/ddollar/foreman https://github.com/ddollar/foreman (Convox employee) http://theforeman.org/ http://theforeman.org/
- dekz 10y agoHow do you feel Convox deals with the Hybrid approach? Of wanting to use a PaaS App container service, but keep the app dependencies like Cache, ElasticSearch DB hosted by AWS. Does Convox continue to use hosted AWS services? I like the idea of the App being containerised and that workflow, but I cannot convince myself that running DB/Cache in something like Convox is a good idea (vs Hosted in AWS). Can you give your thoughts?
- nzoschke 10y agoOne of the core values of convox engineering is that services are better than software. We do not run dbs as containers other than for dev or testing. 'convox services add postgres' and 'convox services add redis' provisions RDS and Elasticache respectively.
- dekz 10y agoThat is great. What about services which convox doesn't support (yet)? For example SNS. Would convox ever support terraform/cloudformation for an App, or would you add SQS service in convox, then create SNS outside of convox, and then join them together somewhere else?
- nzoschke 10y agoconvox services add [sns|sqs|s3] Is a thing. Automatic provisioning services should be easy. Your rack and all your apps and services are CloudFormation stacks. We favor CloudFormation over terraform for the same reason, it's a managed service. The dream is fully automated provisioning of everything you want inside a single AWS account and VPC. Then you can peer this VPC with another to keep linking things. The framework is open source so it's pretty easy for us or anyone to add more services when requested. SES would be a good one next.