Positioning of Genus
Genus is a powerful low-code application development platform for building sustainable enterprise applications. The platform is based on the principles of model-driven development and metadata-interpretation. Consequently, Genus is built to support evolutionary development of advanced, often mission-critical, business applications that are expected to last over time.
The platform supports advanced enterprise-requirements for security, scalability, high performance, and ease of maintenance. Thus, it is ready to be integrated into any enterprise IT landscape and co-exist with other systems and applications.
Model-driven development (MDD) is a way of developing software applications through visual models rather than code. The model is a representation of the key functional artifacts of the software application; namely the data model, the business- and application logic, the user interfaces, and the integrations with other systems.
The key concepts of MDD are abstraction and automation. Through visual modeling of applications in terms closer to the business domain, MDD abstracts the complexity related to computer code. Further, the model is automatically interpreted by the platform, completely removing the need to generate and verify any code.
There are two significantly different approaches to low-code: code generation and model interpretation. Genus is a 100% model interpreting low-code platform that reads and executes the model directly. Thus, the visually developed model is the actual representation of the application, not an intermediary used to generate code.
Furthermore, there are no opportunities to inject code into our platform, as we believe that this is the only way to achieve sustainable software applications.
The low-code applications built with Genus are interpreted directly by the services in the Genus platform. These services (Genus Services) are based on a microservices architecture, utilizing industry-standard server-side technologies (Kubernetes, Docker, etc.). All microservices are stateless and dynamically scalable, both as multi-containers and multi-threads (scaling up and out).
The platform is built with enterprise application requirements in mind, focusing on security, scalability, performance, and maintainability. To reflect a modern approach to infrastructure, Genus Services can be run on all major public clouds as well as on-premises.
Genus also supports all major database systems (RDBMS) for storage of customer data and application models (metadata). This provides flexibility for customers, as they can choose where and how to run their applications and store their data.
Data storage and data access
The data (customer data) in your application is stored in an RDBMS-database of your choice. Contrary to some other low-code platforms, Genus provides a clear separation of responsibility between the low-code platform and data storage, where the latter is a fully transparent relational database layer.
The data in the database is structured following industry-standard database normalization and can easily be accessed directly from the database. Furthermore, Genus enriches the functionality provided by the database server by adding additional layers of security, auditing, data validation, and data integrity controls.
The open approach to data storage and separation of responsibility also provides additional advantages:
- It allows for advanced optimization of the database by database administrators and database professionals. Furthermore, it opens for external extract, transform, and load (ETL) tools to be used to optimize voluminous integrations.
- It enables reverse engineering of existing data models. Genus can be used on top of any supported relational database. Moreover, built-in tools in the platform can be used to generate a Genus data model to be used directly in the low-code platform.
- It eliminates vendor lock-in. Genus enables customers to access the data directly in other tools or platforms, should it be necessary. The data stored in the database can also be directly exported using standard mechanisms such as ETL tools or database migration tools.
We believe this principle of open and transparent data storage is important to support the variety of application scenarios that can be solved with Genus.
Our platform is built with core enterprise applications in mind. It offers an integrated environment for full-stack model-driven development, deployment, and management of enterprise applications.
The main components are:
- Genus Studio
- Genus Services
- Genus Desktop
- Genus Web
Genus Studio is the multi-user Integrated Development Environment (IDE) to design, build, and deploy low-code applications. The IDE is built around the concepts of model-driven and visual development, where Business Engineers can work together on building advanced enterprise applications. Genus Studio is a Windows 10 client that runs locally on each Business Engineer’s computer.
Genus Studio provides the tools you need for full-stack application development. This includes User Interface Design, Business- and Application Logic, Data Model, Integrations, and Security. Additionally, it provides the tools you need to administer and operate your applications.
Genus Studio has impact control of all changes made to the application model to ensure error-free applications. This means that you will receive a warning if you try to delete an application construct that is being used in other parts of the application model. You can also reference-check any part of the application model to see where it is used elsewhere.
Genus Services is the metadata interpreting runtime environment providing application services to Genus Studio, Genus Desktop, Genus Web, and external service consumers. This component also manages the database connectivity to the Metadata Repository and other data sources for your applications.
End users will not have any direct relations to Genus Services, except as exposed web addresses in their web browsers or API endpoints.
For more information on Genus Services, see Runtime Architecture.
Genus Desktop is a native Windows 10 end-user client for presenting applications. Genus Desktop provides a familiar user interface wrapping for your low-code applications, making them appear as a natural part of a typical business productivity suite.
Genus Web is a client for web browser applications and Progressive Web Apps (PWA). As with Genus Desktop, Genus Web is based on well-known design frameworks, providing an intuitive wrapping for your enterprise applications. However, Genus Web also provides more possibilities for theming and customization of the appearance of applications. This extends the possibilities of what types of applications can be expressed through the platform.
Data- and metadata storage
The Metadata Repository is the database storing the metadata information for your applications (the application model). Any supported RDBMS can be used to hold the Metadata Repository.
Data- and file storage (customer data)
Genus applications can read and write data to any supported RDBMS database. Furthermore, the Data Storage can consist of one or more databases, and Genus can also connect to read-only databases or schemas. For File Storage, Genus can utilize streaming of data to- or from Binary Large Object (BLOB) services.
Genus Services provides the application services responsible for interpreting and executing your low-code applications in a cloud-native microservices architecture. In this section, we will explain the architecture behind Genus Services as well as important aspects behind the runtime execution.
Pure model interpretation and execution
Genus Services reads and interprets models from the Metadata Repository. Based on this interpretation, Genus Services provides services to users through Genus Desktop, Genus Web and API-interfaces.
Differing from most low-code platforms, Genus interprets and executes the model directly. Consequently, there is no code generation or compilation involved in the deployment and execution of models.
This also implies that there are no options for injecting or extending your Genus applications with custom code. This pure, codeless approach to metadata interpretation is the only way to achieve truly sustainable business applications where the platform can evolve and be modernized without impacting your model. Additionally, it is the only way to truly ensure that the security configured in the application is not broken. However, should you need to interact with custom code, this can be achieved by using REST or SOAP services.
Stateless microservices architecture based on Kubernetes
The Genus Services runtime consists of the microservices to interpret and execute your applications. The architecture is based on the principles of coupling and cohesion, where each microservice has a clear role or responsibility and a clearly defined interface.
All microservices are stateless and dynamically scalable, both as multi-containers and multi-threads. The client requests include all necessary information and will be validated server-side to maintain security and consistency.
The microservices are 100% based on Kubernetes and are implemented as a mix of both Linux and Windows Docker containers. This allows for Genus Services to be deployed to all major cloud providers (e.g. Microsoft Azure, Amazon Web Services, or Google Cloud) as well as on-premises.
The microservices are deployed to a Kubernetes cluster, and authentication within the cluster is token-based.
Runtime architecture components
The following overview shows the microservices representing Genus Services.
|Agent Service||Responsible for scheduling and executing modelled agent jobs, which are comparable to batch jobs, running server-side.|
|Authentication Service||Authenticates users via Identity Providers (see “Identity and Access Management”).|
|Authorization Service*||Responsible for authorizing access to different parts of the application through permissions on a metadata level.|
|CardDAV Service||Responsible for handling requests from standard CardDAV clients, such as Microsoft’s, Apple’s and Google’s contact apps. Contact lists or address books can be defined in Genus Studio and can expose any contact-related data to third-party applications.|
|Core Service||Responsible for executing CRUD (Create, Read, Update, Delete) commands on the customer data based on the metadata. This is an essential service to enable codeless, metadata-interpreting applications.|
The service verifies the CRUD commands against the metadata before executing them, to ensure that they follow configured rules for data integrity, permissions, and other security aspects.
|Data Mart Query Service||Responsible for aggregating data and maintaining data marts, enabling advanced dashboard- and analytics functionality. The microservice handles requests and contains logic for running queries towards the data marts.|
|Database Dictionary Service||Helps optimize the communication with underlying databases, building on statistics and Data Definition Language (DDL) requests. The service also provides support for reverse engineering of databases by reading database information (tables, columns, indexes, etc.)|
|File Utility Service||Provides file- and file format services, including email format services and both client- and server-side document merge. This microservice is partly built on top of the third-party library Aspose.|
|Gateway Service||The Gateway Service routes all incoming requests to other microservices within the runtime environment.|
|Help Docs Service||Delivers sections or articles to our desktop- and web clients from the markdown-based help documentation of our platform.|
|Ingress and Load Balancer||The ingress is used to control the routing of incoming traffic. A controller interprets the ingress rules and routes traffic to the correct microservices, while the load balancer routes the external traffic into the Kubernetes cluster.|
|Internationalization Service||Delivers natural language translations and word lists in an i18n format. Enables the Genus applications to be accessible in several languages.|
|Kubernetes Operator Service||Responsible for commands towards Kubernetes to control the pods in a namespace, fetch a microservices version, assign trace level, and route to green/blue namespace etc.|
|Live Update Input Service||Collects live update messages from other Genus microservices.|
|Message Subscription Service||Reads messages in queues (stored in Redis) and sends live updates and trace messages to Genus Web and Genus Desktop clients via web sockets.|
|Metadata Definition Service||Used by Genus Studio to read and write application models (metadata) to and from the Metadata Repository. This service is not used by Genus Desktop, Genus Web or APIs.|
|Metadata Query Service||Responsible for reading metadata from the Metadata Repository to provide application model information to Genus Web, Genus Desktop and APIs.|
|REST Consume Service||Enables the consumption of REST services exposed by third parties from your Genus application.|
|REST Expose Service||Exposes REST services and handling calls from third parties. REST-endpoints are subject to the same security model as all other communication with your Genus applications.|
|Send Mail Service||Responsible for asynchronous mail delivery from your Genus application.|
|SOAP Consume Service||Enables the consumption of SOAP services exposed by third parties from your Genus application.|
|SOAP Expose Service||Exposes SOAP services and handles calls from third parties. SOAP endpoints are subject to the same security model as all other communication with your applications.|
|SQL Execution Service||Responsible for interfacing towards the supported database engines, such as Microsoft SQL Server, Oracle and DB2. This includes database driver handling, threading, etc.|
|Stream Data Service||Provides functionality for streaming of data, including videos, to/from databases or BLOB-storage providers.|
|Trace Input Service||Responsible for monitoring and collecting trace messages from other Genus microservices and making these available to clients through Redis and the Message Subscription Service.|
|Webcal Service||Handles requests from any Webcal client, such as calendar apps from Microsoft or Apple. Calendars are defined in Genus Studio and you can expose any calendar-related data in your application.|
|WOPI Service||Supports Microsoft Office Online clients reading and editing documents stored in your Genus application. WOPI is short for Web Application Open Platform Interface Protocol.|
Genus gives you the freedom to deploy your application where you want it. Your Genus applications can be deployed in any cloud environment, on-premises, or in any third-party hosting environment.
All components used in a Genus deployment architecture are standardized, and the required components are:
- A DNS setup providing mapping of your domain names towards a load balancer.
- A load balancer of your choice, like Azure and AWS’s default ones or MetaILB.
- An ingress controller of your choice like Traefik or ALB (Amazon).
- A Kubernetes installation on a cluster of both Linux and Windows Virtual Machines (nodes).
- A database of your choice, such as Microsoft SQL Server, Azure SQL Database, Oracle, DB2 or Amazon Aurora (MySQL).
The components are illustrated in the diagram below.
The Kubernetes command-line interface (Kubectl, or any tools built on top of it) allows your administrators to run commands towards the Kubernetes cluster. This includes the deployment of Genus microservices, inspection and management of cluster resources, and to view detailed logs.
The Helm command-line interface (CLI) is used by your operations team to manage Genus releases in the cluster.
Genus uses an Azure Container Registry to store Genus container images ready for deployment into your cluster.
Genus connects to a range of ID Providers for secure access to the cluster. For more information, see Identity and Access Management (IAM).
Genus utilizes the standard high-availability features within Kubernetes, which basically comes down to setting up multiple Kubernetes master nodes, and a sufficient number of pods for each service spread across underlying nodes, the Ingress controller service included. Your load balancer and DNS also need to be set up with standardized high availability features.
To provide disaster recovery one needs to set up clusters and databases in multiple regions or availability zones with configuration, data replication, and backups. Although this is perhaps most easily achieved using one of the large cloud vendors like Azure or Amazon, also third-party vendors can set this up. This is because all the underlying technologies of Genus, like the database systems and cluster software, are standardized and come with the necessary mechanisms to support disaster recovery.
You are also free to define the level of application isolation you require. If you have multiple Genus applications in your organization, these can be deployed to multiple and different Kubernetes clusters providing the highest level of isolation. Further, Genus supports deployment of multiple Genus applications into a single Kubernetes cluster separated by Kubernetes namespaces and standard Kubernetes Role-Based Access Control (RBAC).
Scalability is supported through standard Kubernetes mechanisms as described further below. Scalability can also be supported by standard features provided by cloud vendors, like automatic scheduling of new nodes in Azure.
A failure in any Genus microservice will be detected through standard Kubernetes mechanisms and the microservice will be restarted by Kubernetes. The appropriate events will be logged and retrieved by any monitoring set up according to your choice.
Some cloud infrastructure providers also provide support for automatic node repair to automatically take measures when a node fails or becomes unresponsive.
We are always ready with technical resources to assist you with the right deployment architecture to meet your needs. Contact us for more information.
Genus comes with a sophisticated security model, developed over decades with feedback from highly security-aware industries including public safety, banking and finance, and insurance. As a metadata-interpreting low-code platform without code generation and possibilities for code-injection, the security model is designed to cover the entire application and cannot be compromised by custom code errors.
The application model is secured from the bottom up, starting at the data model. This means that no user or interface will be able to access or modify any data without being authorized. When designing the data model, the Business Engineer must decide who should be able to access the information:
- “No security”: The object class is open for anyone with access to the application
- “Inherited permissions”: Access to the object class is based on access to a referenced object
- “Granted permissions”: Access to the object class is granted explicitly
- “Grant with conditions”: Access to the object class is granted conditionally
Access can further be granted on several layers, according to what the different users should be able to do or see. The levels of permission are:
- Find And List: The user can see the entry in search results or listings.
- Read And Execute: The user can open the object in a form and view the content (properties)
- Create: The user can create new objects of this object class
- Modify: The user can modify an object of this object class
- Delete: The user can delete an object of this object class
- Read Event History: The user can see the history of this object and what has changed over time
- Read Permissions: The user can see who has the different types of permissions to objects
- Set Search Criteria: The user can search based on properties of objects of this object class
Security groups and effective permissions
All users must be assigned to at least one security group to access the Genus application. Further, a security group can be a member of one or more security groups – to allow inheritance of privileges from other security groups. Genus supports both role-based and level-based security group setups.
For advanced applications, access to information must often be assigned dynamically. For instance, a case management solution should immediately grant a certain level of access to information about a case to new team members. In Genus, this type of dynamic grants of access is handled through Conditional Security.
Conditional Security allows the granting of permissions to be based on the data in the application, in contrast to for example which security group you are a member of. For instance, access to an activity can be based on whether you are assigned to that specific activity. Or, it can be based on that you are the manager of someone assigned to the activity.
The entire data model can be used to define the security model best suited for your specific application. This type of security is especially important in applications containing sensitive or confidential information, which should only be visible to specific, and often dynamic, groups of people.
Data sets and multi-tenant solutions
Genus applications utilize the concept of data sets to support multi-tenant solutions. Data sets are segregated through access rights, where users are only able to access data from their specific data set.
Data sets share the same data model, but the underlying data is separated either physically, through separate databases or schemas, or by unique identifiers for each data set. However, it is also possible to design object classes with data shared across data sets (e.g. to share master data).
Identity and Access Management
Genus can be used with multiple ID providers supporting OAuth2 (e.g. Azure AD, Google, or Facebook) or Open ID Connect (e.g. ADFS or BankID). Additionally, Genus comes with a native ID provider. For more information about Identity and Access Management, see the section under Lifecycle Management.
Other security aspects
The audit trail is an integral part of the Genus platform, where all CRUD operations on data and actions can be logged. Even search actions can be logged, ensuring full visibility into who has seen or modified the data in your application.
Data integrity and data constraints
Genus builds on the functionality of underlying databases, but also enriches and extends the functionality to ensure full portability of your data. The data model of your Genus application is set up to support data integrity and data constraints, which again reduces the risks of erroneous or malicious data in your applications.
OWASP top 10
Genus is hardened against the top 10 Web Application Security Risks defined by the Open Web Application Security Project® (OWASP).
HTTPS as default
Genus always uses Hypertext Transfer Protocol Secure (HTTPS) as the standard communication protocol, and the communication can be encrypted with your own digital certificates.
Genus is designed to support a variety of scenarios and to enable the natural evolution of applications. This includes a strong focus on scalability, allowing applications to grow from smaller proofs-of-concept to large, enterprise-wide solutions.
The Genus runtime microservices architecture is based on Kubernetes. This supports dynamic and automatic scale-up and scale-out with containers in addition to scaling out with new Kubernetes nodes.
Genus uses a de facto technology stack, including Kubernetes with Helm and Docker containers. We use Redis as an internal cache and non-persistent database within the Kubernetes cluster.
Horizontal scalability, or scaling out, with Genus is achieved by utilizing the scaling features of Kubernetes. Essentially, this means that you add more replicas of a pod (microservice). The number of replicas is set when deploying a microservice, and this setting can be adjusted manually later at run time.
Kubernetes also supports the concept of autoscaling, where the number of pods is automatically increased based on metrics.
The number of nodes can also be scaled up or down as needed. This is usually more relevant when adding or removing environments in a cluster, rather than as a result of changes in load.
Vertical scalability, or scaling up, in Genus translates to modifying requests and limits for the pods in Kubernetes. Both CPU and memory have a request and a limit. The pods request certain amounts of CPU time and memory from the nodes.
The request settings are used to determine which node the pod is assigned to. If a pod uses more resources than their assigned limit, it is throttled.
Both the request and limit for each microservice can be specified when deploying the microservice through Helm values.