Although my background is focused around SharePoint development, ASP.NET development and Microsoft web technologies, I don’t code any more the amount of code I used to do. If I am lucky enough, I would spend 2-3 months a year to lead the SharePoint development team and make my hands dirty with the code for 4-5 weeks along with overseeing team activities and setting the architectural direction. Even though I am not exposed to code 365 days a year, it is important to note that not only I would keep up with the latest innovations announced whether at TechEd, SPC, Build, and now Ignite, I would also continue to play with these innovations in my lab as much as I can with basic scenarios.
Luckily (or unluckily) for one reasons or another, I have been leading SharePoint development teams over the last 4 years building four different kind of traditional SharePoint intranets with each approach varied (and influenced) from each other either because of client requirements or SharePoint development industry trends.
- Spring 2012 – SharePoint Online 2010, used sandbox solutions with code and content queries approach with Mark Anderson’s SPServices as a provider for cross-site collection communications, no content by search web parts in SharePoint 2010 and no full trust code in SharePoint Online
- Spring 2013 – SharePoint On-Premises 2013 Standard, used full trust model approach, Apps wasn’t supported in SharePoint running on Windows Server 2008 R2, ADFS 2.0, and Sandbox solutions with code was already deprecated. Due to no Content by search web parts in standard editions and full trust model approach, we went wild with all kind of tried and tested – SharePoint 2010 full trust development best practices for the SharePoint 2013 platform.
Having bored you with my credentials, let’s get to the meat of the story. Ever since Microsoft has released SharePoint Online and SharePoint 2013 Apps Model, there has been various announcements, recommendations, and best practices from the community and the Microsoft. Rapid innovations fueled with Microsoft’s cloud-driven approach, confused both industry and developers over the time.
SharePoint Development – Where we came from
When SharePoint 2007 was released, it was clear that SharePoint Full Trust model with server side code is the future and everyone from Microsoft and community (Microsoft partnered with Ted Pattison who wrote one of my favorite books – Inside WSS 3.0) declared it as future of SharePoint development platform. After all, SharePoint 2007 remote APIs were written as ASMX SOAP services when XML and XSLT was ruling web world. Even though Visual Studio tooling wasn’t available when product was released, SharePoint community kindheartedly adopted this model.
Deployment issues of SharePoint 2007 (and BPOS, Microsoft’s dedicated cloud SharePoint offering) full trust model code running on SharePoint servers itself was evident after few years industry adoption, which forced Microsoft to release Sandbox Solutions to alleviate the problems of full trust model (mostly bad development best practices) with the release of SharePoint 2010. SharePoint 2010 also tried to enhance remote framework as proprietary CSOM and industry standard REST APIs. If you have attended SPC09, there was a pretty impressive session from Scot Hillier on why admins should allow only Sandbox solutions from then on. Even with Microsoft’s push for Sandbox solutions as future of SharePoint development, restrictions of this model was never adopted by both developers and industry. Many of us thought that Sandbox solutions was Microsoft’s brainchild to support future version of BPOS, which was released as SharePoint Online 2010 (first version of multi-tenant architecture powered as Office 365) in May 2012.
Fast forward to July 2012 and SPC12, Microsoft announced it’s next wave of SharePoint development platform – Apps Model. Again, Microsoft partnered with Andrew Connell, Ted Pattison, and Scott Hillier to onboard traditional SharePoint developers to the Apps model. SharePoint 2013 continued its investment in remote APIs to please both traditional developers and open source web developers with Unified REST and CSOM APIs. All the issues related to Full trust model running on the SharePoint servers causing upgrade issues, limitations of Sandbox solutions which would run only at the Site collection level under strange resourcing system, and Microsoft’s own cultural transition to adopt web industry best practices, Microsoft decided to offer Apps Model which means code will run outside of the SharePoint servers, in it’s own domain, which would not only make SharePoint deployment stabilized and upgradable but allow SharePoint developers to adopt latest and greatest innovations in web technologies including ASP.NET MVC. Now, it’s been 3 years since Apps Model has been released and in most cases – industry and community has formed their opinions – although everyone agree on running customization besides the SharePoint rather than on the SharePoint, industry is not keen on adopting Apps Model. So why adoption is slow? Faulty architecture again? – Answer is partially YES.
Microsoft initially announced three Apps model – SharePoint hosted model (extremely limited), Provider hosted model (standalone Apps), and Azure Hosted Apps. Microsoft killed Azure hosted apps within 2 years stating scalability and manageability concern. I wasn’t surprised. I am yet to meet someone who had invested in Azure hosted apps. In general, any one who has configured Apps Model on the SharePoint 2013 on-premises farm wants to avoid it all together because of it’s complexity and additional hardware cost. While provider hosted model does provide some benefits (at the expense of complex infrastructure, most of the benefits comes at the remote provisioning patterns from PnP library), SharePoint hosted model is joke in most cases. Like they says, if there is smoke, that means there must be fire. Although there is no verdict on Apps model judgement as of May 2015, rumors are already out there. Industry is already trying their best to avoid complexity of Apps infrastructure for SharePoint On-premises. Majority of the SharePoint developers are not willing to adopt this model and continue to invest on SharePoint full trust and sandbox solutions. If that’s enough, there has been sarcastic (and partially true) blogs stating Apps Model is dying.
Fast Forward to SharePoint 2016 and future of SharePoint development
As far as SharePoint 2016 development platform, here are the key messages and clarifications from various Microsoft speakers at the Ignite 2015 for future of SharePoint on-premises development.
- Farm Solutions will be still supported
- Sandbox Solutions with declarative code will be supported, there will be no further enhancement in Sandbox code service.
- Microsoft will continue to invest in Apps Model, both SharePoint and Provider hosted Apps model would be supported
- InfoPath Form Services will be supported and will work with InfoPath Form Designer 2013, there will be no further enhancement in InfoPath forms service but Microsoft has no replacement story for forms.
- SharePoint Designer won’t be released for SharePoint 2016 and Office 2016, SharePoint Designer 2013 will work fine with SharePoint 2016
My take on these announcements are there is nothing here which would make SharePoint developers to change what they are doing right now on the SharePoint on-premises. They may continue to develop customizations using farm solutions (although it’s not necessary after Office 365 PnP guidance and reusable code) or invest in unspoken sandbox solutions rather than leaning towards equally fatal Apps model. Smart developers may not build any code on top of SharePoint platform but as happened in past, everyone wants to take short cuts and develop fast without thinking of maintenance in future. As long as there is SharePoint on-premises software and unless there are Apps model innovations (both infrastructure complexity and iframe UI), people will continue to develop using Full trust model (and unfortunately using sandbox model).
Trends on Office 365 development platform
Let’s turn our eye to other side of the SharePoint development world – SharePoint Online and Office 365 development. Ever since Microsoft started upgrading all the Office 365 tenants with SharePoint Online 2013 in Q1 2013, innovations in the Office 365 development platform is mind-boggling. If Microsoft ever wants to control the future of the SharePoint development, this was the platform for them. From the get go, they have made it very easy for anyone adopting SharePoint online Apps development by preprovisioning Apps services infrastructure (arguably one of the most complex infrastructure configuration in SharePoint history along with User Profile Sync Service Application in SharePoint 2010 and 2013) and enabling Azure PaaS and ACS for apps hosting platform. Developers who were early adoptors and lucky enough to work on the SharePoint Online customizations projects were flying in blissful world of SharePoint Online Apps development including Azure PaaS development and web technologies innovations like ASP.NET MVC, Angular JS, Knockout JS, and Node.JS.
Ever since Chris Johnson and Jeremy Thake embarked their journey on Office 365 developer program after SPC14, Microsoft gained huge momentum on not only onboarding reluctant SharePoint developers on the Apps platform from many fronts including weekly Office developer podcasts (in parallel efforts from Vesa Juvonen and Steve Walker’s Office 365 Patterns and Practices program) but also innovated on Office 365 development platform itself. Throughout Summer of 2014, Apps model marketing was at its highest peak which culminated into amazing Office 365 and Office Graph APIs innovations announced during TechEd Europe 2014. Annoucements of Office 365 and ADAL APIs were probably first glimpse of Microsoft’s vision of Office 365 as developer platform. In the meanwhile, Microsoft continued their effort on Office 365 PnP program on MVA throughout winter to continue winning SharePoint developers, making it more of community efforts on GitHub and delivered through Nuget packages.
Fast forward to Ignite 2015, out of all the new innovations Microsoft have announced including APIs for Groups and NextGen portals, Office 365 Unified APIs are probably one of the most strategic APIs came out from Microsoft after Win32 APIs in early 90s, ASP.NET released in 2001, and SharePoint solutions and features framework released in 2006. For traditional SharePoint developers, this might be the time to look back and start shredding all their SharePoint server development methodologies and start adapting Office 365 REST APIs, Azure Active Directory as Auth platform, and Office 365 PnP program for code transformation for both SharePoint on-premises and SharePoint Online customization.
In short, my final takeaway here is future of the SharePoint development community would continue to divide depending on what kind of hosted environment they would work and we may experience the trend of traditional SharePoint 2007/2010 development and futurastic world of the Office 365 development.
Personally, my approach and my quick guidance to all the developers would be:
- For SharePoint On-Premises:
- Avoid full trust and sandbox solutions what so ever. Administrators should plan to disable Sandbox code services on the SharePoint farms. Administrators should plan to have governance policies to avoid deployment of custom solutions from the Central Administration.
- Plan to provision SharePoint artifacts using remote provisioning pattern – CSOM APIs reusing Office 365 patterns and practices code. Start investing in the provider hosted apps for remote provisioning and custom business applications. If Apps infrastructure and High Turst (S2S) configuration is not your cup of tea, you may want to use console applications (code based approach) to provision all the SharePoint artifacts from the remote servers.
- For fully integrated custom applications, in extreme cases, if you want to avoid provider hosted model, you can plan to just build ASP.NET standalone web applications and interact with SharePoint CSOM and REST remotely.
- Adopt Office 365 Patterns and Practices for ShaePoint On-premises development and avoid features and solutions framework.
- For SharePoint Online and Office 365:
- Avoid sandbox solutions what so ever.
- Start investing in the Azure PaaS or on-premises provider hosted apps over low trust (OAuth) configuration to host ASP.NET web applications
- Start building custom apps using Office 365 Unified APIs and Azure AD consent framework to build your NextGen customizations.
Last but not least, I would leave you with some of my must have SharePoint and Office 365 development resources. It sounds like road ahead for traditional SharePoint developers is more fun, rejuvenate their careers, and chance to get back to roots of innovative web technologies. Good luck!!!
- Office Developer Platform Program – http://dev.office.com/
- Developer Track Sessions from Ignite 2015 and Build 2015 (This is latest from Microsoft as of May 2015) – http://channel9.msdn.com/Events/Ignite/2015?sort=sequential&direction=desc&term=&r=Development#theSessions & http://channel9.msdn.com/Events/Build/2015
- Developer Track Sessions from TechEd Europe (This is latest from Microsoft as of Nov 2014) – http://channel9.msdn.com/Events/TechEd/Europe/2014?sort=sequential&direction=desc&term=&r=Developer+Platform+and+Tools
- Office 365 for developers MVA Training – http://www.microsoftvirtualacademy.com/product-training/office-development
- Starter Frameworks – Office 365 Patterns & Practices – Github & Nuget Packages