 Hello, this is your host of Nibbantya reporting for TFI on a platform where we talk about open source emerging technologies. Today we are going to talk to Thomas Jackamo, or as he is famously known within Suze as Dr. T. Dr. T is CTO of Suze and we are going to talk about the role of CTO at an engineering company like Suze. What is it planning for future because as a CTO he is into things that are coming up in the future not the things that happen in the past so we are going to talk about all those latest technologies and everything else that Suze is planning. So let's go and meet Dr. T. So the first question is that what is the role of CTO of a company like Suze? So the main role is to spend time with our key partners and customers understanding their needs and also explaining them what Suze is doing but also doing the same with the open source communities, scooting some of the industry trends and then bring back that home to discuss with our marketing, alliance people, engineering about what could be the next step for Suze in terms of adding those new technologies in our portfolio of working with partners to deliver them. And actually I'm happy to announce that at SuzeCon we are launching a CTO office at Suze because we keep on growing, we're investing more and more into people, into projects and so we are creating a CTO office now. So I'm quite sure that in a CTO office you will be the, having a CTO office. So what will be the kind of key people who will join the CTO office and what will be their roles then? So I think there are a couple of different angles to that. One is to work even more with the open source communities and projects. We do a lot today but we want to engage even more with that. Another one is to be maybe localized in some key territories like North and South America or Asia back because I'm based in Europe and CTO to meet chief travel officer, I've been traveling all around the world and it doesn't scale. So at some point we also need people to be in the specific places where we have partners, where we have key customers and as it's everywhere then we need those guys to be there. Then of course we have different focuses in the company. So we focus on software and infrastructure type of technologies from storage to open stack including virtualization and all of that, containers, application delivery. So in the team we will have expertise across all those technologies with some people deeply more involved with specific topics like more on the application side or more on the storage side for instance or cloud. And as a CTO, when you look at the whole technology stack in modern world, first of all we are in the middle of a revolution that's going on. At the same time the technology is moving really fast and on top of the technology that was announced last year, not iterations are happening on top of that. So first of all from your perspective as a CTO, what are the really exciting and hard technologies of course for enterprise and how do you see SUSE should be, what are the technologies you think SUSE should be investing in which are like forward-looking technologies. So I think that there's still a lot of growth and a lot of adoption around software defense storage for instance that needs to happen and that's happening. So if you take for instance all the improvements and performances that are achieved in the last release upstream, it's going to help a lot enterprise customers to add software defense storage for even more use cases than they do today. So same thing with OpenStack, OpenStack keeps on being adopted. We keep on seeing new innovation and things that make things easier for people to use in production, address more use cases. So there are a lot of things around software defense infrastructure that can help even more our customers today. Now those things have to be managed as well so we need to make sure that we provide management solutions together with our partners or by SUSE ourselves to help our customers benefiting from what they could put in place. And the last thing that I would like to mention is the application side of things. So SUSE is an infrastructure company, it's been the case for the last five years and we are still focusing on software defense infrastructure but it's very important that we keep in mind that at the end of the day the infrastructure is used by applications and that's where our customers are making their business or depending their business on. So more and more we are including technologies to facilitate the development of applications with technologies like containers. So we announced SUSE containers as a service platform version 2 here at SUSEcon with the latest Kubernetes and a lot of other things. And also even more towards developers themselves, technologies like CloudFundry that can help a lot of developers speeding up their work and benefiting to the business. And so for us it's very important to bridge those two worlds together. So it's not like you work on the software defense infrastructure and then you work on the application delivery. If they don't work to each other then you don't really benefit from your infrastructure and from the whole solutions that you can get today. I understand that SUSE is an infrastructure company and when I think about exciting technologies I always look at machine learning and artificial intelligence. And I am very well aware that that's not the market where SUSE will go, SUSE will not invest in TensorFlow and all those machine learning technologies. But how can machine learning help the stack of infrastructure itself? How can you use machine learning technologies? Automation is the key today but machine learning can't take it to the next table. So what do you also have a perspective on that? So that's a very interesting question. So you're right we don't have a TensorFlow based product today for instance but we are working on integrating TensorFlow with some of the SUSE technologies. Well first because it's fun, some of our engineers are doing that because they like it. Also because some of our partners and customers are looking to integrate machine learning into their own solutions that are running on SLES or SUSE OpenStack or SUSE Containers. And I'm thinking partners like SAP, HPE, they all have interest in those technologies and we are working with them to see how we can interface all of that. And as you mentioned I think there are concrete use cases to improve software infrastructure with machine learning. So we actually have some proof of concept internally to filter the bug request and the support request that we have. Use machine learning to predict what's going to come or another use case is that we are using that to check how much time it takes to deploy packages to let's say thousands of servers so that we can predict next time the maintenance window or how much time it will take in a different environment. So we are also looking at machine learning to help operations inside our products. And another example that I could give is if you take software different storage or even CASP, it's distributed systems with clusters. And it can be quite complex to set up SAP for your own use case based on your hardware, what you want to do with the data and all of that. And sometimes as humans we try to configure things but it's not perfect. And we think that machine learning could help as well. So having many, many customers using the technology, getting all the data and how it's configured, how it's performing. Then machine learning could help us to create configurations that are more optimized automatically for other setups. So yeah, we're looking into that last point maybe. And it's probably more linked to high performance computing where machine learning can be used as well. We are working more and more with the NVIDIA CUDA drivers, for instance, to also implement, let's say, the processing part of it in relationship with the hardware. Right. Now let's change the topic from future to somewhat past. This is kind of complicated and sensitive topic, Cloud Foundry. Cloud Foundry came before Docker made containers, sorry, popular. Basically, if you look at it, it seems like the Cloud Foundry was trying to solve the same problem to abstract the whole layer and you just worry about your application. And that's what kind of Docker also does, you just worry about deploying your application at a scale. Suze has, of course you have REL, and then you also have CASP. And you're also closely working with Cloud Foundry and you also have OpenStack. So first of all, three of these things, try to do the same thing, solve the same problem. At the same time, they also kind of complete with each other. So from your perspective, do you see some kind of consolidation in future, or where do you see this IES path in CASP or either colliding with each other or coexisting? Can you please talk about that? Yeah, sure. So they're looking at some of these problems are the same, but they don't look it from the same angle. So let's start with containers and Cloud Foundry, for instance. So Cloud Foundry is more looking at helping developers to develop. Of course, with all the CI CD and DevOps things to get the applications in production, but by providing build packs of programming languages, prepackaged libraries, services that you can consume, and they do that a lot better than what container or infrastructure could do. Containers are providing more the delivery mechanism for putting things that are running in containers in production. So to me, it's like you use a pass to build services. The services are running inside containers and you use gas to manage all those containers, schedule them. And of course, it's not that black and white, right? So as you mentioned, I don't see them colliding. Today I see them as complementary, but they will converge. And that's why through the Cloud Foundry based solution is actually containers that are managed by Kubernetes. So that we try not to siloed them, separate from each other, but to have them work together inside each other, so that you can benefit from the best things from both worlds. So that's for containers that gas and pass. If you look at OpenStack containers today, they're running in production. A lot of companies are running them in productions. But quite frequently they run inside VMs, and VMs can be managed by OpenStack or by other solutions or whatever. And the reason is that a VM environment is still better at managing the storage and the networking and the line layers that containers cannot really do today. And there are a lot of works being done to improve how storage is interfaced with containers or networking. But today, yes, it's still a better way to manage your private data infrastructure from networking and storage, for instance, than containers. So typically, you could have an OpenStack with containers managing the workloads, an OpenStack taking care of networking with the open daylight, for instance, storage itself. And then you will have the bus layer on top of it for the developers themselves. Now they are complementary, but you need to make sure that they work well together as well. And that's also what we are trying to bring with the Sousa solutions, actually some integration between those different projects. So if we just look at the analogy of the last stack in old days, if you look at the modern infrastructure, what stack would you call it? Because you have OpenStack for that many cloud storage, and then you have containers. So from Sousa's perspective, and the good thing is you have all four. So Linux could be OpenStack. Some people have said that OpenStack was the operating system of private cloud, for instance. And we should probably talk about hybrid cloud as well, because it's not only about private, but I'd say OpenStack is the hell. Apache would be maybe pass. It's getting tricky, right? Let's not like point by point, but just like four components, we should do different things. Kubernetes is like orchestration for every very, so there are different components of the stack. That serve different purposes, so there is no collision as such. Yeah, so I think to me the pass layer is the layer talking directly with developers. And the Kubernetes layer is orchestrating. So containers are the core of all of that, right? Because they are common to infrastructure and developers. So developers, they use pass to develop. Containers are built with the container infrastructure, managed with the container infrastructure, deployed, upgraded, and all of that. And then the data center infrastructure is managed with a yes solution, if that makes sense. Yeah, it doesn't make sense. One last question before we wrap it up would be that what are the areas that you think, I mean, we already talked about it, we have storewood stack, we have the CASP, we have open source CASP as a cubic for community, then a lot of other things. So what are the new areas that you think Suze should be or is going to invest on there? Do you see a lot of excitement happening? So there are still some new stuff to be done for the software defined storage and stuff like that. I think software defined networking so it's a topic where things could be better. And there are a lot of solutions, but it's very fragmented and the use cases are very different between Delcos and IT. So there are still a lot of things that could be improved. And not only from the Suze perspective, but from an industry and open source community perspective as well. And I think that's why we're working with the Linux foundation on that together with other companies. Another key aspect to me is the management of all of this because you have management and orchestration for OpenStack, you have that for containers, you have that for pass, you have that for storage, but as an operator or service provider, I don't want to have a different dashboard, different management solution for all the different pieces of that stack. I need something that is integrated and unified. So that's also one thing that I think could help. So typically, we are providing Suze Cloud Application platform, the Cloud Foundry-based solution, and Suze Container of the Service Platform. Some customers, they don't want to have a Kubernetes dashboard and management system, and the Cloud Foundry they want to have something that is integrated for them to use like a platform management tool. So that's one space where we will continue to work. We do that with OpenATIC for storage and Suze Manager, and we'll keep on working on that. And maybe the last thing I would mention related to application delivery. I think the industry still needs to work on improving the way that services are consumed. So you have different service catalogs or service platforms that are not interoperable, and so we need to make sure that we can provide to developers who are using any type of platforms the access to services from public clouds, from what they have internally, from what they have from partners, or even from competition, so that they can build applications together. And then once it's done with all those different services, make sure that those services can talk to each other with service meshing and configuring those services from the networking to the role-based access at the service level that they need for applications. There's always one last question. Since you're mentioning that one of the areas is management or orchestration, when we look at Kubernetes, it's like going everywhere. So do you think that you said that some of your customers don't want Kubernetes, but do you think that the SUSE solution, which will work across the board, will be somehow based on, because somehow Kubernetes is kind of becoming latex kernel of the. Yeah. So for the container management and orchestration, I can say yes. So I don't have a crystal ball for like two or three years from now, but definitely yes. I was thinking about also the management from a user interface perspective and the single dashboards. And it doesn't have to be Kubernetes or something else, right? And the same applies to monitoring and logging. So people, they don't want to have to look at the logs of Kubernetes when they run something else on top or with it. They want to look at consolidated logs of all the platform and stack. Some of them, some of them I still want to look at the separate pieces together. But so I think we are. Today, Kubernetes is clearly the solution that we select for container management and orchestration. And we're hoping to complement that with other solutions as we do with Cloud Summit. I think we got everything that we were looking for today. Yeah. So thanks once again for your time. It was nice talking to you and hope to meet you again soon. Yeah, thank you, sir. Thank you. And back to your audience. Thanks for listening. We love talking to technologies and business leaders. So if you want us to talk to technologies and business leaders of your company, get in touch with us. You can find all the links in the tfir.io slash about page. And don't forget to subscribe to our channel. Here's the link. Thanks for watching and see you next time. Bye for now.