This is the first post in a series about Beezy´s (evolving) architecture. We will be looking at the different development models (Server, App & Hybrid), how Beezy applies these models and how Beezy envisions a migration from one model to the other.
This post will explain that Beezy´s App architecture suits both on premises and cloud scenarios.
Back in 2011 Beezy started as an on premises server farm solution. The initial Beezy application has been developed using traditional SharePoint server schema and the Server Object Model. This Server Model has proven its success in many projects and installations. The Server Model has many benefits, but also some limitations (that will be covered later in this post).
The main benefit of the Server Model is the flexibility to access the full power of the object model with hardly any limitation. Full trust code allows applications to perform any operation at any level of the SharePoint hierarchy. This is extremely useful when you need a deep level of integration with the SharePoint platform.
This is the traditional on premises schema for the Beezy application:
The Beezy application runs inside the SharePoint context. So it relies on SharePoint´s physical infrastructure, capacity and scalability plans. Beezy is just one more application in the SharePoint farm consuming its own resource quota and offering its API through the SharePoint Web application content. Just like standard SharePoint services do.
Beezy uses several standard SharePoint artifacts as event receivers, timer jobs, Web parts or site templates. All of them consuming the flexible SharePoint Server Object Model when they need to.
Unfortunately the Server Model approach also has limitations. Poorly architected and developed server solutions can put SharePoint servers at risk in terms of resource consumption and stability. Moreover, custom server developments are not migration-friendly when it comes to SharePoint version upgrades. How to manage these limitations?
In SharePoint 2010, the Client-Side Object Model (CSOM) was introduced to build code that executes outside of SharePoint. The CSOM, available in JavaScript, .NET and Silverlight, allows to perform a subset of operations with the SharePoint context using a client API.
SharePoint 2010 also introduced a new development model, the sandboxed solutions. Concerned about the misuse of the server resources by custom developments, the SharePoint team offered a way to wrap custom developments inside a controlled process (a sandbox) where resource consumption, memory leaks, etc. could be isolated and kept under control. Of course, sandbox solutions were much less powerful than server farm solutions. Moreover they were still executed inside the SharePoint infrastructure. Therefor the adoption and popularity of this model was not sufficient to become a successful model. The sandbox solutions with managed code are now deprecated and replaced by the App Model.
In SharePoint 2013, Microsoft has clearly stated that the preferred development model is the new App Model. The code of any development on top of SharePoint must run outside the SharePoint server and connected through the SharePoint logic architecture through Apps, not farm solutions. In order to interact with SharePoint, Apps use the CSOM, which has been considerably improved in SharePoint 2013 with many more operations and possibilities.
The main advantages of the App Model are:
The SharePoint Server Model has not been deprecated by Microsoft. Microsoft has confirmed there will be at least one more release of SharePoint Server. Beezy will keep supporting every new SharePoint Server version. Especially since Microsoft confirmed they will not add any new social features to SharePoint Server. Though Microsoft considers the Server Model as the model that needs to be extinguished. All SharePoint partners and providers have to consider the App Model as a development model for the future.
Besides Microsoft´s focus on cloud, we finally noticed a substantial amount of organisations getting ready for apps. Therefor we have been applying the App Model to newly developed apps focusing on the capture and retrieval of Social Knowledge. More about this app later in a blog post that is not architectural. Furthermore, we are re-architecting our current Enterprise Social Network to the App Model.
Are you interested in Beezy´s overall architecture according to the App Model schema?
Request our Whitepaper: Beezy Architectures: Server Model & App Model. This whitepaper will explain that Beezy´s App architecture suits both on premises and cloud scenarios.
No Comments Yet
Let us know what you think