I started with python on google app engine 3 months ago.
Then I switched to Play2! on Heroku + mongodb and it is a breeze to work with.
I am really far in my project and I want to release the website in the next couple of days. But I just saw the pricing for SSL on heroku, which is really high.
And I don't want to launch my website without SSL. SSL on heroku costs $20/month without the certificate.
I saw some alternatives in this post What cloud platform supports playframework 2.x deployments?
But I am still not too happy. I want to pay as little as possible to start my website.
So at the moment I am looking on Google App Engine again. This would mean that I have to rewrite my whole DB.
Does GAE restrict some features of play2?
I also saw dotcloud but their pricing page is really confusing. I don't know how far I can go with the sandbox mode, and there is a mark on SSL so I think its somehow included but there is also an SSL addon which doubles the price.
I am okay if my website will cost me more then I will get out of it for a few months, but with the ssl on heroku is just too much.
What would you recommend me?
Edit:
Currently I am looking at openshift which looks kinda interesting. They implemented SSL for free to all users, but I am still not sure if I can use this with my custom domain.
Edit2:
Okay it is only shared ssl. Which means I would have to get "Megashift" which costs $42/month
Edit3:
It seems that I can only deploy war files to GAE, which destroys the purpose of play2.
So I would have to choose between heroku, dotcloud and openshift. And all of them are expensive if you want to use SSL.
I would advice you to give openshift a try
It's free, red hat has stated that it will keep a free offering (it's not just during the beta...)
Here's a screencast:
http://playlatam.wordpress.com/2012/05/21/deploying-play-framework-2-apps-with-java-and-scala-to-openshift/
a github repo
https://github.com/opensas/play2-openshift-quickstart
and an article at red hat
https://openshift.redhat.com/community/blogs/supporting-play-framework-on-openshift-with-the-diy-application-type
I doubt that GAE will work properly with Play. The blacklisting of some classes will impact your project with several limitations that you won't have in another environment, and you have the issue of deploying war files (there are plugins for that in Play 2, but still).
Look at it from another point of view:
if your project is a personal "for fun" project with no other aim than trying something, you probably don't need SSL. Even if you really need (or want) SSL, 20$/month is not so much for a hobby, people pay close to that in games like WoW (subscription + extras) each month.
if your project is serious (startup, aiming to get money) you should stop worrying about expenses like 20$. They are investments to get the cash coming. If as a business you are willing to rewrite your code to save just 20$, you are doomed to fail.
I can recommend you Jelastic.
Besides it offers Jelastic SSL and Custom SSL as well at a reasonable price.
Some hosting Providers allow SSL for free for their customers and the price actually varies depending on the Hosting Provider you choose. So you have alternative here.
Jelastic has recently provided a tutorial on how to deploy Play 2 web framework application to the cloud. So you can freely use it as a basis.
Related
Now that my bot is live, I'm trying to understand what the best way is to maintain a production and development version.
My production version is hosted on Heroku and my development version is hosted on my computer and tunneled to a static address. So far, I've been testing the bot by pointing Facebook's webhook from the production environment to the development environment.
This is not ideal for many reasons, which is why I'd like to understand if there's a better approach. It seems like the only way I can do this with Messenger currently is to create a new test page and then a new app that is tied to it and unreleased. Then I can use that test bot via the Messenger app. Is there something I'm missing (i.e., a way to tie my account to a different webhook)?
As far as I can tell, it seems like you have everything set up pretty well. What you described is exactly how I am doing it.
This is not ideal for many reasons
What's not good about it? Can you clarify the question?
EDIT:
Your heroku hosted and local hosted webhook adresses are different right?
You should have 2 of the following, 1 of each for both the release and test version:
Page, App, Server, Repository.
That way, the test and release version are 2 completely separate entities and there is no interaction between them
I'm studying Couchdb right now. It looks like I could use Couchdb as a backend and web server without needing anything else. Am I correct? Do people use Couchdb as a only backend? Are there any disadvantages doing so?
The core team seems to have pulled back from this in recent versions, but a few years ago there was a lot more of a push to run standalone apps straight out of the CouchDB, these standalone apps are called "Couch Apps".
I don't know it was ever really more than a proof-of-concept (ie. I don't know that any significant web app is actually running on this platform), but if you're interested, apparently the tools do all still work, and there's still the http://couchapp.org/ site with a lot of good information.
Update
I want to add that if the problem you're trying to solve is the problem of javascript origin security, then you should know that recent CouchDB supports CORS
I've been developing a web app locally on my local MAMP computer for the last few months. Now I am ready to launch it while continuing to add enhancements/fixes. So, I am wondering what is a good way to implement a development AND production server in order to efficiently manage updates, prevent overwrites, and seamlessly add other developers into the workflow. I also want something that has a minimal learning curve for me. Personally, for whatever reason, I've never been able to fully grasp version control systems like Git or SVN so I am hoping for an easier solution until I am able to invest more info the business.
As I see it, the options that I have are:
Spend more time learning Git before launching. And hoping that I don't break anything while further developing my app.
Buy two hosting accounts. One for Dev and one for Prod, where only I can do the deployments into Prod. I suppose I'd have to keep track of all files we've modified in a spreadsheet that are deemed ready for deployment.
Editing right on the FTP (no Dev server).
Are there any other options that you can recommend? I've heard that there are some new types of Web Hosting companies that can do the heavy lifting...
While personally, I have had good experiences using svn/git for multi-developer websites, I can understand your reticence to start relying on something you are not entirely familiar with. Unfortunately, I do believe that is your best option, but failing that, you might try using subdomains. My former employer would create test area on the disk and point beta.thedomainname.com at it. When bug fixes or upgrades were complete and verified to be working in the beta directory, the entire directory would be copied over to the live domain. Not the most elegant solution, but it worked. It certainly is cheaper than buying two hosting accounts.
Is there a online/cloud-ish app engine with an available Perl option?
I'd like to write and deploy a personal web app that's hosted by some existing web App engine (the app's fairly simple and resource-cheap, but does need small online storage. If anyone cares, it's basically a family-scope shopping list to be used off of smartphones and PC web browsers).
I'd rather not host it on my home PC's Apache, due to concerns about downtime (my broadband connection is less than stable).
The main candidate my investigations uncovered so far was Google App Engine.
My understanding is that Google App Engine only has Python or Java APIs. Catch is, I'm a Perl guy, with zero exposure to Python.
And if so, is that specific engine inferior enough to Google's engine that it would be worth it for me to learn Python just so I can use Google's? (I don't mind learning Python in theory but I am somewhat stressed for time so I'd rather not embark on that particular project for now - I just want to get the app done and use it).
There was an attempt at one point to get Perl running on the Google App Engine (GAE). However if I recall the nature of the GAE made these attempts difficult, and the group behind the push lost momentum.
Perl applications can (and are) easily hosted on AWS EC (Amazon), Linode (a Virtual Private Server (VPS) provider) and several other solutions. Linode specifically has a VPS solution for $20/month that can host a full Catalyst web stack and comes with, as of this writing, 16GB of storage.
For reference: Perl AppEngine - Project to get Perl on the Google AppEngine.
However like perigrin has already mentioned the project as stalled. Though note its stalled and restarted twice now so don't rule out another revival!
I believe GAE as had its growing pains and was just too much of a slippery moving target for the Perl AppEngine developers. With the inclusion of Java on the GAE it is/was hoped that things would settle down a bit.
Remember Google have promised that "other" languages would be introduced to GAE. So Perl and even Parrot VM may well get on there in the future.
Additional references:
Perl on AppEngine - Brad Fitzpatrick
GAE add feature list
PAE mailing list
/I3az/
Your best bet is to just get a basic web hosting account for $5 a month. As a random example, see Geekisp (This is the ISP I use for such things and have had great service.)
This give you most of the benefit of a cloud solution (ie someone else is doing most of your administration work, leaving you free to just handle the content.)
Learning both the Google App Engine API and Python is probably not worth it for an app that will never need to scale, which is the other main benefit of being "in the cloud".
Another option may be Phenona. It's in beta now but looks very promising.
dotCloud will host perl for you.
However, the cheapest plan (32MB of RAM) is $4.32/month
we (a team of about 150) are considering moving our ALM solution from Bugzilla/CVS to Jira/svn/Confluence/Bamboo/Fisheye. SO has a lot of good info on those, but I would be interested to learn about another tool from Atlassian - a Single Sign On (SSO) Crowd, I am considering adding it to the mix for an LDAP integration with our Novell id's.
has someone had any experience with Crowd?
how does it handle 100/200/500 (after recession, that is) users?
any tips/tricks?
would you choose different, open source SSO solutions?
thanks
EDIT:
a year has passed...
We got Crowd and went with ActiveDirectory integration along with internal Crowd directory (for short-term contractors, etc.). So far the solution works just great.
EDIT2:
Another year: still going strong (We have 1K users now). Nested groups is a killer feature, thankfully it is working fine after last point release.
EDIT3:
mid-2012 - 7.5K users - going strong. with a little automation for onboarding (Confluence pages with Ajaxified forms + a little Crowd plugin)
Major disclosure: I'm the Crowd Product Manager. So, apply as much NaCl as you think wise.
I'd be very surprised if you had any issues with 500 users. Especially since Novell seems to be one of the better directory servers in terms of performance. The only time I'd expect to see problems is if your Crowd server and Novell directory server are on opposite sides of the world. Don't do that unless you have to :-)
We have plenty of users connecting thousands of users to JIRA, Confluence, and the Dev Tools with Crowd.
Any issues - drop us a line (sales#atlassian.com or http://support.atlassian.com) and we'll help out.
Cheers,
Dave.
ps: I hope that didn't come off as a sales pitch or "we make magic products that are perfect in every possible way, now give us your money!"
We're using Crowd with about 80 users and expect that number to climb into the hundred when we roll it out for client access. Crowd is important to us because it allows us to integrate Jira and Confluence (the Atlassian wiki) with SSO, which is critical.
Crowd works well for us but it does have some quirks. We are using it to draw authentications from Active Directory. There are some things that are a little inelegant. We need to do some more digging to troubleshoot those.
But that aside, Crowd is a big win for us, for these two reasons:
SSO across Atlassian apps
Ability to have our internal users drawn from Active Directory, and add clients directly to Crowd and not bog down AD
We're very happy with all the Atlassian tools.
I haven't had experience with Crowd on such a large set of users as yours, but I did find it very easy to set up and manage our JIRA, Confluence and SVN instances with Crowd (we only have 25 users). It will handle Apache authentication as well, so I'm planning to switch our various authenticated Web sites to Crowd as well.
According to Atlassian's site, Crowd should easily be able to handle 500 users; there are some useful case studies and Webinar recordings on the site that will tell you more.
I do have few installations of Crowd with over 16000 users, most comming from LDAP/Active Directory and I would say that the performance would not be a problem but there are other problems which Atlassian did considered solving in years:
There is no auto account creation/registration in crowd
None of the Atlassian products allows people to register accounts with an email validation
There is no way to prevent people from creating several accounts with the same email address.
SSO works only if you have only one domain.
If you do no have many users you can configure Confluence to coonect to Jira directly instead of using Crowd. Atlassian products do already have an interal crowd instance in them, but its performance is limited to about 200 users or so (it's more about the number of authentications made, not the total number of users).
Considering the above limitations, I would summarize that Crowd is far overpriced for what it delivers, unless you are getting a free license if you are eligible.
We have also Crowd installed and connected within the Atlassian product family. It is backed by a corporate LDAP (M$ AD). So far it is great and works pretty well.
BUT currently we're struggling with integration of so called custom applications. We have e.g. Prometheus for monitoring data which doesn't have any authentication built in. So we have an Apache 2.4 in front as SSL endpoint. To add authentication we considered integrating it with Crowd. There is a Apache Crowd connector that is no longer supported (which would be fine by me). There are only the sources available, but built on Apache 2.2. We have to use Apache 2.4 (corporate policy) where some of the required API has been removed.
So either we invest considerable amount of time to migrate the Connector to current Apache API or we do something else (like using a generic LDAP connector towards AD). Which makes the whole Crowd idea a bit a two sided sword for us. (We wanted to centralize user management within our project into a single tool like Crowd to get rid of corporate processes and regulations on the central LDAP).
UPDATE: We now use https://github.com/fgimian/cwdapache connector for Apache 2.4 (with slight adaptions it can be built for Ubuntu 16.04). This adds support for Apache Basic Auth with Crowd groups/users.
UDAPTE2: Bitbucket, Jira, Confluence, Crucible work out of the box of course. User migration is a bit cumbersome though (renaming old users and then integrate with Crowd or use unsupported SQLs).
Jenkins 2 and Nexus 3 seem to work fine.
FURTHER DOWN THE ROAD:
Right now I am considering Crowd as a centralized tool for identity and access management for Atlassian products. There it works fine and does what it should. Integrating numerous other applications just sucks since available integrations are not supported/updated.
Example: if you want to have Crowd authentication with nginx there is nothing usable available. There is a OpenId Connect module available, but Crowd lacks support for that (they only support outdated OpenId v2.0). Not even talking about OAuth. There is a Atlassian OAuth library, but Crowd doesn't have it yet (or will ever). Even the Google Apps support will vanish, since Google dropped support: https://developers.google.com/identity/protocols/OpenID2Migration