Big news these days… Microsoft has announced SharePoint 2013’s public Beta! Before diving into all the new & improved stuff in this release, I thought it would help to share some of my thoughts on this release. Over the last 18 months or so I’ve been working with the SharePoint engineering & marketing teams at Microsoft learning, developing, building a delivering a 5-day developer course on SharePoint 2013. You can read more about why we’re the ones to be your go-to resource for SharePoint 2013 training on our website. During this time I’ve formed my own perspective & opinions on this release.
To the Cloud!
Yup, this release has a *ton* of stuff that will move SharePoint as a great platform to the cloud, building on Office 365. Office 365 is a big deal in my mind for one key reason: it brings SharePoint to the SMB (small & medium size business) market. In the past SharePoint was really only viable in an on-premises deployment or one which you bought & installed it within your company. The problem with on-prem is simple: it’s damn expensive for a small business to stand up & use SharePoint… and this is a HUGE growth opportunity for the product. Office 365 was the first real step to this space but the only customizations that were possible are those that could be done with the browser, client-side customizations (with JavaScript or Silverlight) and sandboxed solutions.
Developers had had frustrations with hosted SharePoint as the sandbox was very limiting. Microsoft addressed this by introducing a new concept: Apps. Developers can do so much more with apps while working in an isolated environment. I have another post up on apps which you can read here, but in a nutshell, apps are:
- Safe & Secure: Apps are completely isolated from each other, just like the phone or tablet. There are a few different ways you can build & run apps, but for the most part code doesn’t run on the SharePoint server (unlike the sandbox). Code either runs in the client (JavaScript) or external to SharePoint (cloud, IIS, etc). Apps are also secure in that they are granted permissions, not just assuming the permissions of the user, via the new Oauth support in SharePoint 2013.
- Flexible: Apps can make calls to external services unlike sandboxed solutions. This is done either through the client or external from SharePoint. They can also call back into SharePoint with an incredibly robust CSOM or REST API layer that’s been improved in this release.
- Easier to Build [than Solution Packages]: I suspect this is the crux of why a lot of existing SharePoint developers will fret over apps. Why are they easier to build? Because you don’t have to know the SharePoint API or SharePoint-isms as much as you did in the past. You only need to create a SharePoint app to manifest your logic which could be written in the client (as in an HTML5 based app) or to surface your external investments built using ASP.NET, MVC or any other technology (PHP/Java even) running externally to SharePoint (IIS, Azure, or some other cloud)! This should bring SharePoint development to more people without having to learn all the SharePoint-isms increasingly democratizing the platform.
- Clean Install/Upgrade/Uninstall Semantics: Previously installing your solution packages wasn’t that hard, but you had to plan ahead for the upgrade story and sometimes the uninstall story. With apps the semantics are much cleaner… much like the way we deal with apps on our phones.
- Healthier SharePoint: Apps don’t allow server-side code in SharePoint… period. This is very different from sandboxed solutions which could use a subset of the API. Nope… apps can’t have any server-side code in SharePoint. It’s all in the client or external to SharePoint.
Don’t mistake me for saying “solutions are dead”… there are plenty of times they make much more sense over apps. Many people won’t build apps when they see what it means. In fact I wouldn’t be surprised to see on-prem deployments having zero apps and sticking with solution packages. Time will tell…
What’s new for On-Prem?
I don’t think some folks at Microsoft would care for this statement, but let’s face it: this release is mostly about the cloud. Sure, there are big improvements to the platform for on-premise deployments, but the bulk of the new stuff is all to facilitate cloud deployments. In order to make the cloud work Microsoft had to come up with the new SharePoint App Model and to support it, introduce OAuth support as well as double down on their client side object mode (CSOM) and REST API’s… frankly, that took a lot of time. So what’s new for on-prem deployments? There were dramatic and significant improvements to search, ECM & WCM.
Search Is Big… Huge… the King!
I can’t stress this enough… the improvements to search are just epic in this release. Microsoft too the best from SharePoint 2010 Search & FAST for SharePoint and merged to two together for a single unified search engine. Everyone will benefit. But who benefits the most? Arguably Enterprise Content Management (ECM) & Web Content Management (WCM). ECM’s big benefit here is that search is used in the new eDiscovery capabilities SharePoint 2013 has to offer. WCM benefits by becoming a first-class search-based application at it’s core. I’ll write a more (a *lot* more) on WCM in the coming days & weeks but for now just know search if the driver for WCM.
New Workflow Architecture
Talk about a change, this is big! Id put this on par with the same shift from SharePoint 2003 to SharePoint 2007 with respect to Web Parts. Web Parts were “invented” by the SharePoint team and prevalent in SharePoint 2003. However when the ASP.NET team made some platform changes in ASP.NET 2.0 as well as added Web Parts to the core, the SharePoint team said “that’s it, we’re building on top of ASP.NET and getting out of the Web Part business: ASP.NET will do that for us.” The same is true for workflow.
What Microsoft did was create a new product, Windows Azure Workflow (WAW). There’s a hosted cloud version and a product you can install for on-prem deployments. Now when you build workflows you publish to SharePoint, but SharePoint actually hands them off to WAW. When you start a workflow, SharePoint tells WAW to kick off a new instance. WAW then talks to SharePoint via CSOM & REST, authenticating using OAuth, to run the workflow. This makes workflows much more stable, reliable and also much more powerful. SharePoint 2013 still has the SharePoint 2010 .NET Framework 3.0 Workflow Foundation Runtime for existing workflows, but the new ones should be built for WAW.
That’s just a few big things I wanted to highlight… now it’s time to dive in and write about some specific features!