Marcos Figueiredo, Fujitsu | Open Source Summit Europe 2022

This is texturing TV. Hey folks, welcome back to the open source summit. We're here in lovely Dublin Ireland and we're talking with Marcus figaretto who's the director of global platforms and solutions and offerings for Fujitsu and turns out fidgets has been doing a lot of work with postgres over the years in Japan.

And now they've also done some interesting stuff we containers and they're going Beyond Japan. They're gonna be here in Europe and they're coming to the US so Marcus welcome the show. Yeah.

Nice nice to be here. Actually. It's a great opportunity to spread the word that we actually going outside of Japan now and we're focusing on Bring a lot of the Heritage actually we have around open source and postgres to to the other markets, right?

So we are. Expanding in the US spending in Europe. Of course.

We have we have a footprint in in Asia, but we think it makes sense now to tell hey we doing this. We we have expertise. We actually giving back to the community and how many focus is around postgres.

That's our main software, but we are actually expanding we're doing a lot of work around containers kubernetes, especially because there's a lot going on on this space of databases and people need some of the automations and toolings that you can get with a containers. So it's all about Devops how we can actually make it easy for folks to tap into database, right? To that point women here in and talking about stateless apps for containers forever in a day.

Now. We're finally starting to see some more stateful applications and it's a bit of a debate. There are some people out there who are like, you know, there's no way in hack that you should be storing data on a kubernetes cluster.

So what drives people to put the database on the cluster and what's and what needs to be done to enable that right? That's that's a great question. So, something I keep Hearing from clients.

It's really. Why should I put a database actually on containers? That's probably the last thing I want to put in containers because I might not get the performance but I think we got to a point where we have mature enough tooling.

To get us to deliver the same capabilities that we were getting on on traditional bare metal or virtualized environments. Now, we have all those capabilities into the containers. So we have actually launched early this year our food capability around openshift.

For example, they call level five right operators. They have a they don't have a standard necessarily but level five basically means we have full out of scaling monitoring and capabilities to allow the developer to connect the database without knowing too much about it. And and on the same time he can tap into high performance storage high performance compute if those things are connected to to their kubernetes cluster, right?

So because of this have evolution of the toolings, I think we are to the point where we're gonna see a lot of these tateful applications actually now really being migrated into containers. So I think we are at the tippy point from that perspective. There are a lot of people who do not have an existing data storage architecture that they can call externally and so if it's Greenfield, you got to have some data somewhere so likely is you're going to attach it to the cluster anyway because that may be all you have, correct, correct?

Yes and There is a lot around that there's a question around no sequel tends to be more suitable for this types of environment, especially Green Fields because the developers they don't need to talk with a DBA right? So They can just go out and then connect to another Sequel and then start using without worrying too much about well, what's my schema gonna look like or how do I optimize this to make that application without perform? The funny thing is when we got postgrades which is a traditional object relational database and we bring operators around kubernetes.

We actually give a lot of those capabilities back to the developer so they don't need to worry too much. Yeah. I still there is a need to think about how they're going to scale long term.

But when you start putting those toolings and now they get the outer scalability that they would get those using an on SQL, right we dial having to worry about to to worry too much about how the things going to short in the future or if they're gonna get a lot of data spread all over so so yeah again back to the tooling. I think what we do in a rock containers, it's really provided to set to allow even if you're starting from scratch to allow you to grow in a way that applic Can be coming Enterprise at any moment, right? We have been hearing about the developers don't need no stinking DBA thing for a long time.

But it seems like what happens is they get about into their third or fourth database and they go. Oh, well, maybe I need a DBA but I don't want to admit it to DBA. So I give it a different title or a different job function.

So what is the relationship between developers and dbas as we go forward and what should it be? Well, I think I think more and more dbas will have to to understand what what the challenges are for the developers and move away just from The little Silo so I think with devops really does is really breaks The Silo so now you need to understand the other side of the equation, right? So you the same thing we have the dbas and developers you have between dbas and infrastructure Architects, right?

So all of that has to to go away to really to have devops to to work and to to realize the food benefit of operating in agile way and leveraging what devops can deliver So I think dba's will. Potentially have a change of title or they will have to understand better what the needs are and and things will start to change in terms of a how developers and DBA is communicate with each other right? There is a lot around database as a service which is usually easy way for developers again to tap into database without knowing knowing about the data in itself.

