Skip to content

Common challenges in LA new deployments

vjrj edited this page Jul 10, 2025 · 1 revision

Common Challenges in New LA Portal Deployment

Overview

The Atlas of Living Australia (ALA) software stack presents unique deployment complexities compared to typical open-source solutions. This document outlines frequent challenges and recommended approaches for successful implementation of Living Atlas (LA) portals.

Key Deployment Considerations

1. System Complexity

  • The ALA stack is a complex ecosystem of interconnected components (not a monolithic application)
  • Requires DevOps expertise for proper configuration and maintenance
  • Demands deeper infrastructure knowledge than standard, smaller free/open-source platforms (e.g., WordPress)

2. Implementation Approach

Recommended strategy:

  • Begin with a minimal test deployment (core services only: branding, CAS for authentication, solr and cassandra backend, collectory for metadata, biocache for occurrence records, logger, and bie for species information)
  • Gradually add components after achieving stable operation
  • Avoid premature customizations before fully understanding the base system
  • Follow ALA’s conventions as closely as possible. For example, use subdomains (auth.yourportal.org, collections.yourportal.org) rather than path-based routing (yourportal.org/collections)—at least initially. This setup is well tested and documented.

Common pitfalls:

  • Deploying all services at once instead of adopting a phased approach
  • Attempting to secure the portal too early
  • Deviating from the recommended architecture (e.g., using paths instead of subdomains) – Not enabling SSL or configuring it improperly
  • Using untested, development, or upstream versions not proven in LA Community production environments
  • Choosing a different deployment method from ALA’s without prior experience
  • Making UI or functional customizations too early
  • Performing tasks manually instead of using DevOps tools like ala-install and related utilities
  • Under-provisioning hardware (e.g., attempting to run all services on a single server or with few servers). ALA typically deploys each service on a separate machine. Installing many services together is a common source of problems and requires additional effort to avoid, for instance, conflicts.
  • Lacking required skills (e.g., DevOps, systems administration)
  • Introducing local customizations that are hard to maintain or upgrade over time, especially if changes are only kept in private or local forks. Sharing the code is not enough — submitting pull requests and working to merge generic improvements into the upstream ALA codebase is key to long-term sustainability

3. Community Aspects

ALA’s software also differs from WordPress or other open-source projects in that it is not developed primarily with the community in mind. Rather, it is built to meet ALA’s internal needs and shared openly under a free/open-source model. As a result, the broader LA community often needs to adapt the software to cover features ALA does not prioritize—such as internationalization or alternative use cases. It also differs in terms of documentation and support practices, requiring the community to fill many of those gaps collectively.

Clone this wiki locally