This is part 2 in a blog series on “Microservices and No-Code”. In part 1, we highlighted the benefits of using microservices when developing a platform. Here is a short recap:

  • For the users of the platform, it allows scaling of independent services of your applications at run time. This results in a dynamic and cost-effective use of computing resources for your Genus applications.
  • For the developers of the platform, it is easier to develop and maintain the platform since each service is small. Also, since each service is independent of others, it enables developers to work in parallel.

We also claimed that microservices exist at two levels in our no-code platform, namely at the platform level and the application level. This second post of the series will focus on the platform level, i.e., how the Genus platform itself utilizes microservices.

Platform Level Microservices

At present, the Genus platform runs on almost 30 microservices. While an extensive list of services can be found in our Evaluation Guide, here are some examples:  

  • Gateway Service
  • Message Subscription Service
  • Metadata Query Service
  • Core Service
  • SQL Execution Service

We are going to go into details on each of these, and several others, how they are connected, and how they serve you as a user, developer, or partner of the platform.

But first, a couple of words about “Genus Services” and the “Genus clients”, in case you are unfamiliar with Genus.

Genus clients and Genus Services

The Genus clients are our user-facing and developer-facing software:

  • Genus Web: Our client for web browsers, for interpreting and using your applications built by Genus Studio.
  • Genus Desktop: Our native Microsoft Windows end-user client for interpreting and using your applications built by Genus Studio.
  • Genus Studio: Our Integrated Development Environment (IDE) to design, build, and deploy no-code applications.

When you build an application in Genus Studio, the application model is stored in a Metadata Repository. At startup, Genus Web and Genus Desktop read this application model and, contrary to many other no-code platforms, execute your model at run-time. We call it real-time model interpretation.

The enabler of this real-time model interpretation is Genus Services. This is a collection of platform microservices. They provide server-side application services to our software clients, end-users, and no-code application developers. Simply put, this is the set of functions needed for the clients to interpret or execute your no-code application properly.

The relation between Genus Web and Genus Desktop is illustrated in figure 1. All traffic from our clients is received by Genus Services through “service requests”. These requests are small data packets that contain information about which microservices to query. Next, we give you an introduction to how requests are handled and some examples.

Figure 1 – The Genus clients (Web, Desktop, and Studio) work closely together with Genus Services, which again connects to different kinds of storage.

Making it past Genus Services’ outer boundary

Figure 2 shows that a request first hit the Ingress and Load Balancer and then routes requests to a Kubernetes cluster. All while the Ingress routes a request to the correct microservice that works with the Gateway Service.

The Gateway Service works closely with the Authentication Service to let users gain access to further microservices. The Authentication Service maps user accounts to one or more identity providers, like Active Directory FS, Azure AD, Facebook, Google, and more. For details, have a look here.

Figure 2 – A request (red) from the Genus Web client making it past Genus Services’ outer boundary

Now, our microservices know who you are and have assigned a security token that your request carries to other microservices.

However, we still need to determine which functionalities and data you are allowed to access. Your access is determined by the Authorization Service. It interprets permissions based on a user account.

All Genus microservices read your application model by accessing another microservice, namely the Metadata Query Service.

The Metadata Query Service contains a preloaded version of your model from a database outside our microservice cluster. The preload is optimized, making the service reply quick. Eliminating time-consuming lookups in your Metadata Repository database.

Requests spawning new requests

Access between microservices is made by spawning new requests within our cluster. All microservice can request any other microservice. This is a semi complex process known as “orchestration” that is implemented following best practices.

Most microservices only read the parts of the application model they need for a specific purpose. This keeps a microservice small.

The initial request – the bootstrap

When your application starts, neither Genus Web nor Genus Desktop knows anything about you or your application. The application only has a URL to the Load Balancer. The application model is then read from the Metadata Query Service. The model is then interpreted by Genus Web or Genus Desktop, and your application with your data opens.

Genus Web and Genus Desktop send requests to microservices and different microservices are queried. The requested information is returned or ordered commands are executed.

Use cases: examples of requests and how they are implemented in the Genus microservices architecture

Display data on-screen from your business objects

When an end-user views data in your application, two things happen:

  1. A request is sent to the Metadata Query Service. Based on the response, the client draws the user interface.
  2. A request is sent to the Core Service, which requests the SQL Execution Service to get data from external databases, as illustrated in figure 3.
Figure 3 – A request for fetching data about one of your business objects and displaying it on Genus Web).

Update data

When an end-user changes data, for instance by clicking “OK” or “Save”, a request is sent to the Core Service. It verifies the changes for consistency and security matters, before passing the request to the SQL Execution Service for final execution towards the database.

Execute an action

