martes, 10 de septiembre de 2013

Apps vs Sandbox: presente y futuro

Mucho se ha hablado sobre el nuevo modelo de desarrollo de SharePoint, basado en Apps, y de lo que esto supone para las soluciones Sandbox. La mayoría de información que encuentras en la web está basada en opiniones o no es lo suficientemente sólida para ser tomada como referencia a la hora de plantear el modelo de desarrollo que quieres aplicar en tu compañía. A continuación os expongo la opinión que yo tengo sobre este asunto y, lo que os resultará más interesante, la visión que tiene Microsoft a este respecto de cara al futuro.

Lo primero que tengo que decir es que, personalmente, nunca me gustaron las soluciones Sandbox. Veía sus ventajas (básicamente que funcionan tanto en una instalación on-prem como en Office 365) pero también veía sus limitaciones. No hablaré de las limitaciones aquí porque encontraréis suficiente información en la web al respecto, pero sí os diré que para el tipo de soluciones en las que me suelo encontrar involucrado, esas limitaciones eran un stopper total. Con la versión 2013 de SharePoint apareció el concepto de App y con él llegó la polémica. De manera oficial, lo único que encontrabas en la documentación de Microsoft era que las soluciones Sandbox se habían declarado obsoletas y que, en la medida que te fuera posible, utilizases Apps para desarrollar tanto on-prem como en Office 365. Esto no estaría mal si no fuera por un par de detalles: el modelo de desarrollo de Apps, a día de hoy, tiene tantas limitaciones o más como el modelo Sandbox y todavía no hay documentación suficiente como para plantearse un movimiento en esa dirección si tienes una base de desarrollo lo suficientemente grande.

Además de lo expuesto anteriormente, había una serie de consideraciones que hacían que gente como yo se mostrara reacia a hacer un movimiento en firme en alguna dirección. Por un lado, Microsoft había tardado una única versión en descontinuar el concepto Sandbox. ¿Pasaría lo mismo con el concepto App? Por el otro, hay una carencia de información al respecto del número de usuarios de Office 365 y de su naturaleza. ¿Cuántos son usuarios activos de SharePoint Online? ¿Cuántas suscripciones pertenecen a compañías que también tienen una instalación de SharePoint local? En definitiva, cómo de grande es mi mercado potencial. Sin esa información, las empresas se mostrarán reticentes a apostar por algo que, a bien seguro, requerirá una fuerte inversión por su parte. Respecto a la segunda pregunta todavía no puedo aportar nada pero, respecto a la primera, Microsoft ha arrojado algo de luz el respecto, como podéis comprobar aquí.

El resumen es el siguiente: podéis seguir apostando por Sandbox siempre que sólo incluya elementos declarativos. Sandbox no está muerto, pero el código de usuario sí lo está.

Mi conclusión: más armas para seguir apostando por el método convencional y por soluciones de granja que únicamente funcionarán on-prem. Me alegro de no haber invertido demasiado tiempo en migrar todo mi código a Sandbox porque ahora me habrían confirmado que habría sido trabajo inútil. PERO, y aquí viene el motivo principal de este artículo, luz verde para todos aquellos que trabajáis con soluciones Sandbox para continuar haciéndolo siempre y cuando no incluyáis código de usuario.

2 comentarios:

Gabriel giraldo dijo...

Piensas igual que yo en mis 7 años de consultoria de sharepoint veo grandes limitantes en las aplicaciones sandbox , inclusive muchso ensamblados no funcionan con este tipo de .proyectos.
Voto por usar soluciones , control total del codigo , es lo mejor.

Gabriel giraldo dijo...

Piensas igual que yo en mis 7 años de consultoria de sharepoint veo grandes limitantes en las aplicaciones sandbox , inclusive muchso ensamblados no funcionan con este tipo de .proyectos.
Voto por usar soluciones , control total del codigo , es lo mejor.