Skip to main content

Architecture and Disaster Recovery

We have built on top of the best in class cloud services available from AWS and from our User Interface, Application Platform through to how data and information is stored, we have selected the right-fit services and technology to deliver a durable, resilient platform for our customers.

Cloud Native​

The Fenergo SaaS application has been designed from the ground up to be Cloud Native. Some of the services and technology we use are illustrated below. Understanding & interacting with these components is not required for our customers as Fenergo are responsible for provisioning and managing the platform.

info

With the exception of using S3 Secure URLs for file uploads and downloads, FenX users are not exposed to any of the underlying config or features of AWS services. The configuration and management of these remain the sole responsibility of Fenergo.

API First​

From a technical perspective, API First is one of the most important concepts to grasp. In creating our SaaS platform, we adopted an API First Strategy to ensure our consumers have the broadest possible options to interact and work with our platform. The key differentiator is that APIs are not an afterthought used to enhance existing functionality, but are used to deliver the ACTUAL functionality of a product offering. Elements like, User Interfaces then become lightweight wrappers around APIs. There are lots of reasons why this strategy is best way to design SaaS applications.

  • APIs are Dynamic A collection of APIs are usually created to deliver a business use case, and that use case is building on a modular collection of functionality. Once made available to customers those customers will derive their own uses and new custom experiences will be created using the same APIs but for differing purposes.
  • APIs are Developer Friendly Well documented, easy to understand APIs will empower developers to create their own implementations without direct hand holding. An API is like a wrapper for functional capability, and developers can include your functionality into their APPs without needing to be concerned about the underlying implementation.
  • APIs support separation of Concerns With well documented interfaces to and from other functional silos, leveraging an API means you only need to be concerned with the contract and SLAs. It is far less likely to create unintended consequences in code, developers just need to adhere to contracts. This results in faster development and more stable implementations.

Command Query APIs​

The majority of the APIs offered by the Fenergo SaaS platform conform to the CQRS (Command Query Responsibility Segregation) Pattern. The logical code execution paths through our application treat requests made to the Command API differently to those made against the Query API. As Illustrated below. Command APIs are used to change and update data where as Query APIs retrieve data. Whilst not intended to be a component level code path, the bellow illustration demonstrates how both command and query logic interact with separate code paths to achieve their outcomes. The Command Query pattern is implemented across all domains where it makes sense and in some cases more traditional APIs are in place (such as Event Ingress or SCIM).

This is more of a Design Pattern that strictly Architecture, but the underlying implementation across all of our APIs as listed in the API catalogue conform to a structure similar to the below illustration, differing only in the application logic and outcomes those domains are targeting.

FenX Physical Architecture​

In keeping with SaaS principals, Feenrgo, as a vendor take responsibility for managing the availability, resilience and composition of our product. Clients are not required to take on responsibility for the inner workings, software perquisites or maintenance of the software, as this is wrapped in the Service Offering. To offer some insights into what we have designed we have included an illustration below of the high level architecture of our SaaS platform.

Some of the concepts assume a basic understanding of how networking and resilience is achieved on the cloud. Fenergo follow the best practice guidelines from AWS including the 6 pillars of the AWS Well Architected Principals. Learn more about AWS Well Architected. Our clients can choose one of the regions where we have deployed and each of our deployments spans 3 Availability Zones within those regions. Learn more about AWS Global Infrastructure

Click Here for a HQ PDF

  • Entry Points: Illustrated at the top are client entry points into the application. If you are using the UI, an application that integrates with our APIs, something like Postman even our Salesforce App, these all connect through the main entry point URLs.

  • DNS Services: Amazon provides a way for Fenergo to map the URL endpoints into the private hosted cloud space so when clients access main endpoints such as app.fenergox.com they are brought to the login / authentication portion of the application.

  • Security and Networking: Using SaaS offerings from AWS, fenergo has selected security and networking components to ensure traffic is safe and balanced to available resources.

  • Application Components: The actual application itself is made up of several separate domains as illustrated above. At a high level each deployment consists of:

    • Fenergo Identity Service: This allow API Clients and Users to securely authenticate against the application and interact with the functionality.
    • Separate Functional Domains: Dividing the application into separate functional areas following the principal of Domain Driven Design eliminates the drawbacks of monolithic brittle structures which can inhibit speed of development and stability of the end product. These separate interfaces into component functional areas such as Risk, Entity Data, Screening etc... is evident in the Command / Query API interfaces which you can explore in our API Catalogue
    • Notification Domain: A common counterpart to Domain Driven Design is an Event Driven Architecture. Rather than having End-to-End responsibility for all eventual consequences implemented within each domain, domains advertise that events have occurred, publishing the details to a queue where interested downstream systems can subscribe to listen for specific events.
    • Event Sourced Data Changes: All data changes and updates are passed into Fenergo as events In the Order they occur. They are durably handled and then fanned out to interested downstream domains where that data might become a Legal Entity Record, New Risk Model, etc... What remains is an Immutable Time Ordered Message Store. Such a pattern of application design favors speed of response (to the calling User or API Consumer) and eventual consistency of the data to downstream domains. Working in a multi-tenanted platform where peak load can be difficult to predict and spikes of demand from one tenant cannot be allowed to interfere with other tenants, this strategy

Resilient Architecture Overview​

Stepping up a level of granularity from the Application Architecture above, we can see as illustrated below how we have deployed the application across three Availability Zones within each region. The DNS, Security and Networking services from AWS offer the flexibility to logically combine these AZ's into a single application stack. So which zone is servicing a client or consumer request is entirely transparent.

Click Here for a HQ PDF

  • Entry Points, Security and Networking: Exactly as previously described, but load balancing is used to direct clients to the best Availability Zone (least busy) to service their request.
  • AWS Region: Is a geographic location, such as our EMEA Region which is made up of a cluster of Availability Zones. We deploy the application into a region and it is replicated on each of the three Availability Zones.
  • AWS Availability Zone: Is a single data centre separated from other Availability Zones in a Region by at least 50km and powered by different Electricity Grids and Independent Networking.
  • Multi Data Centre Deployment - Single Interface: The interface to an application is the same for clients regardless the AZ servicing their requests. All data is synchronize across the Availability Zones so anything created or updated is persisted to services which span all AZs. The benefit here is that even in the unlikely event of one or two Data Centres going offline, the remaining Data Centre(s) can deliver the application.

Disaster Recovery Multiple Availability Zones​

As per the Resilient Architecture outlined above, what clients get from this deployment configuration is an Always On, Active-Active-Active DR Strategy. Being deployed across multiple separate AZs provides Data Synchronization and Application Availability across 3 distinct Data Centres, whilst from a consumer perspective no logical difference exists. A single or two AZs could go offline and clients would continue to operate as normal on the remaining AZ. RPO and RTO metrics do not apply as the objective is for there to be no discernable impact on the availability of the application and client data.