Microservices on the Platform level
This is part 2 in a blog series on “Microservices and Low-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 will make 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 low-code platform, namely at the platform level and the application level. While a future blog post will be devoted to application-level microservices, 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 low-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 low-code platforms, execute your model at run-time. We also call this for real-time model interpretation.
The enabler of this real-time model interpretation is Genus Services. This is a collection of platform microservices, providing server-side application services to our software clients, end-users, and low-code application developers. Simply put, this is the set of functions needed for the clients to interpret or execute your low-code application properly.
The cooperation between Genus Web and Genus Desktop on one side and Genus Services on the other 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. In the following, we will give an overall introduction to how requests are handled, before we provide some concrete examples.
Making it past Genus Services’ outer boundary
As illustrated in figure 2, a request will first hit the Ingress and Load Balancer. The load balancer will route requests into the Kubernetes cluster, while the Ingress routes the requests to the correct microservices in close cooperation 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 (ADFS), Azure AD, Facebook, Google, and more. For details, have a look here.
At this point, our microservices know who you are and have assigned a security token that your request carries along on its way to other microservices.
However, we still need to determine which functionalities and data you are allowed to access. The access is determined by the Authorization Service, which interprets permissions (connected to your user account) inside your application’s security model and stops further access if you are not allowed to pass through.
The Gateway Service, the Authentication Service, and the Authorization Service, as well as all Genus microservices, read your application model by accessing another of our microservices, namely the Metadata Query Service (which could have been named ‘Model Query Service’ since Model and Metadata are synonyms).
The Metadata Query Service contains a preloaded version of your model, which is read from a database outside our cluster of microservices. The model is preloaded in an optimized way, so the service can reply quickly to all requests, without having to do time-consuming lookups in your Metadata Repository database.
Requests spawning new requests
Access between microservices is made by spawning new requests to other microservices within our cluster. All microservices can send requests back and forth between various Genus microservices. This somewhat complex process known as “orchestration” is implemented following best practice recommendations and will not be discussed in this blog post. Most microservices read only the parts of the application model they need for their specific purpose. This allows the microservices to be kept as small as possible and not concerned about interpreting parts of your application model that they do not need knowledge about.
The initial request – the bootstrap
When your application first starts up, whether it is on your Windows PC or in your browser, neither Genus Web nor Genus Desktop knows anything about you or your application. It does not have any data, knowledge on how to present the data, nor how the data may be manipulated by you. All the application has is an address (an URL) to the Load Balancer. From this address – combined with your login – the application model is read from the Metadata Query Service, then the model is interpreted by Genus Web or Genus Desktop, and your specific application with your familiar data opens up.
From that point onwards, Genus Web and Genus Desktop send requests to the microservices, and, depending on the type of request and functionality you need, different microservices are queried. These microservices then return the information requested or execute the commands ordered.
There are hundreds of combinations of such requests and commands. Below we will take you through some use cases, so you can get a feel of how this machinery works.
Examples of requests and how they are implemented in the Genus microservices architecture
Display data on-screen about one of your business objects
When an end-user opens a page in your application (through the Genus Web or the Genus Desktop client) to view data, two things happen:
- The client needs to know how the user interface is designed, so a request is sent to the Metadata Query Service. Based on the response, the client draws the user interface.
- The client needs data to display and sends a request to the Core Service, which again sends a request to the SQL Execution Service to fetch data from external databases, as illustrated in figure 3
When an end-user does changes to his or her data (for instance by clicking “OK” or “Save” on a page in Genus Web or Genus Desktop), a request is sent to the Core Service, which 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.
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).
Scaling microservices to meet higher demands
At some point, you might need to increase the microservices computing resources available to your users to speed up things. As discussed in part 1, scaling up what you need while leaving everything else unchanged is an important aspect of microservices. It avoids wasting unnecessary resources and thereby saves energy 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.
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.
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 low-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.