Love it, this is great. I'd definitely use it for quick prototypes and hackatons.
It says "No setup, No configuration". But what if I want to configure stuff? For instance, there's a lot of things going on in settings.py.. to name a few:
- setting up the DB
- email config
- celery (tasks and stuff)
How much control do I have on the "cloud"? I.e. if I want to create a folder to put the files uploaded by users? If I want to run background tasks?
Also: How does one switch from dev to production? Does Kite plan to offer a robust solution for production down the road? I'm not overly concerned because since I have a local folder, I can easily deploy it to any vps.
I have dozen of django projects and I'd gladly give it a fair try, let me know: phzbox at gmail.
We wanted zero setup for devs who may just want to get something up and running right away. The video shows the basics, and we definitely realize there is much more to building a web app than that.
We want to make configuring your app and using common services easy without Kite getting in the way. That’s our mission. Although we showed direct shell access to your app in the video, our end goal is to give developers a machine they can call home as their development environment - root access and all.
For databases, we’re making it a simple click to bind a database to your app. Similar to Heroku, we plan to expose different options as a service and they will be connected to your app through the dj_database_url python module (for Django). For beginners, we’ll try to edit your settings to help make this seamless (your settings.py files in this case).
For other services such as email, task queues like Celery, memcached, etc. we plan on taking a similar approach - offer it as a service on a separate machine that can be easily added to your app, or alternatively just install it in your environment if its something very lightweight or serverless (like sqlite).
Like other hosting services we’ll provide storage for things like storing user media, static files.
We’re really aiming to start with development, since there’s this large gap between development and prod that creates serious time-wasting problems that each member of our team has felt. Companies like Heroku are solving the production problem very well, but developers are still left to setup their own environment and deal with problems leading up to prod.
That being said, we see the serious benefit in using the same stack for development & production, and, like others have mentioned, testing, staging, CI. It’s definitely on our mind, and we’d love to see this kind of fragmentation disappear.
Great to see that you’re interested, and we’ll definitely be following up with you soon.
Looks interesting. But, a similar solution exists with a similar name called PageKite (https://pagekite.net/). They do not deploy your application code to the cloud. With PageKite you run your environment locally and then create a tunnel from a public address to your local environment.
I think the only benefit to Kite is if you want your development application to be running from a public address for a long time.
The PageKite approach allows you to have whatever web environment you want and to bring it up/down at will. I have used PageKite for over a year and it has worked very well. It also seems safer, since I wouldn't want to deploy my development changes to a public web site with some unintended security flaw.
While PageKite definitely offers a great way to expose your local web app to others, we want to get rid of the local setup process altogether, so developers can just spin up an environment using our service and start working from their favorite machine.
Our initial target is newer web developers who may find the setup process daunting, or developers who may manage several projects but don’t want to worry about about the details behind setting up different web frameworks and adding new services. As many can attest, setting up Rails isn’t exactly easy, and it can be even worse if you’re not familiar with the command line, or don’t have xcode installed.
We're definitely working on ways to allow developers to work privately and avoid publishing by default.
Thanks - we really want to stay out of your way while taking care of the common pains of web development.
So in the case of git, you can keep using VCS just like before - place your local files in a repo and use the Github app / command line. Our goal is for you to continue to use the workflow you're used to.
I think this would be interesting if you could extend something like packer that was on HN the other day. It's great to instantly have a dev environment for everyone but I'm still more inclined to use one that is the same image as my production box, allowing you to create custome images with packer, vagrant or some similar tool and deploy that to kite would be much more beneficial IMHO.
Overall its a great concept and something I think you'll see done by companies like Heroku as a form of lock-in as teams grow and never really learn how to virtualize their workflow. If you can get on the front of that movement it will be interesting to see where this project goes.
I assume this will be free for the duration of the beta, and I assume you haven't decided (or aren't ready to publish) what pricing and resource quotas will be like?
Some friendly advice: From the homepage, it seems that the focus is on apps in development. This is well and good, but I think your marketing should also mention that you're great for hosting apps in production too. And if you're not great at that, yet, you should try to improve -- for the good and simple reason that, at the end of the day, it's products, not prototypes, that generate revenue for your developer-customers and allow them to pay you.
This is cool - very interested in how well the rails part will work. I see this as a more lightweight alternative to just deploying images, and I think that will be useful for smaller dev teams to reduce setup overhead.
Looks slick, but how is this different from just running "django-admin.py startproject mysite"?
When developing something serious, you typically want to match the stack you will be deploying on. So far, the two easiest (not necessarily wisest) options have been Google App Engine and Heroku, with latter being my choice of late due it running on AWS and "closeness" to S3 and DynamoDB.
Sorry for the delay in answering and thanks for the comment. This is a good question.
Our video is indeed starting a django project for you - we take a step further and let you do that in a click without having to set up a virtualenv, and it's all hosted. This is the basics, but the idea is to move your development onto a hosted server that is the same or much closer to your prod environment.
Ideally, this hosted environment can offer you much more than what you get by installing a different version of everything you’ll be using in production onto your laptop.
Thank you for the clarification. It appears my confusion stems from me doing similar workflows, just with existing tools - when I tinker with either GAE or Heroku, I deploy nearly continuously, which achieves the same results, but on the exact infrastructure that the final version will be deployed on.
I definitely see the benefit for those not utilizing such practice already.
I'd love to use this to develop my Rails applications. I would be using Kite as a 100% staging server to test things out before pushing to production. I don't have to worry about setting up different RVM gemsets for different apps.
Good to hear - I’ve definitely visited gem dependency hell, and been to companies where you had to fight for a staging server. We hope to make Kite a great way to both host your work but also test & stage it in a linux box to avoid any gotchas from developing on a different environment than your prod machines.
I really like this as a solution for spinning up quick cloud apps and splash pages. I was wondering which other environments you are supporting at the moment because I saw Rails, Django and Node.js and quite a few people I had take a look at it where I work asked the same question.
Looks like it could be a useful tool. Just a picky, grammar-related thing: the word "setup" in "Setup Rails, Django, databases, search engines & more in seconds." should be "set up", two words, since you're using it as a verb.
I did notice fan noise increasing steadily in the background. Hopefully those issues will be sorted out before release or are caused by the screen casting software. At the very least, its presence indicates an honest demonstration.
Great question - file syncing in general can lead to so many problems. We're working on making it play well for single developers with multiple clients/workstations. Our goal is to really provide an awesome infrastructure to host your dev environment that you can access from anywhere. Conflicts could still arise with a single developer as they work on different machines, but we're trying to make it easy to merge work, such as in the case where one of your machines gets out of sync but still has unpushed changes made to the workspace.
At this point we're not focusing on collaboration between developers. There are incredible companies like GitHub whose core mission is to make code collaboration an amazing experience, and we really want to help developers leverage this while not worrying about environment, config & setup issues.