“Mobile First, Cloud First” is the new Microsoft mantra. You can’t read anything about their strategy under new leader Satya Nadella without reading or hearing those words.

A large part of this “Mobile First, Cloud First” world is Office 365. Now, for several dollars a month, the common man (or woman) has access to Exchange, Lync, Office Web Apps (reading and editing Office applications in Web browsers), Yammer, up to 1TB of personal storage with OneDrive, and SharePoint Online.

For small and medium-sized businesses, the move to Office 365 is pretty much a no-brainer. As we see more and more companies adopt Office 365, and as more and more enterprise customers start to dip their toes in the cloud, we as developers need to make sure we have the tools necessary to help these organizations succeed in their endeavors. So, what does all of this mean from a development perspective?

The SharePoint story
Today, a large portion of the customizations and application development we do in Office 365 will be for SharePoint. I could hear your groan as I typed that, but it’s true. SharePoint Online is an important piece of the Office 365 puzzle for businesses. If you’ve had to do SharePoint development in the past, you know what a frustrating experience it can be. Guess what? Now you get to learn even more because Microsoft has decided to change things up. Maybe this will make more sense after I tell you a little story.

SharePoint development has come a long way over the years, but at its core it has mostly consisted of developing assemblies in Visual Studio and copying those assemblies to your SharePoint servers. In the very old days, this was a manual process, but as SharePoint matured and the tooling got better, a lot of these processes became automated. Developers no longer had to create their own manifest.xml files or manually copy DLLs to your servers. Things got better. The creation of a Web Part became as simple as creating a new project in Visual Studio, writing a few lines of .NET code, and letting some administrator who understands PowerShell deploy the solution. More developers were creating solutions.

In some ways, it became too easy to develop solutions for SharePoint. With a lower barrier to development, many developers were creating very bad solutions that ate away resources, performed poorly, and caused farms to crash. Because many developers didn’t take the time to learn SharePoint, there were a lot of poorly written solutions being deployed to their SharePoint farms. What’s more, these poorly written solutions had full access to everything on those servers.

How many times have you heard a user complain about performance in SharePoint? How many times has a SharePoint user griped that the site keeps breaking? Most of the time the reasons for these complaints come from an uneducated developer. Let’s face it: One of the reasons consultants like me have jobs is because so many people were doing a bad job at SharePoint development.

And this is how things were. Those who were good at SharePoint development were very good and could develop really powerful functionality in very little time. The possibilities were endless!

SharePoint development today: You kids stay off my Farm!

Microsoft now has a problem with “Mobile First, Cloud First” and SharePoint (yes, I realize “Mobile First, Cloud First” was not the official mantra when Office 365 came out, but stick with me). How in the world do you put SharePoint in the cloud and still allow developers to develop? It would have been completely disastrous if the development model for SharePoint didn’t change and bad developers were still deploying solutions directly to Microsoft’s servers. Can you even fathom the support nightmare, the number of crashing sites, and the overall impact to performance? Microsoft had to get the developers off the servers. What did they do?

Its goal was obvious: get those developers off the servers. In Office 365 and SharePoint Online, developers can no longer create custom assemblies that are deployed to SharePoint servers. In fact, in Office 365 and SharePoint Online developers have no direct access to the servers. So, even if you were to attempt to develop a traditional “Farm Solution,” you would have no way to deploy it in SharePoint Online.

What about sandboxed solutions? Sandbox solutions were created for SharePoint 2010 and gave developers the ability to create .NET functionality in SharePoint for a specific site collection, and they could be deployed without direct access to the servers. So, those would be perfect for SharePoint Online, right? Not so fast.

For SharePoint 2013 (including SharePoint Online), sandboxed solutions have been deprecated. This means that although the functionality still works, the main purpose for these solutions is backward compatibility. Sandboxed solutions are only supported for “No-code sandboxed solutions” (NCSS). An NCSS can contain XML used for configuration, but no .NET code.

Wait, am I saying developers can no longer develop Web Parts, Event Receivers, Timer Jobs, Workflows, and the other critical tools that were previously the lifeblood of SharePoint development? How is a developer supposed to get their job done?

Enter the App Model. For SharePoint 2013, Microsoft introduced it as a new way to create SharePoint functionality. In simple terms, a SharePoint App is a Web application. I’m not talking about a “SharePoint Web Application”; I mean a common, run-of-the-mill Web application. The old becomes new again.

The App Model works the same way for on-premise SharePoint 2013 Farms and SharePoint Online in Office 365. There are two flavors of the App Model…

SharePoint-hosted apps
A SharePoint-hosted app is a lightweight Web application that is 100% JavaScript and HTML. Because these apps use only client-side development techniques, there are some limitations to them, including the inability to elevate permissions and complications with crossing site collections.

However, if all you need is access to data in your current site collection, and users don’t need to elevate permission, then SharePoint-hosted apps are a great way to get started with SharePoint development for SharePoint Online. You don’t even need Visual Studio to get started; you can download “Napa” from the SharePoint App Store for free and get started.

