{"id":1486,"date":"2015-02-03T11:00:51","date_gmt":"2015-02-03T10:00:51","guid":{"rendered":"http:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/?p=1486"},"modified":"2015-02-03T09:30:40","modified_gmt":"2015-02-03T08:30:40","slug":"officesharepoint-apps-azure-app-pros-contras-que-opcion-elijo","status":"publish","type":"post","link":"https:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/officesharepoint-apps-azure-app-pros-contras-que-opcion-elijo\/","title":{"rendered":"Office\/SharePoint Apps, Azure App. Pros\/ Contras \u00bfQu\u00e9 opci\u00f3n elijo?"},"content":{"rendered":"

Desde anteriores versiones de SharePoint, un problema muy recurrente ha sido introducir dentro de SharePoint todo tipo de aplicaciones, sin mirar si este tipo de aplicaciones tienen que estar en la plataforma o no<\/strong>. Esto provoca fallos, mal funcionamiento de la granja de\u00a0 SharePoint, mala gobernabilidad, descontento de los usuarios y abandono de la plataforma.<\/p>\n

Microsoft, escuchando todos estos feedbacks por parte de los usuarios, introdujo en su versi\u00f3n 2010 las soluciones llamadas \u201cSANDBOX\u201d<\/strong>. La idea era que se pudiera desarrollar aplicaciones dentro del contexto de soluciones pero un una \u201ccaja\u201d separada a SharePoint y cuyo funcionamiento no provocar\u00e1 fallos en la granja. \u00a0Esto era la teor\u00eda, porque en la pr\u00e1ctica las soluciones Sandbox eran muy limitadas, no eran escalables y provocaban fallos en la granja.<\/strong>\u00a0Todo ello, lo que provoco es que no se usaran y que en la siguiente versi\u00f3n de SharePoint se declarasen obsoletas por Microsoft.<\/p>\n

\"Evolution\"<\/p>\n

La alternativa a este primer intento, fue el Modelo de desarrollo de Apps<\/strong>. Este modelo intenta imitar el \u00e9xito de las aplicaciones en los dispositivos m\u00f3viles y que las empresas consumieran apps de la misma forma que un usuario lo hace a nivel particular.<\/strong> Ahora bien, este modelo naci\u00f3 con muchas lagunas que han provocado la no adopci\u00f3n por parte de la gran mayor\u00eda de empresas. Desde mi punto de vista, el principal motivo ha sido que es necesario que tengas tu propia infraestructura (bien en la nube o en tu propia infraestructura), lo que supone un coste muy dif\u00edcil de asumir sin saber cu\u00e1nto va a ser el retorno. Sin embargo, este modelo de desarrollo unifica el poder utilizar el lenguaje de programaci\u00f3n, el alojamiento que se quiera, lo que puede provocar que el n\u00famero de desarrolladores de SharePoint se incremente de forma considerable.<\/p>\n

De la misma forma en la que Microsoft ha ido introduciendo el modelo de desarrollo en SharePoint, ha ido potenciando y mejorando su plataforma IAS y PASS (Microsoft Azure y Office 365). El\u00a0escenario d\u00f3nde antes SharePoint era la pieza clave, pasa a verse un poco eclipsado por el Cloud.\u00a0<\/strong>De la misma forma que se hab\u00eda planteado el modelo de desarrollo para Office 365 fuera necesario hacer uso de SharePoint Online, Microsoft da la posibilidad de consumir los servicios disponibles en su plataforma de productividad haciendo uso de Autenticaci\u00f3n contra un directorio Activo en Azure y consumiendo servicios Rest.<\/p>\n

Partiendo de esta situaci\u00f3n, ahora mismo disponemos de dos opciones para extender Office365:<\/strong><\/p>\n