Infrastructure architecture satisfies a number of non-functional requirements (NFRs) of the solution. These usually are security, scalability and maintainability related requirements.

High level Athena infrastructure architecture

High level Athena infrastructure architecture

NFRs that Athena satisfies

  • Personal Data protection - deployed services and applications store data on encrypted data volume.
  • Secure communications - communication with deployed services by default are encrypted using SSL (2048 bit keys) and use SSL Authentication. Network Firewall rules are enabled to make sure that users can access deployed web applications only through Web Application Firewall.
  • Recovery - athena infrastructure is built and maintained as a code and is part of the same change, release and build process as solution service and application code. Infrastructure is destroyed and rebuilt as part of continuous integration regression testing and thus is always recoverable from the scratch in very short period of time
  • Resiliency - services are deployed in a resilient configuration and are accessible through load balancers
  • Disaster recovery - athena infrastructure is built for automatic disaster recovery with AWS multi zone (multiple data centers) design as a primary implementation. Disaster recovery environment is always available and participates in handling of incoming user requests. Should one data center become unavailable, all traffic is automatically routed to available data center. Should both data centers become unavailable it is possible to rapidly recover infrastructure and services an restore service data from backups thanks to Automated deployment.
  • Scalability - athena infrastructure scales automatically depending on a system load, with AWS Autoscaling groups being as primary implementation for auto-scaling.

Deployment zones

Deployed services are split into deployment zones based on their scalability, availability and security requirements as well as to provide basic internal communication architecture to prevent certain attack vectors if one zone would get compromised. If for example Public zone servers become not accessible due to high system load it should not affect availability of services deployed in Backoffice zone (for example content authoring services).

  • Public - zone for services (web applications such as CMS content publish services and web services such as REST APIs or SOAP services) that are available to general public and are consumed either directly by users or by user devices
  • Backoffice - zone for services which are used by internal or backoffice users via Web Application Firewall (WAF) using SSL Authentication. For example CMS content authoring service, user management services, monitoring and service management services.
  • Internal - zone for services that are used by public and backoffice services to store data or application state such as Relation and NoSQL databases, message queues, batch processes, schedulers, etc.
  • Exchange - zone for services which are exposed to external partners but not general public such as REST/SOAP APIs and SFTP services for file exchange.
  • Bastion - zone of Data loss protection, Web Application Firewall and VPN services

Deployment groups

Deployment groups are used to group services into logical groups to allow vertical scaling of the deployment zone. For example if there are 3 servers deployed in Backoffice zone, environment owner can mark servers to specify which types (groups) of services must be deployed on which server.

Bastion groups

  • SYS - system services (docker agent, consul agent, ntp, etc.)
  • VPN - virtual private network services
  • WAF - web application firewall

Backoffice groups

  • SYS - system services (docker agent, consul agent, ntp, etc.)
  • CRM - customer relationship management tools and services
  • CMS - content management tools and services (authoring)
  • IPA - platform user identity management tools and services
  • BPM - business process management tools and services
  • Pricing - pricing, rating and underwriting tools
  • BO - back-office tools
  • SCM - source code management tools and services
  • DEV - development tools and services
  • SSO - single sign on management tools and services
  • DMS - document management system tools and services

Internal groups

  • SYS - system services (docker agent, consul agent, ntp, etc.)
  • API - internal micro-services
  • RDBMS - relational databases
  • NoSQL - not only SQL databases
  • MQ - message queues

Exchange groups

  • SYS - system services (docker agent, consul agent, ntp, etc.)
  • SFTP - file exchange services

Public groups

  • SYS - system services (docker agent, consul agent, ntp, etc.)
  • API - publicly available micro-services
  • CMS - content management system (publishing)
  • Journey - transactional journeys
  • Portal - customer self service, corporate and agent portals
  • SSO - single sign-on and sign-off services

Host operating system

While Athena deployed services are run as Docker images it is also necessary to bootstrap and maintain “Host operating system” that runs these images as well as facilitate system aspects such as routing, log forwarding and intrusion detection.

Ubuntu server LTS vs RedHat vs CentOS

Assuming that environment owner does not own RedHat subscription:

  • Both are commercially supported Linux distributions. Both provide stable LTS (long term support) channels.
  • Without RedHat subscription enterprise RedHat supported package repositories are not available, CentOS community package repositories or stand alone RPM packages has to be used to install recent versions of such commonly used open-source products as Squid, Apache HTTPD, Nginx, etc
  • Security updates for CentOS maintained packages and stand-alone RPM packages installed on RedHat are not available in a timely fashion. There is no tested and clear upgrade path to upgrade these packages.
  • Ubuntu Server LTS does not discriminate based on availability of subscription which packages are available
  • Ubuntu Server LTS package repositories have good balance between bleeding edge versions of open source products available versus maturity and having a safe upgrade path for supported packages
  • Even if environment owner has RedHat subscription, it is mostly useless for Athena since it is focused on helping to deploy commercial products such as Oracle DB, IBM Websphere, etc. Which are not the first choice for Athena, since Athena focus is to deploy open source alternatives of these products.