Just because you're on-premises today, doesn't mean you will be there tomorrow. And even if your local laws and regulations make it impossible for you to move to the cloud, there are benefits in extending SharePoint in a cloud-ready way.
Every day more organizations are moving to the cloud. Leaving their servers behind, they choose to purchase subscriptions for cloud software and using it focusing on business value instead of operating it.
By far this is not the reality for everyone. There are still plenty of organizations running their own servers, hosting software on their own premises. Some choose to do that, others have to. No matter the reason, it's the reality they need to deal with.
Back in the days, when SharePoint was first released, there was no cloud. Organizations would install SharePoint on their own servers and operate it themselves. As SharePoint evolved, so did the abilities to customize it. And customize we did. I don't think there is a single organization in the world that uses SharePoint out of the box without tweaking it to their needs. And why would you? In the last few years, SharePoint started evolving to become more of a turn-key product. But in the past, it was more of a box of building blocks for you to assemble into the end-product of your desire.
Starting with SharePoint 2007, we got the ability to build Farm solutions. We'd build .NET code that would run on SharePoint servers. The customizations were very powerful and tightly integrated with SharePoint. We could control nearly everything about how SharePoint worked.
But whenever developers did something wrong, the punishment was severe. The whole Farm would become unavailable. Luckily, these occasions were rare. Most of the time, SharePoint would be slow, and no one would know why. And when it was time to patch the Farm, it was a 50/50 chance it would work without any problems.
When Microsoft started hosting SharePoint for their customers as BPOS and later Office 365, they were pretty clear from the start: under no circumstances would you be allowed to deploy any custom code to the Farm. Unsurprisingly, they were operating SharePoint on shared infrastructure for many customers. They couldn't bear the risk of your code talking to someone else's tenant, not to mention bringing down the whole Farm.
So instead, we got new development models like Sandboxed solutions, add-ins and recently SharePoint Framework. All geared towards moving the code away from SharePoint to keep it robust and reliable.
Is it worth it?
If you used to build Farm solutions, you likely don't like the cloud-ready models. Sandboxed solutions are very limiting and using code in them is no longer possible. Add-ins require additional hosting complexity, dealing with authentication, context and loading data on-demand. SharePoint Framework seems very promising... in the cloud. Its subset available on-premises allows you to build only web parts that are far from what you need for building real-life solutions.
So with this, you ask yourself: is it worth it? Is it worth the effort to leave behind what you know, deal with the added complexity and extend SharePoint in a cloud-ready manner?
Before you answer, think back: why did Microsoft provide us with cloud-ready development models? Sure, they need to run SharePoint on Farms shared by many organizations and yet offer their customers the ability to extend SharePoint to their needs. But there is more. Microsoft needs to ensure that they can deliver on the promise of their SLA. They need to guarantee the uptime and need to operate SharePoint as efficiently as possible for it to stay profitable. Your organization is no different.
Whatever recommendation Microsoft has given us, they're based on their own learnings, hosting SharePoint at scale. Whatever Microsoft advises us to do, you can assume it's because it's good for the hygiene of your platform, as a result saving you money and headaches.
Have you started thinking in a cloud-ready way yet?
Photo by Jason Blackeye on Unsplash