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
Related
My question is related to the recommended way (going forward) to talk to on-premises Exchange mail box and perform operations on it from an external application programmatically?
EWS APIs and the corresponding SDKs look promising based on a few articles such as this :
https://blogs.msdn.microsoft.com/webdav_101/2018/06/19/about-using-ews-and-powershell/
but there is bit of confusion on whether it will continue to be supported in the future based on this:
https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/
Although the above talks of just o365, the fact that EWS will no longer be invested in, raises the question if new applications for on-premises exchange should continue to use it.
PowerShell, remote PowerShell etc. also might work but it seems less suited for use/integration within an external application and more so for automating operations.
Could someone please throw some light on what is recommended way going forward to work with on-prem Exchange?
Try the Microsoft GraphAPI. Details https://developer.microsoft.com/en-us/graph/graph-explorer here. Sign in. Try the https://graph.microsoft.com/v1.0/me/messages sample. See more examples by clicking "Show More samples" on the left column after you login.
Is it The Way (tm)? I don't know but is very cool. I have some sample code I'm working with, nothing in a format to share, but look like the API covers a lot of territory. Some client-only rules look like they need some work to expose, maybe they'll get beefed up in later releases.
Depends on the type of Application you are trying to write, EWS is going to be around in Exchange 2019 so it will work just fine talking to say 2013, 16 and 19 OnPrem. There are advantages and disadvantages to using EWS vs. the new REST API's but it is application specific and changing fast. But again it depends entirely on the type of Application you are trying to write and what version of Exchange you need to support. And typically newer features that will appear in new OnPrem versions aren't back-ported into older versions. So a great new feature that will work in Office365 and Exchange 2019 may not work in 2016 and you may need to use some of the older legacy API's to achieve the same thing. Bottom line as of today if you are an ISV and need broad coverage support for versions of OnPrem Exchange expect to need to use both EWS and REST. If you are just creating apps for one organization that's going to be migrating to 2019 in the future you'll probably get away with just REST.
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.
I'm going to be creating a few small mobile applications and have managed to find a great online Git repo hosting services that is free. It even comes with online issue tracking software but appears to be mainly geared towards the development team. I was hoping it would also have an interface for end-users to log issues/features and allow them to vote on what they wanted but it does not have this. It does expose an RESTful API but I didn't want to go down that path and wanted something ready to go (once configured).
I don't think I need it to be integrated with the Git repo so having something that is purely standalone would be great but I would definitely want something that is online as I don't want to install software on my local PC.
In summary, my requirements are:
Free or very cheap
Simple end-user interface to allow users
to submit issues/features
Allow end-users to vote on their own or other users issues/features
Visible status of issues/features (i.e. whether they are pending, in progress, rejected, fixed etc)
A more advanced management system for me as a developer to manage the
issues
Some basic reports/charts/graphing would be great
Email/RSS notification of new issues/suggestions would be great too
Something that is ready to go after some configuration/settings.
Can anyone recommend something that would be suitable for this?
TIA
I based my question on a website I saw a while back but couldn't find it. Anyway, I've now found it again (it's called http://www.uservoice.com/). It's not really issue tracking but more of a way of letting end-users report features and allow them to vote on them. The important thing is that it is a very user friendly interface which is perfect for end-users. Obviously, I would then need to maintain issues/features in my own system (e.g. Mantis) and then manually sync features requested in uservoice to Mantis but that shouldn't be a big issue. Anyway, this perfectly meets my needs for my low volume applications at the moment.
I'm looking for a way to give out preview or demo versions of our software to our customers as easy as possible.
The software we are currently developing is a pretty big project. It consists of a client environment, an application server, various databases, web services host etc.
The project is developed incrementally and we want to ship the bits in intervals of one to two months. The first deliveries will not be used in production. They have the puropse of a demo to encourage the customers to give feedback.
We don't want to put burden on the customers to install and configure the system. All in all we are looking for a way to ease the deployment, installation and configuration pain.
What I thought of was to use a virtualizing technique to preinstall and preconfigure a virtual machine with all components that are neccessary. Our customers just have to mount the virtual image and run the application.
I would like to hear from folks who use this technique. I suppose there are some difficulties as well. Especially, what about licensing issues with the installed OS?
Perhaps it is possible to have the virtual machine expire after a certain period of time.
Any experiences out there?
Since you're looking at an entire application stack, you'll need to virtualize the entire server to provide your customers with a realistic demo experience. Thinstall is great for single apps, but not an entire stack....
Microsoft have licensing schemes for this type of situation, since it's only been used for demonstration purposes and not production use a TechNet subscription might just cover you. Give your local Microsoft licensing centre a call to discuss, unlike the offshore support teams they're really helpful and friendly.
For running the 'stack' with the least overhead for your clients, I suggest using VMware. The customers can download the free VMware player, load up the machines (or multiple machines) and get a feel for the system... Microsoft Virtual PC or Virtual Server is going to be a bit more intrusive and not quite the "plug n play" solution that you're looking for.
If you're only looking to ship the application, consider either thinstall or providing Citrix / Terminal services access - customers can remotely login to your own (test) machines and run what they need.
Personally if it's doable, a standalone system would be best - tell your customers install vmware player, then run this app... which launches the various parts of your application stack (maybe off of a DVD) and you've got a fully self contained demo for the marketing guys to pimp out :)
You should take a look at thinstall(It has been bought by vmware and is called thinapp now), its an application virtualizer.
It seems that you're trying to accomplish several competing goals:
"Give" the customer something.
Simplify and ease the customer experience.
Ensure the various components coexist and interact happily.
Accommodate licensing restrictions, both yours and the OS vendor's.
Allow incremental and piecewise upgrades.
Can you achieve all of these by hosting the back end (database, web server, etc.) and providing your customers with a CD (or download) that contains the client? This will give them the "download/upgrade experience" that goes along with client software, without dealing with the complexity of administering the back end.
For a near plug-and-play experience, you might consider placing your demo on a live linux or Windows CD. Note: you need a licensed copy of Windows for the latter.
Perhaps your "serious" customers might be able to request their own demo copies of the back end as well; they'd be more amenable to the additional work on their part.
As far as OS licenses, if your vendor(s) of choice aren't helpful, you might consider free or open-source alternatives such as FreeDOS or linux.
Depending on if you can fit all the needed services into a single OS instance or not...
Vmware Ace or whatever they're calling it nowadays will let you deliver single virtual machines under strict control, with forced updates, expiration and whatnot. But it sounds easier to just set up a demo environment and allow remote access to it.
The issue here I guess is getting several virtual machines to communicate under unknown circumstances - if one is not enough?
An idea then is to ship a physical server preconfigured with virtualisation and whatever amount of virtual servers needed to demonstrate the system.
Using trial versions of the operating system might be good enough for the licensing dilemma - atleast Windows Server is testable for 60 days, extendable to 240 when registering.
Thinstall is great for single apps, but not an entire stack....
I didn't try it yet, but with the new version of thinstall you are able to let different thinstalled application communicate.
But I guess you're right a vm-ware image would be easier
Most of the work I do is with what could be considered enterprise Web applications. These projects have large budgets, longer timelines (from 3-12 months), and heavy customizations. Because as developers we have been touting the idea of the Web as the next desktop OS, customers are coming to expect the software running on this "new OS" to react the same as on the desktop. That includes easy to manage automatic upgrades. In other words, "An update is available. Do you want to upgrade?" Is this even a realistic expectation? Can anyone speak from experience on trying to implement this feature?
At my company we have enterprise installations ranging into the thousands of seats. If we implemented an auto-upgrade, our customers would mutiny!
Large installations have peculiar issues that don't apply to small ones. For example, with 2000 users (not all of whom are, let us say, the most sophisticated of tool users), tool-training is a big deal: training time, internal demos, internal process documents, etc.. They cannot unleash a new feature or UI change without a chance to understand how it fits in their process and therefore what their internal best practices are and how to communicate that to their users.
Also when applications fail, it's the internal IT team who are responsible. Therefore, they want time to install a new version in a test area, beat it up, and deploy on a Saturday only when they're good and ready.
I can see the value in making minor patches more easy to install, particularly when the patch is just for a bug-fix and not for anything that would require retraining, and if the admins still get final say over when it's installed. But even then, I don't believe anyone has ever asked for this! Whether because they don't want it or they are trained to not expect it, it doesn't seem worth it.
Well, it really depends on your business model but for a lot of applications the SaaS model can end up biting you. It's great for a lot of things but for some larger applications the users are not investing as significant amount up front and could possibly move to something else before you've made any money.
See
http://news.zdnet.com/2424-9595_22-218408.html
and here
http://www.25hoursaday.com/weblog/2008/07/21/SoftwareAsAServiceWhenYourBusinessModelBecomesAParadox.aspx
for more information
One of the primary reasons to implement an application as a web application is that you get automatic upgrades for free. Why would users be getting prompted for upgrades on a web app?
For Windows applications, the "update is available, do you want to upgrade?" functionality is provided by Microsoft using ClickOnce, which I have used in an enterprise environment successfully -- there are a few gotchas but for the most part it is a good way to manage automatic deployment and upgrade of Windows apps.
For mobile apps, you can also implement auto-upgrades, although it is a little trickier.
In any case, to answer your question in a broad sense, I don't know if it is expected that all enterprise apps should make upgrading easy, but it certainly is worth the money from an IT support standpoint to architect them to allow for easy upgrading.
If you're providing a hosted solution, I wouldn't bother. Let the upgrade happen silently (perhaps with a notice that you did it). If you're selling an application that's hosted on their servers, let the upgrade decision be made by a single owner, not every user of the app.