How data will be structured but what we're seeing actually back to the containers is that is good to to a point when you need to get control back and when you need to scale and then have a full Enterprise solution container seems to be a better fit actually than just going into the cloud and using a database as a service and forgetting about hey. I don't need a DBA anymore because I can buy this from somebody else what we see in reality is. That's true to an extent right when you get to a level where you really need performance and you really need to make something super reliable.

That's that's where where you need a DBA again, right? So that I don't think that's going away. It's it's just morphing into something a little bit different right.

Do you think people don't understand enough about the the issue with Cloud native microservices based applications that are built using these containers is there's a lot of dependencies. There's a lot of calls to data through these apis and so performance becomes a much bigger issue than it used to be and I'm not sure that people understand that going in. I I agree I think for the most part still very New to it again.

I see a lot of changes happening, and there's maturity now in terms of some of some of the architectures are getting to the point where well, this is becoming really Enterprise again for the most the most part I think people still Trying to absorb and really understand all the parts, especially when you go to a microservice architecture. It is a shift right and complete shift in terms of how you think about the application how you think about the data with the data going to be located how you make that the call to the right apis and how you put performance reliability scalability into the equation, right? I still think it's very new for the most part.

We've been talking for this about. I don't know five seven years, maybe but still it's very new when you compare to what people have been doing with traditional analytic applications analytic databases. They've been doing this for 50 years, right and not a lot has changed from the times of the Mainframe traditional databases into an oracle today, but when you look into microservices containers in itself, it's There's a big shift so that the jump I think people are learning how to do the jump but they not everybody's there yet.

So that's that's how I see at least one of the words in the database lexicon that everybody hates is shouting. Yes. Can we get rid of shorting?

Are we still gonna have sharding as we go along? I think I think you're still gonna have it. So postgrades diversion 15.

You see some things the communities bringing into in terms of trying to address that. I honestly don't think we're going to get rid of it not. Not on the next two releases at least so that but again I might be wrong.

That's that's very Debatable, but that's that's how I see it. I think still gonna be there there are things that we do to work around those issues. I think some implementations get more exposed to it.

I think it's not a super. Complex on postgres that is sitting in on non sequels, for example, but still still something that needs to be addressed right in consider as you work attack the whole solution. As we go along how automated can all this management the database is get and you know, are we looking at I don't know maybe some form of AI will come down the pike and we'll have algorithms take care of stuff.

I mean, how advanced are we at the moment so I think when you look at some of the proprietary implementations right you see Some of the main vendors calling out autonomous database which imparts yes. There's a lot that can be simplified when you put automation a lot that you can do with machine learning and AI capabilities. But I don't think we're gonna eliminate the need to have a data expert.

No matter how evolved the AI becomes and in our understanding of how it can automate things. I think still gonna need on database expert again. Even if that title changes I still you need somebody to understand how the data needs to be stored what the things need to be considered as you evolve in the architecture.

But yeah, but there's a lot that can be done in terms of simplify. One of the things is deploying a traditional relation database in containers. It's it's challenging.

It's it's not a it's not an easy task again. When you when you put things as performance scalability in the context. It becomes challenging.

You can just stand up a postgres in a container and say well I'm done I can use it but that's not reality when you need to scale. and when you get to operators, that's really bringing the automation, right? So it is how do I do backups in a way that I don't need to really fully understand how the backups work, right?

So you want to remove or create abstractions around that to allow developers or even the The expert managing the cluster to be able to back up the data to autoscaling when they sense. Well, there's a need. To increase capacity rings and need to increase compute for this database or more memory.

So all those things actually we have it today. I we actually evolving we are in our second iteration actually on our operator and we're not just working with openshift. Right?

We also do in work with AKs eks the Alibaba version of it Susa as well the Rancher so we all of those flavors we are integrating and certifying on how we can actually tap and build our operator to be compatible and portable because portability is also key here. You don't want to get into one specific cluster and be locked into it, right? One wise guy once said, you know, it's one thing to be wrong.

It's another thing to be wrong at scale. That's kind of what we're talking about. So you're gonna need a human to kind of manage all that process.

Do you think people are trying to do too much with microservices and distributed computing services and you know data has Gravity the laws of physics have not been suspended so are people not thinking through the physical location and the data related to where the application logic is properly. Yes, we see. We see that a lot.

