Mission WYNIWYG – Why are we working on new runtime architectures?

We would like to update you on our plans for the upcoming months. In this update we explain why we are working on new runtimes and what this entails for you as a user of our platform.

In the upcoming months, the eMagiz team will continue to work on what we call the 3rd generation runtime. We have recently updated the API Gateway architecture to leverage a new runtime version, which allows our clients to benefit from new features that are available in the technology used inside this new runtime.

But why are we as eMagiz so busy working on new runtimes? The eMagiz runtime contains infrastructure components in which the integration flows are made operational. These flows process messages, respond to incoming API requests or push messages to a Kafka topic. At the moment, eMagiz runtimes are running inside Cloud resources that are dedicated for each client. eMagiz has invested significantly in developing the eMagiz Cloud architecture which comprises out of eMagiz specific software components and a diverse collection of AWS services that are optimized for the eMagiz Cloud.

We believe in freedom of choice for our clients in selecting on which Cloud infrastructure eMagiz should be deployed. Furthermore, we also think that the configured Cloud infrastructure should closely match the real-time requirements needed to run the integration model, which requires the ability to scale up or down the infrastructure based on message load and timing (cloud elasticity). Basically, we believe that every customer should get what they need.

This is where our Mission WYNIWYG (what you need is what you get) comes in – internally referred to as mission serverless. Serverless in our context means the notion in which the Cloud allocates resources on demand. Ultimately, there is a server or machine that is used, but the Cloud provider will decide how much and when these resources are allocated. To the point where no resources are allocated if none are needed. This will change a lot of things for our clients, but there is an uplift here for our clients:

  1. This new technology opens up the capability to add new, value-add functionalities to our platform.
  2. Pricing structures for Cloud can become more interesting for clients. Pay-per-use models can be an option.
  3. eMagiz becomes more flexible to use any Cloud provider components in our eMagiz Cloud architecture, resulting in better economical choices for sour clients.
  4. There will be more ease of use in the platform to manage the eMagiz Cloud.

Our next-generation runtime which is already available for the API Gateway, is based on Docker technology. This is the first step to abstract from the actual machine or server layer. Our next step is to use Kubernetes to manage Docker images, and deploy these on Kubernetes pods.

To make these runtime work on Docker and Kubernetes technology, we need to implement different techniques within this runtime. We have enabled our runtime to allow API Gateway flows to run on it, and coming quarters we’ll expand this capability to all types of flows (Messaging and Event Streaming). See the light blue section in the picture above. In the coming months, we’ll take our next steps and expand into Kubernetes technologies (purple sections).

So what does this mean for you as eMagiz user? In the first half of this year, we expect to have all API Gateway users transitioned to the next-generation architecture. New users of the API Gateway will start directly in the new architecture. In the second half of this year, we expect to start the transition of the Message Brokers and Event Brokers models to the new generation architecture. We’ll be in touch to discuss this topic with you to ensure a smooth transition.

For more information, please sent an email to g.waanders@emagiz.com. I'll be happy to answer your questions.

By Geert-Jan Waanders, Product Manager @ eMagiz

Twitter
LinkedIn
WhatsApp
Email
en_GB