Microservices on the Platform level
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.
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.
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:
- A request is sent to the Metadata Query Service. Based on the response, the client draws the user interface.
- 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.
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.
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 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.
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 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.