Right? What I see sometimes is When you go to big organizations, what they tend to do is yes we need. To go into containers or we need to put everything in microservices and what you see is.

a lift and shift So they're not breaking things down. They're not rethinking the whole logic right and tapping into why would you go to microservices in the first place? Why they basically get the database install like again just don't postgrades or whatever version of database that they might be using relation or not.

They just lift that phone what they had on Prem or even in a cloud running on a virtual machine you just dump in there hoping that will address the issue. And that's not and that's not the case, right? You have to really rethink.

When you redesigning and you are thinking again scalability, you have to rethink the whole whole process by the whole framework, right? It's not it's not just about I need to use a microservice and when you talk about data gravity, I think it's that's really the The next big iteration for Automation in terms of like operators for example is the capability of sensing. Latency and trying to move data between locations one of the big things that we see when clients are looking into kubernetes deployment.

It's really well. I can be multi-cloud and everybody's like all multi-cloud. We are multi-cloud.

but Laws of physics. It doesn't it doesn't make sense for you to have your your data in one hyperscaler and then your your application running another hyperscale and then connecting because you're going to pay for for the traffic all those things and then the latency might just go to the roof again. There are some Experimentations in terms of saying well while data can be spread all over and we're gonna manage we're gonna make it low latency.

but when we look into real true Enterprise applications, they are tapping into open source to solve the issues. We see the reality is not that simple, right. They still a lot of complexes that need to be managed.

I think we getting there but we're not there yet. So so that's that's that's a great point. So the multi-cloud still does not eliminate the need to know where your data is located.

Are you apps you accessing that where you user actually getting into to access your data. So so yeah, that's that's That's a pain point that people need to consider. That's that's not going away.

Are we getting better and moving data? Because when I was much younger the movement of data was considered the root of all evil nothing good can happen when you start moving data around. So have we kind of solved that issue?

How close are we I think We have a lot more tooling now. and those two are very sophisticated in terms of allowing you to even migrate between different types of databases. One massive Trend that we see is people moving away from commercial databases into postgres.

That's that's why postgres became so. Popular because hyperscalives are adopting they have a lot of the tools to migrate data from one place to the other and then there's the promise of portability right which it goes back to. Okay, so I can move my data anywhere and basically I'm free right what people don't realize is there's a lot of hooks when you go to theoretical community Postgres the vendors are putting a lot of hooks in there.

Where when you try to migrate. The migration will not succeed not going to be successful because you have dependencies behind the scenes and that's interesting because for us fujit, so one of the things that we have is we added a few Enterprise capabilities to our Enterprise flavor of postgres, but a key thing for us is to maintain 100% capabil compatibility with community pool space. To the point where the client they will be with us not because of our software is unique or lock them in it's because really we providing a service is over.

You're actually providing the expertise for them to be able to think about data data movement or how they should approach data and if they're not happy with us, they can just move that to a community prosperous and then just use that or if they want to let their employees to just use community postgres on the laptops and then bring that to the Enterprise version only when they're gonna deploy that in production that's also perfectly fine for us. So And that's a lot of people don't realize that but that's a very different approach other vendors. You see there's a lot of around.

Oracle compatibility modes and and those things what we're folks don't realize is you just switching the evils right? So you were locked into a vendor now this compatibility mode. Yes, you can just flip the switch and then Have an easy migration, but guess what?

You just no longer locked in here. You just locked in here, right? So that that's That's something that that you're really serious considering portability.

That's something you should consider. So someone ultimately is your best advice to folks about how to get started because clearly this is not simple and you need some skills to go do this. So where do I go find these skills?

So of course the first place I would recommend is of course look us up on on a lab. We are like I said, A lot of our regional documentation. It was in Japanese where we doing a big effort on on converting that to English and we are also Building capacity outside of Japan.

So we're using that expertise globally so we open to talk with folks and we also open to interact with the community in terms of providing back expertise. We have committers into the postgres community that they don't do anything on our Enterprise side. They're focus on giving back Upstream code.

so for anyone thinking about containers to have Ops how those that play into what I'm doing today in terms of relation of database. We are here online. You can just search it up fujit.

So postgres you find Us online. And I'll be happy actually to also reach out and talk with anyone. We have a team of experts globally, and we we more than happy to engage in and have some of those discussions.

All right, folks as they always say, don't try this at home. Get some help. Hey, thanks for coming by appreciate it.

Thank you, and we'll be back in a few more minutes.