Developing 'Apps' with SharePoint 2013
With SharePoint 2013, Microsoft introduced yet another paradigm for developing applications. Applications (or Apps)??!!! Yes. 'Solutions' are called Apps now! In fact everything in SharePoint including its primitive constructs such as Lists, Libraries are Apps in SharePoint 2013. However that doesn't change how they behave and they continue function in same way. So what happened to old school development model, farm solutions and sandboxed solutions that were introduced with SharePoint 2010. Well, they are still there.
Motivation behind sandboxed solutions was to gain more stability and achieve increased robustness in the farm by deploying it into partially trusted environment - "Sandbox". Unlike farm solutions, the code doesn't have full access to the entire server side object model and further, the access to resources through code is restricted with CAS(code access security) policies. For those who have developed or dealt with farm solution must be aware with the fact that a 'bad' piece of custom code in a web part can easily destabilize the entire farm and hence all other applications sharing the farm. Running  custom code in User Code service helped achieving the goal up to an extent but sandboxed solutions were never became popular as there is still custom code running on the server and developer can get away with the restrictions by writing a full trust proxy.Â
True stability and isolation can be achieved only with keeping all custom code out of SharePoint server and that's what precisely Apps in SharePoint 2013 offer. SharePoint Apps(Apps from here on) don't contain any custom code on the server. You may be thinking then they are good only for solutions tailored with out-of-box components with no code. But wait, you can place your custom code at the client in for CSOM(Client side object model). Well one can't put eveything especially critical business logic at the client side so where does that go? The answer is you can move that code in the cloud. With all your custom code running outside SharePoint environment, not only best farm performance and highest degree of isolation can be achieved but also you get a liberty to write your business logic in the environment and programming language of your choice including non-Microsoft technologies such as Java and PHP. Yes, your read it right. Use of common web standards such to communicate between SharePoint and Cloud(or servers on premise or wherever your custom business logic is) makes this possible. If code outside SharePoint has ever need to talk back to the SharePoint, it uses REST calls to communicate along with OAuth tokens.