¿Debe Force.com (de Salesforce.com) considerarse un PaaS, o es realmente solo una API con esteroides?

Lo describo de esta manera:

Imagine su conjunto de tecnología total, comenzando con el “metal” en la parte inferior, la interfaz de usuario en la parte superior y la base de datos y la lógica de la aplicación en el medio. Force.com es el PaaS “más alto”, ya que puede (teóricamente) usar soluciones listas para usar hasta la interfaz de usuario.

Hay mucha tecnología interesante en esa zona media, y depende de usted decidir caso por caso cuándo usarla y cuándo construir la suya propia. Entonces, por ejemplo, no solo hay un modelo de inicio de sesión / seguridad de usuario nativo, también hay un motor de flujo de trabajo que puede enviar correos electrónicos a esos usuarios cuando ciertos eventos se activan en su aplicación. Ese es el tipo de cosas que alentamos a nuestros clientes a aprovechar, en lugar de crear un código personalizado para esa necesidad comercial común.

Cuanto más “baje” la pila de Force.com, menos espacio tendrá como desarrollador para construir algo robusto. No puede tocar el metal o ajustar la base de datos, y tampoco recomendaría construir un motor de flujo de trabajo en Apex. Sin embargo, Salesforce tiene todo el poder de Java para atacar ese problema, por lo que si se apoya en soluciones innovadoras para esa infraestructura, tendrá algo muy robusto.

En el extremo superior de la pila, casi siempre creamos UI personalizadas para optimizar la experiencia del usuario en torno a las actividades y objetivos particulares de sus clientes. (Resulta que me apasiona especialmente UX). Afortunadamente, Force.com le da al desarrollador mucha libertad para hacer este tipo de trabajo.

Soy fácil de encontrar en línea si desea discutir esto más a fondo.

Su primera oración responde completamente a su pregunta. Mi pregunta sería ¿accede a esa aplicación a través de la web? Si es así, ¿no es una aplicación web? Force.com está diseñado específicamente para aplicaciones comerciales transaccionales centradas en bases de datos. Como tal, hay un montón de funciones confiables, confiables y difíciles de crear en sus propias funciones que usted aprovecha sin siquiera pensarlo.

Si considera que PaaS no es un servidor, es difícil distinguirlo de IaaS. PaaS necesita incluir algunos servicios abstractos para el desarrollador para que no necesite codificar todo desde cero. Es por eso que Heroku es PaaS, no tiene servidores y muchos complementos que se pueden aprovechar fácilmente, al igual que los informes de la plataforma Force.com. Con esos servicios vienen compensaciones y éstas existen arriba y abajo del espectro (X) aaS. Cada servicio de componentes está diseñado para funcionar en la gama más amplia posible de aplicaciones y para que nunca cubra todas las aplicaciones, solo la gama más amplia posible.

Y así, el debate sobre la definición de PaaS continúa.

Para ser justos, PaaS aún no ha salido de su infancia y 2012 bien podría ser el año para este surgimiento. Entre los diversos problemas que enfrentan los usuarios con las ofertas de PaaS como Force.com, el menos comentado es el hecho de que los usuarios de PaaS podrían enfrentar la amenaza de bloqueo del proveedor desde dos lados: uno que está relacionado con la QoS y la funcionalidad siendo compatible: los proveedores de PaaS ofrecen una prueba para proporcionar una experiencia de primera mano en este sentido. El segundo es la amenaza de bloqueo asociada con los servicios de alojamiento, a menudo los proveedores de PaaS también proporcionan
los servicios de alojamiento y estos son difíciles de probar en una ejecución de prueba y pueden ser una desventaja potencial a largo plazo. En cuanto a Force.com, es probablemente uno de los más estables del lote de PaaS: Microsoft Azure es el otro, pero sí, de ninguna manera son una bala de plata para todos los requisitos de desarrollo e integración.