Automated Trader: This whole feature is about predicting the future; it's also about looking at what we have today and trying to get an inkling of how that's going to work further down the line. You're from a Red Hat background, and as our starting point, perhaps we can talk about that, and about the open source perspective.
Daniel Riek: I was at Red Hat for the last five and a half years. I was running the product management group of the operating system. I did product strategy, product decisions, and I was responsible for the level 5 and level 6 releases. Red Hat is a wild company in a way. When I came there I was first in Europe in sales engineering for two years starting in 2003. I moved to the US to take over the product management at the end of 2005. There were about 500 people there and now it is like 4,000. It was an interesting journey.
AT: At Red Hat, in view of the number of things that go into any Linux distro, you must have been keeping your eye on multiple different streams, everything from networking to image editing?
Daniel Riek: That's why the role at Vincorex was so appealing, because it had a similar problem. Red Hat's business is to take things from the open source and turn them into products. The innovation model is to contribute back to the open source. If you look at the Red Hat product you will find they do not differentiate from the open source community at a technology level. All their own innovation goes into the community first before they productise it. They innovate by influencing and contributing, then they productise, and what they actually sell is long term stability. In effect, they sell the old stuff after they have created it as a new thing in the open source community.
That collaboration model has a couple of interesting aspects. Open source is great; I call it base-lining. You can upload the maintenance of things that everyone needs into the open source and you still have the ability to build customisation and innovation on top of that. If you buy proprietary software you rely on someone else, you offload the things that can be done by someone else to that third party. But it takes away a lot of the flexibility you have in optimising that component. With open source you don't have to make that compromise. You can totally work with the community and either you can still maintain your own differentiation in-house, or if it's something that is not unique in value for me, I can contribute back to the community and share it with others.
At Red Hat my job was to drive this influencing and tell people which direction we have to go to meet our customer requirements. It was really the translation of customer requirements into community movement. Part of that is to find out what things the community does that are interesting to you, and to find out what the community is not doing that you need. Switching to the customer side was really appealing. I have been in this business since '97 when I launched my first start-up, and I have always been trying to sell. I had never been on the other side.
Another beauty of open source is it isn't a completely different thing looking at it from the customer side. You can do the very same influencing. I can go to the open source community and tell them what I need. I can hire engineers and do something in the open source community without going through a vendor first. How to find out what's interesting - I don't think there is a strict process you can follow. The closest to a process is probably an agile approach, but still, technology revolutions don't generally follow a process.
AT: If you are immersed in the open source community, as you have been and still are, you are in an interesting position for the purposes of this feature. If you were just dealing with other vendors and being dependent on their proprietary stuff and you couldn't influence them, you would be trying to predict how that vendor, with a particular type of technology that you might want to use, would progress over the next year or two. You would try and anticipate whether that vendor's product would be mature or suitable two or three years down the line for you. You couldn't do anything more than that. In the open source community it is a much more direct thing and if you think, say, this looks like a promising technology, you can influence it because it is important to you to push it further?
Daniel Riek: Absolutely right! You have three ways to do that. You can just talk to the community and tell them what you need. You can go to a vendor in the open source world, like a Red Hat for example. That was part of the Red Hat value proposition and it's the same for many other companies. There are many larger and smaller companies in different areas that you can go to and get features implemented in upstream projects. Often the best company to go to is the company that employs some of the leading engineers in the area you are interested in.
Of course, I don't want them to create a custom product where I end up with the same kind of technology lock-in because there is only one person doing it for me. I want them to do things within the upstream community so it becomes a common base. With any standard product company, whether they listen to you really depends on how much product you buy from them. If you have only one subscription they are not going to listen to your requirements.
So the first way is, talk to the community. The second way is to hire someone, like a company or an individual. The third way is you can do it yourself, hire an engineer with the knowledge and become part of that community. The beauty is, you don't have to decide. You can do exactly the same things you can do with the proprietary company. You find a trusted partner. You assess whether they do things in the right way and if they have a sustainable business, and see if they are actually driving innovation. Or you just do it yourself.
AT: In your current role there must be several different aspects of technology that will have implications for things like business. How do you prioritise the things you need to be thinking about? For example, do you say to yourself, networking is my current biggest priority - or what do you do?
Daniel Riek: There is never one biggest priority. It is all time management. You can prioritise, but in a start-up you can't ever do one thing. We tried to draw up a priority list - infrastructure, research, production, and so on. To some degree it was a cost benefit analysis. In a start-up you can go far on temporary solutions. It takes a long time before things really break and that allows you to focus on things that give you most benefit and try to leapfrog problems. Don't fix the problem at hand, fix the underlying long-term issue that gets you to a scaleable solution within, say, twelve months. In many ways we are really looking ahead and seeing how we want to do things in that twelve months to two years. Seeing how we can get on to the right road rather than fixing things in the short term.
An interesting area at the moment is the impact of cloud. It's not really new any more, it's still evolving, but we are in a sector that can really benefit from it. With the type of data we handle and the scale-out on demand it actually works really nicely. That is something that is a huge benefit, just the overhead of buying hardware goes away for some time.
AT: Would you say that is an area that you are particularly focussing on at the moment?
Daniel Riek: Yes it is one area that we are active in, definitely. It is a nice solution for one segment that we are looking at, for research data, optimisation, all that; it's great. It is very open source-heavy so everything I said earlier about open source works there. A lot of people are sceptical about the dependency you create if you go into the cloud, and about data security. If you look at analysing data that is not super secret, the feeds we get for example, there is no problem in the cloud and the data is portable. There is no real lock in and we can go to a cloud vendor and within the day we can move to another one. There is no lock in at all.
AT: You still have the issue with the cloud that some of the trading models that Vincorex owns are presumably highly proprietary; there are some security concerns around them?
Daniel Riek: Yes, but of course I want to go to a trusted cloud provider. With the standard system of security you have in those environments, and a decent limit on deployment, it's not really a fundamental risk. The full IP won't be found; it's partitioned.
AT: Vincorex is high frequency, so any models you are running are compiled in C++ and therefore not easily reverse-engineered?
Daniel Riek: It's a lot of C++ and if you look at the binary code then it is of very limited use. Even things that are implemented in Python are never complete. The problem is not, from my point of view, running instances that are closed system. All we do is schedule things. There is no persistency in the information we have on those systems. If you had a customer's data there, with credit card information, that's a whole different story. But we just don't have that problem.
Cloud is not future any more, but it's something that is really useful for us. There is also, always, the next generation of Intel chipsets and what they bring. The new vector operation they have and the new multimedia stuff are really interesting. You just have to stay up to speed and see how you can use it and improve your performance.
The next long term trend I am really looking at is what is going to come out of the platform revolution triggered by the tablets. The tablet itself is just the catalyst; I see us moving away from the dominant model of the last twenty years, which is Intel processors. They have always been highly specialised devices and machines. The problem was that they were not mainstream and you had to do things very differently. You are always are in danger of locking yourself into a corner that then loses the pace.
We try to be agile about it - another buzzword. Don't take decisions too early, take them as late as possible and keep your options open as long as possible. That is the kind of philosophy that I am trying to use here. Don't lock yourself down into an early decision that later on you can never change.
Competing with someone like Intel on the innovation of micro processors is just really hard. AMD is kind of keeping up but not doing great business. That's it. You look at IBM as being the power PC, which is a big power play for them, but it costs them lots of money and I don't think they make any money from it. They just have to do it because they don't want to be dependent.
AT: You are saying the technology that underpins tablets, because of the potential parallelism inherent in that, has a future possible applicability to yourself?
Daniel Riek: Yes. The technology has been around forever. The tablets, what they change, is that this now becomes mass market and not niche. It's been used in mobile phones before but in just very small devices. Whether the tablets are cause or effect I'm not sure. They are probably more effect than cause. The platform and architecture became powerful enough to do things like that. I have a little Android tablet - it's Linux. It's more powerful than the servers were 10 years ago. The way I would see it used in our application would be, you take a lot of these small devices, pack them really densely, and instead of having a big machine, with multiple cores, you would take these machines, also with multi cores, but you actually take a lot of small machines.
It's not a completely new concept but I think with the low power consumption you have in these architectures for the performance you get, it will happen. Another thing is the customisation. There is not a single ARM processor; it's a reference design that is always customised. If you look at the ARM in the iPad, it's actually an Apple version of the ARM. Instead of having to buy all the same hardware from Intel, and three or four big OEMs that do their own chipsets around it, optimise it, you actually get more commodity to customise your own thing. That's what I find intriguing but right now we are not using any of that in production. It is definitely something we are looking at.
AT: Do you see that as the more promising architecture, rather than alternatives like the NVIDIA GPUs or anything like that?
Daniel Riek: Yes. The GPU doesn't help you that much because the memory interface between the processor and the GPU over the bus is going to become a bottle neck. What you see there is that Intel is actually moving that functionality into the chipset. I think the GPU thing is interesting and it is actually useful today but I don't think it is a long term solution because it is too easy for Intel to just out-innovate it. If you look at Sandy Bridge and the new technology they are doing, it is magnitudes more powerful than the old SSE stuff. I'm just not convinced the GPUs will succeed against Intel putting all that kind of functionality in their technologies. For them it will be on the processor bus and there will be no better way to connect it.
AT: With the ARM alternative … you don't see it potentially having that problem?
Daniel Riek: It's a completely different approach. It's not a big machine, it's many small machines. All we are looking for is the triangle of latency, density and heat we produce. I need a low latency platform. If you look at a two socket machine, which is the baseline for what we do today, through the NUMA architecture it has some complexity; the latency changes depending on which core and which socket your data is processsed and where you trade, things like that. You have to look into controlling what runs where.
You already have some of the parallelism problems. The machine is not simple as it's a processor with memory.
At the end of the day, if you take a step back and try and simplify this, you just do individual systems with a simpler design that have their own network cards. You use things like RDMA to easily distribute the data in a high speed interconnection between machines. I think that will be a more scaleable approach in the long term. It's going to be simpler to maintain. This is something we are really interested in.
AT: Are there any other areas that you are particularly watching at the moment?
Daniel Riek: Networking and messaging. Messaging is a big item because the open source world has discovered it and now they have competing concepts. It's interesting because there is a standard called AMQP that has been taking off over the last two years. We are interested in it for some types of communication. It gives you a nice transport layer. You can buy very expensive proprietary solutions for that, but it seems like AMQP or some of the alternatives - ONQ is another one - seem to be at the point where they can render obsolete the proprietary stuff.
AT: Do you feel that you get better? It doesn't sound like you sit there and say, right, today I'm going to predict where this technology is going to be in five years. It sounds like it's lots of little things reaching you the whole time from lots of different sources across lots of different technologies. Do you think you enjoy better quality of information - that helps you make those judgements all day, every day - because of your participation in open source?
Daniel Riek: Definitely. You need to monitor both spaces. Open source is good in things that are mainstream or in really wild things where someone just tries something. But there are a lot of companies that do things in the proprietary way to get an edge, and they have a lot of innovative potential. We are doing what we need to get to our goals. Open source is a baseline but not all we do. We definitely look at both spaces.
If you watch open source, it gives you a good understanding of what the mainstream is. We try to be agile about it - another buzzword. Don't take decisions too early, take them as late as possible and keep your options open as long as possible. That is the kind of philosophy that I am trying to use here. Don't lock yourself down into an early decision that later on you can never change. We target what we want to achieve and then try and get there.
AT: Daniel Riek, thank you very much.