The Genus application model, or “app model”, is a description of the business functionality in your application. Your end-users are using the published version of the application model in their application. Thus, by deploying an application model in Genus, you publish a version and make it accessible for the end-users.
Genus uses a blue-green approach for application model deployment. Blue-green deployment means running two parallel environments and choose which environment the users should be routed to.
This approach minimizes downtime and the risks involved in deployment by:
- Making it possible to test and verify the deployment before users are routed to the environment; and
- Enabling rollback to earlier model version quickly in case of critical error.
A Kubernetes namespace is a way to organize the Kubernetes clusters into virtual sub-clusters. A typical Genus application model is contained in four Kubernetes namespaces that host Genus microservices:
Origin: Directly reads the source application model, and is continuously up-to-date with all changes
Blue: Reads the application model from the blue model deployment
Green: Reads the application model from the green model deployment
Operator: Contains the Kubernetes operator, handling the restart of microservices in blue and green as well as routing to the currently active namespace. The operator namespace also stores user sessions, so that they are preserved when routing is changed between green and blue.
Users sessions are also stored in the operator namespace, so they can be preserved when routing is changed between green and blue.
Origin, blue and green namespaces each host a complete set of Genus microservices (see Runtime Architecture), and can run independently of each other. This means that it is possible to scale down namespaces not currently in use.
The end-users are routed to either the blue or green namespace, depending on which of them is set as the active namespace.
The deployment process of an application model thus involves the following steps:
- The business engineer working in Genus Studio makes changes to the application model. When ready, the business engineer initiates deployment of the current application model to the current passive namespace.
- The Operator automatically restarts Genus Services in the passive namespace, and the new application model is interpreted. The business engineer and other test personnel can now verify the changes in the passive namespace before making it available to all users.
- The business engineer orders a switch of the active namespace (e.g. from blue to green) at a desired time.
- At this point, the Operator automatically changes the ingress to route the users to the new active namespace.
All deployment activities are automatically logged by the Genus platform and are accessible for revision.
The Genus platform is built to be powerful and includes the functionality you need to express almost any enterprise application through visual development. However, to meet the non-functional requirements of your business applications, monitoring and evaluation are important.
A set of predefined alerts are also included, together with Prometheus and Alertmanager. These can be configured to send alerts to various receivers, such as Microsoft Teams, Slack, Pagerduty or by e-mail if something happens that requires immediate attention.
As Genus is usually deployed as part of the core IT infrastructure, we believe in an open approach. Thus, you can easily integrate the monitoring of your Genus applications within your monitoring tool of choice.
Event log monitoring
All microservices write technical logs to the output of the container. These outputted logs can be processed by any tool that reads container logs. However, Filebeat is provided out of the box for this purpose in Genus. The Windows event log is shipped by either Winlogbeat or Fluentd, which can be configured to ship the logs to most log analytics solutions, such as Elasticsearch. Finally, to investigate situations in retrospect, you can access the logs and files through Kibana or your log monitoring tool of choice.
Genus provides a collection of predefined dashboards and searches for Grafana and Kibana to help you get started with your performance- and event monitoring. These dashboards and searches can be customized to meet your specific requirements.
Genus Trace Log
Genus Trace Log is our built-in tool for Business Engineers, assisting them with real-time monitoring of important application events. The web-based tool monitors both client- and server-side events to provide comprehensive information about communication and requests, errors and faults, runtime changes and states, and actual data queries to the database. The tool is used both for debugging and performance optimization during application development.
Genus Trace Log monitors both server-side microservices and client-side communication and events for both Genus Web and Genus Desktop. To get access to monitor events, a user must have the privilege Monitor Trace Log.
Genus Trace Log can also be used to support end-users. If an end-user experiences a problem, time-limited access can be given to support personnel to debug the situation. In this case, the end-user does not need the Monitor Trace Log privilege.
Identity and access management (IAM)
User accounts in Genus are a part of the application model, where each user account is mapped to one or more identity providers (ID-providers) in Genus Studio. This enables multiple ways to authenticate a user and allows you to use your preferred ID provider for a seamless, single sign-on experience. Multi-factor authentication (MFA) is available through the ID providers that offer this option.
The current list of supported ID-providers includes:
- Active Directory FS
- Azure AD
- Genus Native (internal, proprietary ID)
Additionally, Genus supports (and adds support) for Government Official ID providers. Currently, these include:
- BankID (Norway)
- xID by BankID (Norway)
- ID-Porten (Norway)
It is also possible to add custom ID-providers if your preferred provider is not in the lists above.
Generally, we support ID-providers via OpenID Connect/OAuth2.
To allow other systems to communicate with Genus through APIs, user accounts can be associated with generated API keys. A user account can be associated with multiple API keys, providing access to several APIs. The premise of using API keys is that this provides an access key to be used for accessing data or services in the Genus application through REST or SOAP services. These API keys cannot be used as a substitute for traditional ID-provider logon, and do not provide access to Genus Desktop or Genus Web.
Access to the Genus applications is routed through the security model. Through this model, access to data and functionality can be granted to users, and interfaces, on several levels:
- User-specific access
- Access through security group (direct and inherited)
- Access by conditional security
- Data set access (i.e. access restrictions to databases or schemas)
The security model is defined in Genus Studio as part of the application model. This also implies that the security model can evolve and scale with the business functionality you include in your applications, by adding new security groups and security constraints.
Users can be added to security groups and be given access to data sets by system administrators, either in Genus Studio, Genus Desktop or Genus Web.
Genus Studio also provides a complete view of user- and security group access, with advanced functionality for security reviews.