Actions performed by an end-user, such as calculations, follow the pattern above, i.e., requests are sent to the Core Service. The Core Service passes any validated data change requests to external databases through the SQL Execution Service.

Send a mail

When you click send email in a Genus client, the request is passed to the Send Mail Service, as illustrated in figure 4. This is responsible for dispatching the request to whatever external mail service you are using.

Figure 4 – A request for sending an email.

Stream a video

Streaming of large documents or videos to or from your Genus application’s user interface is performed through a specialized Object Storage Service since streaming involves opening a more long-lived connection channel than the usual request/response pairs.

Use a dashboard

Genus Dashboard is part of our Business Intelligence toolset, making end-users able to present data and connections, with filter, explore and analyze features. When you open a dashboard (from within Genus Web or Genus Desktop), all requests for data, filtering, exploring, etc. are sent to the Data Mart Query Service, which is a highly optimized in-memory database.

Mail merge a document

Requests for mail merge are sent to the File Utility Service, which creates documents based on the requested data and Microsoft templates.

Document format conversion

Format conversations occur more frequently than you imagine. For instance, a preview of a Word document on Genus Web will send a request to the File Utility Service for conversion to HTML. The HTML page is then displayed in your browser.

For normal export or save data requests, where format conversion is required, like from Microsoft Word to PDF, the same service will be used.

Automatically update your user interface with data

Some pages in your application may need to be updated quickly and automatically when other users change data. An example is a table of available resources, like the status of police resources within a police management system, or inventory status within a sales system.

In Genus, your application’s user interface will receive update events through the Message Subscription Service, which again is fed by other microservices through the Live Update Input Service.

Switch your application’s language

If your application serves multiple languages, the Internationalization Service is responsible for serving requests from clients (or other microservices) in need of terms and expressions in other natural languages.

Expose calendar data to mobile phones

If your application contains data that naturally lends itself to external calendars, like team meetings or delivery dates, these data can be exposed to e.g., iPhone calendars through the Webcal Service. The Webcal Service uses the Metadata Query Service to get information of which calendars to expose and reads the actual calendar data through the Core Service (which makes sure access and security matters are considered).

Expose contacts to mobile phones

Similarly, if your application contains data that naturally lends itself to external contact cards, like customer contact persons, such data can be exposed to iPhones, etc. through the CardDAV Service.

Do changes to your application model

If you are a developer (or what we prefer to call a Business Engineer) and want to make changes to your application model, like adding a field or changing the position of a field within your user interface, a request will be sent from Genus Studio to the Metadata Definition Service. This service will validate the request and forward it to the SQL Execution Service, which again performs the change to your application model stored in a Metadata Repository in one of your external databases (Microsoft SQL Server, Oracle, DB2, MySQL, or similar).

Figure 5 – A request for a change in your application model

Scaling microservices to meet higher demands

At some point, you might need to increase the microservices computing resources available to your users to speed things up. As discussed in part 1, scaling up what you need while leaving everything else unchanged is an important aspect of microservices. It prevents wasting valuable resources and thereby saves time and money.

With Genus, you can easily do this through the Genus Operator. This is a user interface that allows you – among other things – to access and increase the number of microservices. For instance:

  • Having two instead of one Gateway Service running, if your application experiences higher loads of incoming requests.
  • Having two (or more) instead of one File Utility Service, during high demand for mail merge or format conversions of documents, as illustrated in figure 6.
Figure 6 – Scaling up the microservices you need more of as the number of users and load increases. In this example, the number of Gateway Services and File Utility Services are increased, while all others are kept unchanged (Internationalization Service, Help Docs Service, and Agent Service).

Other microservices – the complete picture

There are many more microservices than we have touched upon above. If you want even more in-depth information about Genus’ platform architecture, take a look at our Evaluation guide and specifically the Platform architecture section. As you will see, there is some overlap between the current blog post and the Evaluation Guide, but the story is told a little bit differently and the Evaluation Guide overall contains more information.

Figure 7 – The complete picture of the Genus platform’s microservices.

Final words

By describing some use cases we have shown the inner workings of our microservices at a platform level. This emphasizes that Genus is a mature and flexible no-code platform for the enterprise market.

However, there is another level to all of this, not visible when you look at it from the current (platform) perspective. We offer mechanisms for you to make your own microservices-like constructs as part of your specific application model.

However, microservices at the application level is the topic for a future blog post. Make sure you do not miss out. Sign up for our newsletter and get a sneak peek before everyone else.

Einar Bleikvin avatar image
Einar Bleikvin

Einar is Lead Platform Architect in Genus. He is a programmer who believes computer software should be told what you want it to do, rather than forcing you to describe how it should do it.