Elegir componentes de la arquitectura
Durante el proceso de diseño de la arquitectura de un sistema ArcGIS, hay que tomar muchas decisiones relacionadas con las aplicaciones, el software, la infraestructura de apoyo y otros componentes de un sistema. Aunque la mayoría de las opciones son principalmente subjetivas y deben ser decididas por diseñadores experimentados que conozcan los requisitos, las entradas del sistema y el planteamiento, también existen directrices generales que pueden ayudar a tomar una decisión más acertada o a hacerlo con más confianza. Esta sección intentará resumir algunas de las áreas de elección clave, con orientaciones útiles que permitirán a las organizaciones elegir de forma más intencionada, basándose en criterios sólidos.
ArcGIS Online, ArcGIS Enterprise, PaaS y sistemas híbridos
Cada uno de los patrones de sistema proporcionados en este sitio web puede construirse a través de varios patrones de implementación diferentes, incluidos los componentes de ArcGIS Online, ArcGIS Enterprise y ArcGIS Location Platform, junto con las aplicaciones e interfaces relacionadas. Durante el proceso de diseño, la decisión de qué componentes primarios implementar es importante. Esta decisión es válida tanto si el diseño se basa en estos patrones de sistema como si se trata de un sistema empresarial específico y adaptado a sus necesidades.
Tradicionalmente, muchas organizaciones elegían ArcGIS Online o ArcGIS Enterprise como su principal sistema de «portal» para los usuarios y centraban sus esfuerzos en ese único sistema, pero cada vez son más las organizaciones que eligen combinar ambos sistemas en su empresa, centrándose en los puntos fuertes de cada uno y proporcionando una gobernanza clara a los usuarios para que sepan qué sistema utilizar.
La publicación del blog ¿ArcGIS Online o ArcGIS Enterprise? No tiene por qué elegir. proporciona una visión general de las diferencias entre estos planteamientos y algunas orientaciones útiles, junto con una página de documentación detallada en la documentación de ArcGIS Enterprise.
Aunque hay cientos de funcionalidades que comparten ArcGIS Online y ArcGIS Enterprise, existen algunas diferencias clave que pueden orientar las elecciones de diseño.
Diferenciadores clave de ArcGIS Online:
- ArcGIS Online es una oferta de SaaS: Esri es responsable de la implementación, actualización y parcheado del sistema, y todas estas actividades se llevan a cabo con un tiempo de inactividad del usuario mínimo. Los sistemas SaaS son menos extensibles mediante código o aplicaciones personalizadas y, por lo general, cuentan con un conjunto fijo y sólido de funcionalidades que están disponibles para todos los inquilinos.
- Esri ofrece un sólido Acuerdo de nivel de servicio para todos los usuarios de ArcGIS Online. Este SLA garantiza la disponibilidad de componentes específicos de ArcGIS Online, y se proporciona una página de estado para el seguimiento de cualquier interrupción.
- ArcGIS Online es un SaaS multiusuario, en el que los usuarios pueden buscar y acceder a contenido de otras organizaciones (si su organización lo permite), aumentando su acceso a fuentes de datos externas, incluido el ArcGIS Marketplace para partners proveedores de contenido.
- ArcGIS Online está diseñado para hacer uso de la aceleración de la red de suministro de contenido (CDN) para muchas funciones, incluidos los activos estáticos de sitios web, los mapas base en teselas y los servicios en teselas administrados por el usuario, así como las teselas de características de los servicios de entidades alojados. Esto también contribuye a un buen nivel de servicio a nivel global, donde los usuarios alejados de los centros de datos centrales no se ven afectados negativamente por la latencia de la red con el apoyo de la CDN.
- ArcGIS Online proporciona acceso a varias funcionalidades que actualmente no están disponibles en ArcGIS Enterprise, como ArcGIS Hub Premium, ArcGIS Data Pipelines, la integración con ArcGIS Location Platform y el sitio para desarrolladores de Esri.
- Como sistema SaaS orientado a Internet, ArcGIS Online está disponible automáticamente a través de Internet para cualquier usuario o dispositivo móvil. No es necesario que una organización administre DNS públicos, certificados o parches para vulnerabilidades de seguridad; todo esto lo proporciona Esri directamente a través de ArcGIS Online.
- ArcGIS Online ya está acreditado para varias normas de seguridad y se somete a rigurosas pruebas de seguridad, planificación e implementación con cada versión. Alcanzar un alto nivel de seguridad de la infraestructura con un sistema SaaS puede ser significativamente más rentable que crear su propio sistema.
Diferenciadores clave para ArcGIS Enterprise:
- ArcGIS Enterprise proporciona roles de servidor adicionales con todas las entidades que no están disponibles en ArcGIS Online o que solo lo están parcialmente, entre los que se incluyen: ArcGIS Knowledge, GeoEvent Server, la extensión Data Interoperability para ArcGIS Enterprise, el servidor Production Mapping, el servidor de Maritime Chart y otras funcionalidades.
- ArcGIS Enterprise puede conectarse directamente a sus sistemas de almacenamiento de datos existentes: bases de datos, archivos compartidos u otras fuentes de datos. Los servicios web publicados a partir de estas fuentes muestran y proporcionan acceso de forma dinámica a los datos de sus sistemas de registro existentes.
- Al ser un software que su organización despliega y administra, usted tiene el control sobre cuándo se producen los cambios y las actualizaciones, a diferencia del SaaS, en el que una actualización se despliega para todos los usuarios al mismo tiempo. La administración de cambios para informar a los usuarios de los cambios o probar la funcionalidad de la aplicación antes de una versión está disponible con un planteamiento basado en software.
- ArcGIS Enterprise admite una mayor integración de TI para la autenticación, incluida la autenticación a nivel web, el uso de grupos corporativos a través de AD o LDAP y una especificación más estricta de los protocolos o cifrados SSL y TLS.
- Como software que se ejecuta dentro de su red, es posible la conectividad con otros sistemas de datos de la empresa, incluidas las conexiones directas en tiempo real cuando sea apropiado. ArcGIS Online como SaaS no puede «entrar» en su red para acceder a estos datasets.
- Al ejecutarse en su red, ArcGIS Enterprise también puede compartir contenido más fácilmente con «todos los miembros de la organización» proporcionando servicios abiertos a la intranet, sin necesidad de autenticación como hace un sistema basado en SaaS.
- ArcGIS Enterprise puede utilizarse con un patrón de orientación interna o puede exponerse a Internet y utilizarse para flujos de trabajo orientados a Internet.
- ArcGIS Enterprise, como software construido a partir de muchos componentes, tiene importantes dependencias de software de terceros que pueden complicar el escaneo de seguridad.
- Las implementaciones de ArcGIS Enterprise pueden alojarse detrás de un nombre de dominio de la organización, donde las organizaciones de ArcGIS Online solo están disponibles como
https://<orgname>.maps.arcgis.com
- El uso de los servicios de la ArcGIS Location Platform se proporciona a través de un único sitio web centrado en el desarrollador que ofrece a los usuarios acceso a sus servicios, facturación y controles de accesos en un único lugar.
- Las claves de API están disponibles como patrón de autenticación exclusivamente con ArcGIS Location Platform, lo que permite crear claves de larga duración, pero circunscritas a un servicio o capacidad específicos, y limitadas mediante una lista de referentes permitidos.
- ArcGIS Location Platform utiliza un modelo de pago por uso en el que el uso se traduce directamente en coste, lo que puede dar a los autores de las aplicaciones un mayor control sobre el perfil de costes de su aplicación.
- ArcGIS Location Platform da acceso a servicios específicos que solo están disponibles a través de ese sistema, como el Places service y el Basemap Styles service.
Implementaciones híbridas
Los escenarios en los que se utilizan ArcGIS Online y ArcGIS Enterprise juntos en una «implementación híbrida» también pueden ofrecer ventajas:
- Separar el contenido interno del externo. Algunas organizaciones eligen publicar todo el contenido de cara al público en ArcGIS Online y reservar ArcGIS Enterprise para fines internos, lo que facilita la separación de usos y ayuda a garantizar que los datos se comparten correctamente. También podrían utilizar las funcionalidades de rendimiento (caché + CDN) de ArcGIS Online para administrar los costes sin dejar de ofrecer servicios altamente escalables a los usuarios.
- Apoyo a los casos de uso móvil: algunas organizaciones utilizan ArcGIS Online para habilitar la colección pública de datos a través de Internet por parte del personal o de contratistas (de modo que los dispositivos no necesiten estar conectados a una VPN).
Sistema operativo para ArcGIS Enterprise
ArcGIS Enterprise se admite en diversos sistemas operativos Windows y sistemas operativos basados en Linux, detallados en la documentación de Windows y Linux para ArcGIS Enterprise. ArcGIS Enterprise en Kubernetes se ejecuta en lo que puede considerarse un tercer tipo de sistema operativo, un clúster de Kubernetes, basado en Linux pero al que no se accede ni se opera como un sistema operativo Linux normal.
¿Windows y Linux o Kubernetes?
Decenas de miles de organizaciones de todo el mundo utilizan ArcGIS Enterprise en Windows y Linux; se ejecuta en una implementación tradicional, basada en equipos, en la que los componentes individuales del software se despliegan en «servidores» de hardware o virtualizados diferentes y se combinan en una implementación. La mayoría de las organizaciones tienen experiencia administrando cargas de trabajo de Windows y Linux y se sienten cómodas con este patrón de implementación, que es estable, coherente y preparado para el futuro.
ArcGIS Enterprise on Kubernetes es un patrón de implementación más reciente de ArcGIS Enterprise, previsto para las organizaciones que han invertido en Kubernetes para organizar y administrar sus aplicaciones con contenedores. Para las organizaciones que cuentan con los recursos y el personal necesarios para implementar y mantener software corporativo en Kubernetes, la opción de implementación de ArcGIS Enterprise on Kubernetes separa la administración y el mantenimiento de TI de la administración de SIG, al tiempo que introduce una variedad de características nativas de la nube, nuevos planteamientos de escalabilidad y actualizaciones y parches con un tiempo de inactividad reducido. La mayoría de los miembros de su organización no notarán ninguna diferencia al utilizar ArcGIS Enterprise on Kubernetes en comparación con una implementación en Microsoft Windows o Linux, ya que cada opción de implementación ofrece el mismo portal centralizado e intuitivo de ArcGIS Enterprise y los servicios SIG que alimentan los mapas y las aplicaciones.
En resumen, considere algunas de las siguientes recomendaciones:
- Las implementaciones de Kubernetes de ArcGIS Enterprise suelen ser más adecuadas para organizaciones que ya cuentan con una inversión organizativa en Kubernetes, incluido el apoyo de personal cualificado y normas organizativas para la implementación.
- Las implementaciones de Windows y Linux pueden ajustarse a otras normas de la organización relacionadas con la seguridad, las actualizaciones, los parches u otros requisitos de toda la empresa.
- Aunque la mayoría de las entidades son totalmente comparables, no todas las aplicaciones funcionales basadas en ArcGIS Enterprise están disponibles en ArcGIS Enterprise para Kubernetes. Consulte la publicación del blog de la versión para obtener más información.
¿Windows o Linux?
La mayoría de las organizaciones ejecutan una mezcla de cargas de trabajo en Windows, Linux y otros sistemas operativos o patrones de implementación. Tanto la familia de sistemas operativos Windows como la de Linux son totalmente compatibles y pueden ejecutar ArcGIS Enterprise con eficacia. Los analistas de soporte técnico de Esri conocen bien ambos tipos de sistemas operativos, y la gran mayoría de las aplicaciones y experiencias son compatibles con ambos sistemas. Los requisitos específicos del sistema operativo para Windows y Linux se proporcionan en la documentación de ArcGIS Enterprise.
Algunas de las principales diferencias entre las implementaciones de ArcGIS Enterprise en Windows y Linux son:
- Las extensiones de objetos de servidor (SOE) y los interceptores de objetos de servidor (SOI) se pueden escribir utilizando un patrón de desarrollo .NET o un patrón de desarrollo Java. Aunque las SOE y los SOI escritos en Java pueden funcionar con implementaciones de Windows, Linux o Kubernetes, las extensiones o los interceptores escritos con la versión .NET de ArcGIS Enterprise SDK solo se pueden implementar en implementaciones de ArcGIS Enterprise de ArcGIS Server basadas en Windows.
- Algunas extensiones de ArcGIS Server, como Data Interoperability para el servidor y Production Mapping para el servidor, no son compatibles con los sistemas operativos Linux. Otras extensiones como GeoEnrichment Server o el servidor de Maritime Chart, han agregado recientemente soporte para Linux, por lo que se requiere el uso de un sistema operativo reciente.
- Los escenarios de inicio de sesión único que utilizan la autenticación integrada de Windows (IWA) requieren un sistema operativo Windows para ArcGIS Enterprise.
- Algunas herramientas basadas en Python pueden esperar módulos o bibliotecas específicos de Windows o de Linux, y pueden funcionar en el sistema de un desarrollador que ejecute Microsoft Windows, pero fallar cuando se publican en un entorno ArcGIS Enterprise basado en Linux debido a la carencia de bibliotecas normativas.
- A la hora de solucionar problemas de fuentes de datos, como conexiones a archivos compartidos o bases de datos, la validación y la solución detallada de problemas suele ser más difícil en Linux, ya que ArcGIS Pro no puede instalarse en el sistema para probar ninguna funcionalidad. Para evaluar la conectividad se pueden utilizar herramientas específicas del sistema operativo o bibliotecas de Python y
arcpy
.
A la hora de seleccionar qué familia de sistemas operativos utilizar para una organización, tenga en cuenta algunas de las siguientes orientaciones sobre prácticas recomendadas:
- La experiencia que tenga su organización con un determinado sistema operativo debe guiar su decisión. Por ejemplo, si la mayoría de las aplicaciones de la empresa se ejecutan en Windows, elegir un sistema basado en Linux puede acarrear problemas operativos, ya que hay menos personal informático capaz (o dispuesto) a ayudar en el mantenimiento de los sistemas. Si su sistema operativo no está sincronizado con la norma de la organización, las probabilidades de que falten parches, mantenimiento de claves y monitorización de la seguridad son mayores.
- Al elegir una versión específica de un sistema operativo (o un tipo, con sistemas basados en Linux), pruebe a alinearse con la orientación organizativa existente y elija una versión lo más reciente posible, sin entrar en conflicto con el apoyo de la organización.
- Globalmente, hay un número considerablemente mayor de implementaciones de ArcGIS Enterprise en Windows que en Linux, aunque en general es cierto que los sistemas más grandes y complejos tienen más probabilidades de funcionar en Linux. Esta disparidad general puede afectar a la disponibilidad de personal experimentado de apoyo, especialmente para los clientes globales con soporte en el idioma local.
- Los ingenieros de sistemas que prestan asistencia a su sistema ArcGIS empresarial en la resolución de problemas, la aplicación de parches, la instalación y las actualizaciones deben estar muy familiarizados con el sistema operativo seleccionado, ya que cada uno de estos pasos, especialmente la resolución de problemas, será mucho más rápido si el personal que presta asistencia en ese paso se siente cómodo con el SO seleccionado.
Proveedor de bases de datos relacionales
La mayoría de las implementaciones de ArcGIS Enterprise que utilizan una base de datos relacional eligen SQL Server, Oracle o PostgreSQL (en la documentación de ArcGIS Enterprise se proporcionan los requisitos específicos de instalación del software para cada tipo). Otros proveedores de bases de datos compatibles son DB2, Dameng, Teradata y SAP HANA, que se utilizan generalmente en organizaciones que ya tienen una inversión importante en ese sistema o proveedor. A grandes rasgos, ArcGIS está diseñado para funcionar igual de bien en cada uno de los distintos tipos de bases de datos, ya que no existe un único proveedor mejor o más rápido que pueda seleccionar. Una geodatabase corporativa puede crearse, utilizarse y optimizarse correctamente en cualquier sistema compatible.
En general, la mejor recomendación es utilizar un proveedor de bases de datos que ya sea compatible con su organización, sobre todo si hay personal disponible para ayudarle con los conocimientos de DBA. Muchas implementaciones de ArcGIS, especialmente las que se centran en el acceso o la edición de grandes volúmenes de datos, requieren un apoyo específico del DBA para ayudar en el ajuste, la resolución de problemas, la seguridad y las decisiones de almacenamiento, por lo que alinear la elección del proveedor de bases de datos con la disponibilidad de apoyo es una de las prácticas recomendadas.
Si su organización admite varios tipos de bases de datos, considere con qué sistema puede tener más experiencia su equipo, o si existe alguna limitación de costes o de disponibilidad de versiones que pueda ayudar a tomar la decisión. Considere también el uso de capas de consulta para conectar con otras bases de datos que puedan contener datos empresariales útiles.
Estrategia de almacenamiento de datos
Los sistemas ArcGIS se conectan a muchos tipos diferentes de almacenamiento, más detallados en la sección Datos de la descripción general de ArcGIS. En muchos escenarios, los propietarios y editores de datos tendrán que decidir si alojan los datos en una base de datos o sistema existente o utilizan un componente administrado por ArcGIS como el ArcGIS Data Store. Estos dos componentes ofrecen muchas entidades similares con varias diferencias notables, que se tratan con mayor profundidad en el documento técnico Datos en ArcGIS: administrados por el usuario y administrados por ArcGIS.
También encontrará información adicional sobre los tipos de data store en la documentación de ArcGIS Enterprise.
Proveedor de nube comercial
Como se explica en la sección proveedores y servicios en la nube, a la hora de decidirse por una ubicación o un proveedor de implementación, la experiencia organizativa es más importante que las entidades o preferencias específicas.
A la hora de implementar el software ArcGIS en la nube, tanto si se trata de la primera implementación en la nube de una organización como si es la quincuagésima, la experiencia del personal implicado contribuye en gran medida al éxito. Esto significa que, si su organización de TI empresarial ya tiene experiencia significativa con AWS, puede tener sentido proponer que su implementación de ArcGIS Enterprise se base en AWS, en lugar de Azure. O bien, si su equipo tiene experiencia en la automatización de implementaciones con canalizaciones DevOps de Azure, lo mejor es que siga ese proceso para que pueda beneficiarse de su experiencia y sus prácticas recomendadas.
Métodos o proveedores de autenticación
De forma similar a los temas anteriores, la selección de un proveedor o tecnología de autenticación debe guiarse generalmente por las preferencias y políticas organizativas existentes, como la preferencia por SAML u OpenID Connect, así como por un proveedor preferido, como Azure AD, PingFederate u Okta. Entre las recomendaciones adicionales se incluyen:
- Mientras que la autenticación a nivel web, como la autenticación integrada de Windows, puede funcionar bien dentro de una red, la mayoría de los sistemas incorporan ahora acceso externo o dispositivos no corporativos, que pueden tener más dificultades con un patrón de autenticación a nivel web.
- Asegúrese de que todos sus usuarios podrán llegar a los extremos de autenticación cuando sea necesario. Por ejemplo, una organización puede ofrecer tanto un SAML interno como un proveedor de identidad SAML externo; cuando los flujos de trabajo incluyen aplicaciones móviles, a menos que los dispositivos estén constantemente en una conexión VPN se prefiere el uso del IdP externo.
- Los cambios en el método de autenticación o en el proveedor pueden resultar perturbadores, pero en general lo son menos cuando se utiliza SAML (donde el NameID o nombre de usuario del usuario puede definirse mediante una combinación de atributos).