If you’re implementing customizations in Office 365, it’s fair to say that numerous approaches exist now, and that the service has certainly been enhanced as a development platform in recent times. However, one area of potential confusion is around how apps are developed. Developers and other technical folks became used to “the app model” over the past 2 years or so, as a way of implementing custom functionality which ran on non-SharePoint servers (perhaps Azure) and called into SharePoint using remote APIs such as CSOM or REST. But since then, Microsoft have introduced new APIs and authentication models for Office 365 – these sit above the underlying SharePoint, Exchange, Lync/Skype for Business and Yammer services in Office 365, and come with some differences in how the solution must be developed.
Notably, there are also differences in how end-users access the app, and also how administrators can make the app available (e.g. to specific users) in the first place. In all this, the original app model is not going away – SharePoint apps have now been renamed to “SharePoint add-ins”, but they are still are very valid implementation choice. So technical teams working with Office 365 often have decisions to make: should a customization be implemented as a SharePoint add-in or an Office 365 app?
For me, the key is understanding the impact on the different stakeholders – end-users especially, but also administrators and developers. The last group in particular need to understand the capabilities of Office 365 apps (e.g. what the APIs can do), to decide whether the functionality needed by the business can indeed be implemented with this approach.
My presentation
I presented on this topic at the SharePoint Evolutions 2015 Conference, and have now published the presentation deck and demo videos. The deck is shown below, and can also be downloaded from this link: SlideShare - Comparing SharePoint add-ins (apps) with Office 365 apps. There are 3 demo videos, and I’ve added captions to these and published them to YouTube – you can see these if you use the presentation below or obtain it from SlideShare.
Hope you find it useful!
7 comments:
Thanks for the presentation.
But I seriously doubt how many organizations are having both Azure AD and Office 365 before we talk about office 365 apps development.
@kesav7902,
Well, any organization using Office 365 will automatically have Azure AD, because that's the directory service (containing users, and handling authentication for example) behind Office 365.
I might be missing your point though - can you rephrase it perhaps?
Cheers,
COB.
My first point is that its not mandatory to have Azure AD for every office 365 tenant though internally it might be using it. if you login it will say you dont have subscription even i am the admin to an office 365 tenant.
So I dont think every organization will have Azure AD. Most organization will have only ADFS configured for office 365 to work with on-prem AD via single sign on. In this scenario, i believe its not worth going with office 365 app development.
Following up on the comment from @kesav7902, I think what he means is that a lot of organisations will have an O365 tenant, but they won't have signed up for an Azure tenant and therefore won't have the Azure Portal UI to allow them to get to the Azure AD screens.
Of course every O365 Tenant has an Azure AD behind it, but unless a company explicitly chooses to sign up for an Azure tenant they don't have any way to manage O365 Applications.
This to me is quite a big issue at the moment, I've been thrashing out a decision point on what direction we should go with some of our (albeit simple) generic business applications that we want to sell on the marketplace.
Our target customers definitely have O365 and so they can add Apps (to soon to call them Add-ins) from the SharePoint store, but it is very unlikely that the customer will have access to the Azure portal and therefore not be able to add the Azure Application.
I also think that it's a bit "too IT" to have to go into Azure AD to manage apps and licenses. If the apps are all SharePoint Apps then the management and licensing can be pushed back to the business to deal with (with of course some IT support).
I also think that the SharePoint Hosted App model with Workflows affords a developer an aspect of running "server side elevated privileges" without having to worry about provisioning any websites to support the app. For O365 Apps I don't see what the alternative of running server side code is other than to have a separate website "somewhere".
Do you know what the guidance would be for a dev who wanted to replicate the functionality of a SharePoint App with a workflow that elevates privileges in the O365 model?
@finarne: I really appreciate for elaborating my doubts in a larger perspective.
Hi @finarne and @kesav7902,
Good comments. OK, I think it *is* fair to say there is a small barrier to actually getting the Azure subscription behind an Office 365 tenancy enabled, but I don't see that step in itself as being a big issue, even in the enterprise. Yes, a credit card is needed during the setup screens, and yes, someone will need to "own" the Azure subscription. But no-one is saying that any costs need to be incurred on the Azure side - the Azure AD piece is free (unless you upgrade to Azure AD Premium), and ultimately this is just the process we need to go through to enable management of this capability.
Additionally, Azure is now better at role-based access, so concerns about someone who can administer one aspect being able to (say) create virtual machines in Azure and leave them running are much reduced these days.
So, I think this activation step is perceived as more of a barrier than it actually is. I've certainly taken some of our clients through the process recently (across multiple Office 365 tenancies too), and all went well..
To respond on @finarne's point/question about apps and hosting - yes, I do agree that SharePoint-hosted add-ins do present even less of a barrier: at least in Office 365, where the app infrastructure is already configured for you. On-premises of course, you'll need to configure the app domain and deal with wildcard DNS and SSL. But, the model still definitely has its place in my eyes, because there's no need to worry about an external web application and it's hosting.
In answer to the question around elevating privileges in an Office 365 app, well, Azure AD provides a couple of options here. Check out the "Getting an app-only token" section of Build service and daemon apps in Office 365
Good discussion, thanks :)
COB.
Great content + discussions, thanks for sharing your knowledge + thoughts. This will be helpful in establising our development positioning + governance going from strict on-prem (with SharePoint ADD-Ins) to an (initial) hybrid SharePoint deployment.
Post a Comment