5 Key Questions from our webinar, “Is Your Data Architecture Ready for Microservices?” - VoltDB
post-template-default,single,single-post,postid-15532,single-format-standard,mkd-core-1.0,highrise-ver-1.0,,mkd-smooth-page-transitions,mkd-ajax,mkd-grid-1300,mkd-blog-installed,mkd-header-standard,mkd-sticky-header-on-scroll-up,mkd-default-mobile-header,mkd-sticky-up-mobile-header,mkd-dropdown-slide-from-bottom,mkd-dark-header,mkd-header-style-on-scroll,mkd-full-width-wide-menu,mkd-header-standard-in-grid-shadow-disable,mkd-search-dropdown,wpb-js-composer js-comp-ver-6.0.3,vc_responsive
VoltDB / In-Memory Database  / 5 Key Questions from our webinar, “Is Your Data Architecture Ready for Microservices?”


5 Key Questions from our webinar, “Is Your Data Architecture Ready for Microservices?”

At our recent webinar, “Is Your Data Architecture Ready for Microservices?”, we received a number of questions from attendees about VoltDB and how it works. From integrating VoltDB with Kafka to running VoltDB in a container, here’s a recap on the FAQs asked during the webinar.

For those who missed the webinar, you may view it on demand.

Editor’s Note: Unless otherwise noted, the question is coming from a webinar attendee via our chat functionality during the session. Answers were provided by VoltDB’s Chief Technologies, Dheeraj Remella. These answers have been edited for clarity and grammar.

Q: Can VoltDB work with Kubernetes?

Yes, actually. In fact, in the telco world, that is becoming like a mandate for us. We have actually done a lot of work on Kubernetes integration and lifecycle management of VoltDB through Kubernetes for managed and guaranteed availability.

Q: Can VoltDB integrate with distributor log systems like Kafka, Kinesis and PubSub in a command orchestration model?

That’s an interesting question. One of the things that I talk about when bringing state and stream together is being able to integrate with your existing systems. Like if you look at the major distributor log systems, most of them are cloud — other than Confluent Kafka — so we integrate with all of these because we recognize that these are probably already in their systems.

What we have done is, because we’re specialized technology, we essentially have a front-end integration and a back-end integration into streaming technologies like Kafka or Kinesis. On the importer side, we can take the data directly from the stream and push it into Volt’s work function stored procedure. And then on the back-end, we can actually push out notifications through our exporter framework. It fits very well with the command orchestrator model, but you also want to be [to my earlier point] mindful of how do you manage the latency on the orchestrator.

On the other hand, is there a way that you can actually move the work into Volt to say, “Here is a message, and Volt, you know that it is coming from this channel, this topic, whatever be it, you know what to do and all the exception handling is within this stream processing function within Volt.” And then you can actually emit signals based on what your end criteria is, or end state is of that business transaction.

So we integrate with all of those and that’s the model importer and exporter, and in between is your transactional processing and decision-making.

Q: Is VoltDB available as a path offering with AWS RDS?

We’re not on the RDS, but we are on AWS marketplace and you can perhaps work with us to see how we can actually make it server-less through the Kubernetes integration. So that’s one way to approach it.

We run on AWS a lot, mostly in VM models, but more recently in containerized models. So, something that we can actually look into it, but we’re not, as a path, offering on AWS today.

Q: What about network enhancements, like network service mesh? Will that help with data movement?

Well, I mean, if one is actually hellbent on “I want to have it in NoSQL store because somehow it actually accelerates my development cycle, so I’m going to keep it as NoSQL but I’m looking for network enhancements.” Of course, you can do it, but you will actually hit limits and the limits would be artificial because of the choices, right? So, make a different choice and you’ll see different limits.

So, yes, I think there is a commercial organization — Istio, if I’m not mistaken — that has a commercial version of network service mesh but also, it’s actually becoming an open source initiative of its own. I haven’t done any personal work there, but it should help. If that’s your architectural choice, it will help think differently because that’s all I can tell, right?

Q: How different is running VoltDB on a container than running it on a VM, and do you see any advantages for either approach?

Yes, right. So first of all, VMs have slightly better interfaces than containers from a networking standpoint. But with containers, you can actually declare your entire application as a part and just spin the whole thing up within a few seconds. So it’s massive difference in agility standpoint.

From a business standpoint, probably VMs are slightly better. But VMs do carry the cost of the Hypervisor, while containers don’t, so I would say definitely containers have advantages.

One thing that containers would actually have a challenge with, if you can address it, is the durability part. VoltDB is an in-memory database. One of the things that you do is actually run data in-memory, but you don’t want to lose the data, so we offer you 100% durability.

In a containerized world, that’s a bit more difficult because you’re actually going to some kind of NAS or network access storage for your durability contracts that defines what kind of a pipeline you have with your NAS. On the other hand, a VM could have native storage, globalized local machine storage and things like that. So that’s another consideration that you can actually think of.