SharePoint 2013 On-Premises Vs. SharePoint Online - Which One is Right For My Organization?

As SharePoint Online matures into a viable alternative to its on-premises counterpart, many people are asking the question Which version is right for my organization? As is usually the case, the answer is "It depends". Too often we see this decision being made solely on one criteria (i.e. cost) and not taking into account all of the factors involved. Here I am going to focus on what I regard as two of the main factors to consider: setup/cost/maintenance and customizability.

SharePoint Online is still very new and is changing on a regular basis. The Office 365 Road Map is a great resource and I would encourage everyone to consult it regularly. Also, by "on-premises", I simply mean "not SharePoint Online". A SharePoint 2013 farm may be hosted in a mega datacenter, but for the sake of simplicity, I am calling that an on-premises installation.

That being said, here are some of the main factors that I think are important when comparing SharePoint Online to SharePoint 2013 on-premises environments.

Setup/Maintenance/Cost
Obviously, this is a big one. Installing SharePoint 2013 on-premises requires multiple servers in a datacenter, software licenses, installation, bandwidth, upgrades, maintenance, user licenses, etc. Typically, this also involves at least one person whose job is dedicated to keeping the SharePoint farm running. On the other hand, a SharePoint Online environment can be setup in a matter of hours. Also, as with all cloud-based applications, Microsoft bears the cost and burden of maintaining servers, bandwidth, datacenters, etc. Furthermore, the cost of SharePoint Online is charged as a fixed monthly fee based on number of users, storage requirements, etc.

Customizability
In my experience, many organizations get so caught up in the aforementioned advantages of SharePoint Online that they fail to ask enough questions about whether or not SharePoint Online will be able to meet their needs from a business process standpoint.

With on-premises versions of SharePoint, you can deploy server-side code, deploy files to the file system, alter web config files, deploy custom Master Pages, and just about anything else you need to do to meet the needs of your organization. With SharePoint Online, you can't do any of these things. Even simple things like making branding changes to a Master Page require a whole new level of complexity and must be done using jQuery and JavaScript Injection. Why? Because at any time, Microsoft may deploy a new version of the SharePoint Online Master Page that wipes out any of the customizations you have made directly to the file.

To be clear, SharePoint Online sites CAN be customized with branding, workflows, custom forms and functionality, etc. However, all of these business processes need to be examined beforehand to make sure that the plan for implementation is realistic and can be accomplished.

Neither SharePoint 2013 on-premises or SharePoint Online provide "one size fits all" solutions and organizations must take all factors into consideration when determining which one will best meet their needs. SharePoint Online definitely provides a great option for those organization wanting to roll out a basic collaboration environment in a quick, less expensive manner. However, those organizations whose business processes require more robust applications need to accurately assess whether or not SharePoint Online can be customized to meet their needs before taking the proverbial plunge.

by Rob Aycock via Everyone's Blog Posts - SharePoint Community

Developing SharePoint-Hosted Apps for Office 365

As the popularity of SharePoint Online (Office 365) continues to grow, SharePoint developers must begin to approach development of custom applications from a different angle. The biggest challenge that developers face in this new arena is that SharePoint farm solutions built using server-side code like C# cannot be deployed to Office 365 environments. Therefore, any custom functionality must be developed using the SharePoint app model that was introduced in SharePoint 2013.

This new paradigm for SharePoint development certainly presents a learning curve for developers that will take time to conquer. However, some aspects of this shift will also make things easier. Foremost, SharePoint developers don’t need to setup virtual machines with full-scale SharePoint environments to build SharePoint apps for Office 365 as is required for on-premises development. All that is needed is Visual Studio 2012, or later, and an Office 365 SharePoint site collection where apps can be deployed and tested.

SharePoint App Hosting Models for Office 365

There are two hosting models available for SharePoint Apps for Office 365: SharePoint-hosted and Provider-hosted. The biggest difference between these two models is that SharePoint-hosted apps are installed on and execute within the Office 365 SharePoint site, while Provider-hosted apps are installed on the Office 365 site but require a remote web application, running on either an on-premise web server or Microsoft Azure, where the app is actually executed.

Developing SharePoint-hosted apps is the focus for this tip, so let’s explore that model a little further.

SharePoint-Hosted Apps for Office 365

Since all of the components of SharePoint-hosted apps are hosted on the Office 365 SharePoint site and server-side code such as C# cannot be deployed to Office 365, SharePoint-hosted apps can only contain code that runs on the client-side such as JavaScript (with the SharePoint 2013 JSOM library) , HTML, REST Services, etc. Furthermore, since client-side code runs in the browser, user interaction is required for the code to execute. Therefore, a SharePoint-hosted app could contain a custom form that adds items to a SharePoint list when the form is submitted by the user, but not a timer job that runs automatically every night at 11:00 PM.

Host Webs and App Webs

When a SharePoint-hosted app that contains SharePoint components (i.e. app parts, custom pages, custom lists, etc.) is deployed to an Office 365 site, the app is available from the Site Contents page on the host web where it can be launched. However, the app itself, along with any lists, content types, pages, etc. is deployed to a special website that has its own isolated domain called the app web. Even though the app web has its own isolated domain, the app web and host web are contained in the same site collection.

For example, suppose that an app, with SharePoint components beyond just the UI elements that can be deployed to a host web, is installed on a host website at the following URL:

http://ift.tt/1I3FypJ

The app for SharePoint will be deployed to app web with a URL like the following:

http://ift.tt/1bmFl2E

Notice that the app web URL contains the App ID (bdf2016ea7dacb), which is a hexadecimal number generated when the app is installed.

The following diagram illustrates the relationship between the host web and the app web:

Cross Domain Library

The fact that the client-side code runs in the app web, yet may need to access data from the host web presents an interesting set of challenges for developers. For security reasons, modern browsers include blocking mechanisms that prevent client-side code from communicating across domains. Therefore, by default any client side code running in the app web that is trying to retrieve data from the host web will be met with an “Access Denied” error when executed.

The solution to this challenge is to take advantage of the Cross Domain Library. The Cross Domain Library is a JavaScript file (SP.RequestExecutor.js) that can be referenced in client-side code that runs in the app domain that allows the remote app to successfully access data on the host web.

More information about implementing the Cross-Domain Library, as well as code samples, can be found at http://ift.tt/1I3FAOr.

Developing custom applications using the SharePoint 2013 app model, especially for Office 365, forces SharePoint developers to tackle familiar tasks in a new manner. It also forces developers out of the comfort zone of relying on server-side code to do the heavy lifting in our applications. While JavaScript may have once been used only for interacting with UI design elements, SharePoint-hosted apps built using the SharePoint 2013 JavaScript object model or REST OData services provide a framework for building custom SharePoint functionality for Office 365 that is not only powerful, but also easy to setup, build and deploy.

by Rob Aycock via Everyone's Blog Posts - SharePoint Community