If you really want to harness the power of SharePoint-hosted apps, combine them with some great client-side libraries like AngularJS and Breeze to create powerful single-page applications (SPAs). SharePoint MVP, trainer and Microsoft development expert Andrew Connell has a great series on “Using Breeze and AngularJS in SharePoint 2013,” as well as a Pluralsight course, “Building SharePoint Apps as Single Page Apps with AngularJS.” Be sure to check them out!

Provider-hosted apps
What if you need to elevate permissions? What if you need to integrate with your business systems? A lot of the time, client-side development just won’t cut it! That’s why, in addition to SharePoint Hosted Apps, we also have provider-hosted apps. The key thing to note about provider-hosted apps is that these are Web applications that must be hosted on a third party’s server, not Office 365. So, you will need a Web server if you are using provider-hosted apps.

This Web server could be your on-premise SharePoint farm, some Web server in Azure, or that old Linux box under your desk. Yes, you heard me right: that Linux box. Because one of the very cool things about provider-hosted apps is they can be written in any language. You can write them in Java, PHP, .NET, whatever your heart desires. This is because provider-hosted apps are surfaced in SharePoint as an iFrame with hooks into SharePoint for authentication. Yes, you read that correctly, an iFrame (insert your 1990s Web joke here).

There are a lot of developers who have been taken aback that Microsoft would leverage iFrames in a “new” technology. This is not your average iFrame though; it has access to the current SharePoint Context and Security. So, there’s that at least. (But really? iFrames?)

Because of provider-hosted apps, you no longer need to be an expert SharePoint developer to create SharePoint applications. Your Java skills are suddenly relevant in a Microsoft world. This opens up an entire world of SharePoint development to non-SharePoint developers.

Communicating with SharePoint using SharePoint’s APIs
The secret sauce when creating your SharePoint apps are the REST and Client Side Object Model (CSOM) APIs that have been greatly expanded upon from SharePoint 2010.

If you are using JavaScript or .NET, then you can take advantage of all of these great APIs. Using REST or CSOM, you can create, modify and delete Sites, Lists, Users, Roles, and so much more. You can work with search, workflows and event receivers. The list goes on.

If you are using Java, PHP, or some other platform besides JavaScript or .NET, then you will be limited to the REST API. I really like the REST API for a couple of reasons. First of all, you can now test your queries in the browser URL, which helps speed up testing in general. But what’s really huge is that if you use REST to query SharePoint data you no longer have to use CAML. How awesome is that? If you don’t know what CAML is, consider yourself lucky and look at REST before you jump into CSOM (where you will still have to use CAML).

One downside to the REST API is that you don’t have as much functionality as you do with CSOM. With REST, you are going to lose some hooks in Taxonomy, Workflow, E-Discovery, Analytics and Business Data. Additionally, SharePoint REST does not support batch processing. Another SharePoint MVP, David Mann, did a great session at the SharePoint Conference earlier this year comparing CSOM and REST, including performance information.

Finally, SharePoint MVP and development expert Rob Windsor has a course on the CSOM and REST interfaces for SharePoint 2013/Office 365 on Pluralsight. I still go back to this course on a regular basis when I need to remember how to do something. So, make sure you check out SharePoint 2013 Development: Client Object Model and REST API.

As you embrace these growing APIs, you will discover that you miss traditional SharePoint development less and less. You are also building upon a critical skillset for non-SharePoint development. What do I mean by that? Stay tuned to find out.

Is the app model good or bad?
Now, to be perfectly honest, there are a lot of SharePoint developers who are upset about this. And who can really blame them? We developers spent years becoming proficient in a difficult technology. It made sense to us, performed well, and there was very little a good developer could not do. Now, in some ways, we are starting over.

You are going to lose some of the ease of integration with business systems now that you must create provider-hosted apps. That Web Part that used to take half an hour to develop may take longer because you’ll have to create an entire Web application. You now potentially have an additional server to maintain because you need that Web server hosting your provider-hosted apps. There is going to be more upfront work.

Let’s take a look at one of my favorite examples of how this new App Model world is going to give developers more work: the creation of a Custom Action. Using a simple sandboxed solution, the steps to create a custom action to deploy a script are as follows:
1. Open Visual Studio
2. Create an empty sandboxed solution
3. Add an element to the project
4. Enter something similar to the XML below in your element:
<?xml version=”1.0″ encoding=”utf-8″?>
<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>
<CustomAction ScriptSrc=”~sitecollection/SiteAssets/jquery.min.js”
Location=”ScriptLink”
Sequence=”100″>
</CustomAction>
</Elements>

5. Save. Compile. Voila: You are done. It’s literally a five-minute process.

Now, take a look at the blog post from Waldek Mastykarz: “Deploying Custom Actions Using the App Model.” How much more complicated and time-consuming is it going to be now to deploy a simple custom action using the App Model? It’s frustrating just reading about it!

We can also look at it another way: Yes, we have to do more upfront work, but only at first. We need to build a new set of copy-and-paste templates. Soon we’ll have a nice little library, and it will again take five minutes to create a custom action using the App Model because we’ll copy and paste what we did before.

