Skip to main content

Teiid Runtimes Explained


If you have been following Teiid lately we have been going through a whole lot of renovations. Yes, renovations or reorganization or refactoring or whatever you want to call it. Basically, we are making Teiid more modular with fewer dependencies that can be used by however your use case dictates rather than use it as one monolith application deployed into WildFly JEE Application Server. There is nothing wrong in using Teiid as server model, but with the proliferation of container-based workloads and cloud-based architectures, the previous server-based model does not work or simply won't scale. So, we needed to think of alternatives, thus Teiid team introduced a couple different versions modular Teiid what we are calling as "Teiid Runtimes".

Note that in these modular Teiid runtimes, not all the features you were used to using in Teiid Server model may not be there but you will have extensions to add in those that are most appropriate for your domain. If you are looking for a data virtualization system in any configuration, one of below should satisfy your needs.

Now that we know what Teiid is up to, what are different flavors of these Runtimes? Basically, we have four different varieties.

  1. Teiid Server with WildFly (legacy model)
  2. Teiid Embedded
  3. Teiid Spring Boot
  4. Teiid Thorntail

Teiid Server on WildFly

This is the legacy runtime that Teiid team has been supporting for a while, the support for this will be continuing to new versions of WildFly. Currently, with the release of Teiid 12.0, the WildFly support is at WildFly 14.  Going forward there will be a separate repo for the WildFly based deployments that is different from current Teiid git repo. This repository will contain only code that is specific to WildFly. To use this version one needs to be little knowledgable in WildFly server, but typically no Java experience is needed but recommended.  If you want you can build Docker images based on this as a Server just like say MySQL or PostgreSQL image.

Teiid Embedded

I would call this and rest of other runtimes below as "frameworks" where they do not provide a fully functioning system, but Teiid provides the essential APIs and hooks to design your own system with ease. Teiid Embedded is the plainest version of all, where you have a whole lot of autonomy to design to your use case and embed Teiid in your own JVM. There are plenty of examples to you started. When using this Java experience is required. This is ideal for anyone wanting to embed in their own project/product in OEM fashion.

Teiid Spring Boot

It is no secret that Spring Boot most popular among Java developers. This runtime uses Spring Boot and Teiid Embedded to bring Data Virtualization features for Java developer in a way that they are already familiar to them. For example, it is as simple as using JPA framework. This one is my current favorite, as this supports legacy VDB file based deployments and also JPA based view definitions where explicit VDB does not need to be defined. It also has a feature called "redirection", where it can make it possible to use production data for testing without modifying it. If you are Spring Boot developer there is not much more you need to learn as most of the Data Virtualization will be instrumented in by using a set of annotations. This would be an ideal framework to use if you are thinking of using Teiid in Microservices architecture. If you are looking into container-based deployments and cloud architectures this is an ideal platform. The examples will show how to deploy into OpenShift or Kubernetes using fabric8-maven-plugin.

There is limited support for different sources currently we only support relational sources, excel, REST. But this support will be expanding.


Teiid Thorntail

Thorntail is a Microprofile based Java framework that is designed for Java-based Microservices using standards-based technologies. Thorntail was previously named "WildFly Swarm".  Since this Thorntail 2.x technology was mostly based on WildFly there good support for most of the features that were available in Teiid Server. We will continue to support 2.x Thorntail.  If you want a system close to WildFly technology but in embedded Microservice style application then choose this version. this version is also good for using as container-based workloads for cloud environments. This supports similar features as spring boot in this area.

When Thorntail 4.x rolls around we have to reevaluate the support there as that is assumed to be vastly different from Thorntail 2.x, and we expect that would be a complete rewrite.


What about UI?

As you probably noticed the pace of Teiid Designer releases stopped, as we are not putting in any more work into eclipse based tooling. The existing Teiid Designer should be still valid to use in the design of your VDBs if you prefer as they VDB you build will be deployable in any of the above Teiid Runtimes. However, Teiid Runtimes also support dynamic VDBs that one can build by hand or programmatically.

We are also collaborating/integrating Teiid technology with Syndesis community, there you will see a UI to build and deploy Teiid based runtime. More on this later in future blogs.


Let us know your opinion as we shape Teiid for future workloads while supporting the legacy.

Ramesh..

Comments

Popular posts from this blog

Teiid Platform Sizing Guidelines and Limitations

Users/customers always ask us about the sizing of their Data Virtaulization infrastructure based on Teiid or the JDV product from Redhat. Typically this is very involved question and not a very easy one answer in plain terms. This is due to fact that it involves taking into consideration questions like:
What kind of sources that user is working with? Relational, file, CRM, NoSQL etc.How many sources they are trying to integrate? 10, 20, 100?What are the volumes of data they are working with? 10K, 100K, 1M+?What are the query latency times from the sources? How you are using Teiid to implement the data integration/virtualization solution. What kind of queries that user is executing? Even small federated results may take a lot of server side processing - especially if the plan needs tweaking.Is materializing being used?Is query written in optimal way?and so on..Each and every one of the question affects the performance profoundly, and if you got mixture of those then it become that much…