It’s funny how much people hate change. Remember when you first started learning SharePoint development and how much you hated it? How stupid you thought it was? Here we are again with SharePoint developers complaining, thinking how stupid it sounds.

You know who doesn’t hate the App Model? Non-SharePoint developers. I’ve spoken to several groups of Java and .NET developers who hated all things SharePoint and were dreading being forced to do SharePoint development. Guess what happened after I explained the App Model to them. Do you think they got upset and yelled about how dumb it is? No, they were relieved and even excited. They realized their skills as they exist today very much fit into this new SharePoint development world. These wary developers now felt empowered and hopeful.

A word or two about hybrid
At this point, it is very important to note that there is another option for SharePoint development with Office 365, and that is the hybrid approach. This is where you have both an on-premise SharePoint farm and Office 365 integrated together. If you are using an on-premise SharePoint farm, you can still create traditional SharePoint artifacts like Web Parts, Event Receivers, Timer Jobs, and the like.

If you have invested heavily in custom SharePoint development in the past and want to now move to Office 365, you may find that the hybrid approach is the most painless. Indeed, for many enterprise customers, the hybrid scenario is the only one that makes realistic sense for them.

Even though it’s possible to do “traditional” SharePoint development on your SharePoint 2013 on-premise farm, Microsoft has made it clear that the App Model is the future of SharePoint development. Even if you intend to keep an on-premise SharePoint 2013 farm, it would behoove you to embrace the App Model today.

“All future investments will go to making the new SharePoint app model richer and more powerful,” Microsoft wrote on its developer site. “Accordingly, we recommend that all new development should use the new app model whenever possible. In scenarios where you have to develop a farm solution or coded sandboxed solution, we recommend that you design it so that it can easily evolve toward a more loosely coupled development model.”

It’s more than just SharePoint
Here’s a nice little reality check for you: SharePoint is fading as a brand. There will no longer be a SharePoint Conference. SharePoint people are now hanging around the Office areas at Microsoft Conferences. Although SharePoint development is still critical and entwined in everything Microsoft is doing, it is time to take on a bigger mantel and become an “Office developer.”

Office 365 development is NOT just SharePoint development. Way back at the beginning of this year at the SharePoint Conference, Microsoft announced the Office 365 APIs. With these APIs, you can now create applications for Outlook, Word, Excel, PowerPoint and more.

“We’re introducing a new set of Office 365 APIs that expose services across the entire Office 365 surface area in a simple, RESTful way,” wrote Arpan Shah. “We are moving in a direction where you won’t have to develop against SharePoint and Exchange-specific APIs; you will be able to develop against a consolidated Office 365 API set that spans SharePoint, Exchange, Lync, and Azure AD. We’re exposing Calendar, People, Mail and File Office 365 APIs that make interaction with the platform intuitive and easy. One of these platform APIs is the Discovery Service APIs, which allow you to determine the location of related Office 365 services for particular users, including Files, Calendar, and Mail APIs. Another new platform API creates a consistent and unified authentication experience across Office 365, as well as from device apps into Office 365 leveraging OAuth.”

Using the Office 365 APIs, you can now create apps that work the way your users work. Create mobile, contextual apps that help users to interact with e-mails and appointments without having to leave Outlook. Use the PowerPoint APIs to call RESTful services that display live information during your PowerPoint presentations. Interact with Lync, Yammer, SharePoint and OneDrive, across all the other Office applications. The possibilities are mindboggling.

How do you get started? Well, it turns out you can use that same free tool, Napa, to create Office apps as well as SharePoint apps. In addition, check out the Office Dev Center for tools, training, code samples, and much more. Also check out the SharePoint and Office Patterns and Practices site. Microsoft may have changed the game on us, but they have also given us a lot of help to learn to play by the new rules. Where was all this during the SharePoint 2007 days?

So, what does Office 365 mean for developers?
Office 365 means there is a gigantic world opening up for developers. It means developers can leverage their existing skills and start developing applications for SharePoint today. Office 365 development means you can create applications across the Office 365 stack. Create OneDrive apps, Word apps, Outlook apps, Yammer apps, SharePoint apps, and more.

Office 365 development means learning the extensive APIs and becoming very comfortable in JavaScript and REST. You don’t have to be a .NET developer, but you can and should invest time into become proficient in JavaScript if you haven’t already. In this “Mobile First, Cloud First” world, you are going to find circumstances where your only option is to write some script.

One last word: Microsoft realizes they’ve changed the game here, and they want to hear from us developers to make it better. To that end, they created “UserVoice.” Now you can leave your feedback, make suggestions, and let Microsoft have an eyeful. We have a voice now. Let’s use it.

This vast world may seem daunting. It is vastly different, and we are still in the early stages of this genesis. If you want to be an Office 365 developer, this is the path set before us. Let’s face it: Deep down, truly great developers like to be on the bleeding edge. Well, here’s our chance to get cut up.