DevDataSecOps – Karthik Ranganathan, Yugabyte

This is Textron TV. Hi everyone. Welcome back got another texture on TV segment here for you.

I'm my guest is gothic rock on nothing. He's the CTO. I believe co-founder of gigabytes.

Is that did I get all that right car that all that right on? Yeah. Thank you.

Perfect. So first of all, welcome, you know as we times as I was talking off camera, we haven't had the pleasure of having any anyone from you goodbyes on in a bit. And so I think the place to start is remind people what the company is about.

Maybe a little bit of your background and we'll go from there. Awesome. Perfect.

That sounds like a plan Allen. So I'm Karthik one of the co-founders and the CTO as you said Alan and I've mostly had a technical background before starting gigabyte in early 2016 and I'll get to why we started it. I was at nutanix for three years working on distributed cloud storage and before that at Facebook for about six years working on the first generation of no SQL databases.

So myself. I met my co-founders at Facebook and most of the original team engineering team at gigabyte. We all worked together at Facebook building and open sourcing databases like Apache Cassandra and Apache base and it didn't seem like fun at the time but it was great learning.

We also ran these databases in production for Facebook at a pretty massive scale. Right? So it was the distributed databases and the distributed d-bas both of that that you know, we really cut our teeth that Facebook and you know, and really learned interesting things.

And so here we are building yoga by it and to answer your question the second part of the other part of your question. What do we do? Quite simply you go by bills a cloud-native version of postgresql, right?

So everybody wants to move and build cloud services, but the database they pick is invariably something like on my SQL or postgres, which is not Cloud native or databases that people are already using our databases like Oracle SQL Server tb2, which were made before the cloud era, right? So so we're here trying to modernize the database and offer the databases service things around it. So, you know Enterprises and various companies can easily and quickly build their their applications with velocity and put their features into the market and have them run without much pain.

Love it. And look our audiences is a technical audience. They of course no h basic Cassandra and all of the great tools that came out of that.

Facebook, you know Lab at that point as Facebook was achieving hyperscale. Yeah. And now if you don't mind just a little bit of the kind of cloud native aspect.

We were talking you guys were recently in Detroit at kubecon Cloud nativecon, maybe a little of the cloud native story here Absolutely. I'll actually start you know, you mentioned your reference Facebook. I'll start from there the like couple anecdotes to you know, kind of show the lessons learned and why we're doing this, right?

So at Facebook we started building Apache Cassandra first when we had to you know, kind of host the inbox search data, so people couldn't search through their messages and they were like, I think 150 billion messages. So I hundred fifty million messages being exchanged per day at the time and every message had a bunch of different words anybody writes to anybody they write some text and every word had to be indexed for every person sending and receiving the message, right? So that was a lot of Rights and it had to live across data centers all that stuff.

So Cloud native at the time and like it had to be available. You can't have people babysit it. You can't run it on premium Hardware, you know, even if a region goes down, it should reasonably be Level right.

That was that was the point and we said, you know, there was no database that could do it at the time. So we built one, you know know that as Apache Cassandra, but we said, you know in the cap theorem, we have to compromise on something we compromised on consistency. We said it's okay.

If somebody couldn't find their messages we re-index it, right but, you know pretty soon Facebook reinvented messaging itself into what is now known as messenger and when we started, you know building up to Messenger to release it. We said it's not just the search index. It's right.

It's chat. It's SMS. It's anything that's being sent from anybody to anybody and we simply could not predict what the usage would be once this product came out because it didn't exist.

And we knew that our product engineer designers being really good would make it a very sticky tool but we still didn't have a clue as to what to expect. So we said we have to build this infrastructure that can grow and Shrink as needed and you can like make it super large on day one. It's too expensive and if what if it doesn't take off and you can't say after it starts taking off.

Okay. Look give me six months. We'll come back and really Scale this to how you need it can do that.

It has to be something that's ready to go. But yet Nimble and quick enough to scale On Demand, right? So we ended up building hbase and and you know after we had fully rolled out and gotten like everything under control the new product went from 150 million messages per day to 20 billion messages per day.

It's Dave kept going up after that. I just kept growing growing growing right like crazy. And that was just one of multiple 10 or 20 different applications that we ended up putting on the system.

We had many petabytes of data thousands of servers under management. So we also learned that to be able to run this thing on commodity where things can fail and a lot of failures can happen and in the cloud like topology you needed to have certain aspects of the database like you cannot have somebody react to a failure in order to unblock, you know, a user from Gaining access to their messages or whatever data they have so so from there, you know, if you derive the cloud native aspects of a database, it really comes down to a few things that comes down to, you know be available no matter Doing a software upgrade you're doing a security patch you're doing like for example a node fails or Zone fails. You still have to be available.

So availability and zero downtime. That's a very critical aspect. The second aspect is scale.

We talked about, you know scale on a dime don't don't write size it early and don't say you can do it when the time comes you should be able to scale dynamically without taking down or doing a lot of surgery and the third aspect that has grown since is if you look at the public clouds, there's about 200 different regions where they have data centers. Whereas in the old days. It used to be two or if you're lucky three, that's that was about it.

So now you really have to think about how you peace and partition data and push it to different regions and that need constantly changes. Right as we started building out more data centers and started building out more data centers in Facebook. We saw that need too.

So it's really those three aspects I'd say and along with make it easy to operate because you know, you're scared your scale not just in the size of any one workload with the number of workloads also keeps increasing right? So so always available. Scale move data around and make it easy to run.

So those are really the underpinnings of cloud native in the database speak at least absolutely and either I mean we talk everyone throws around this term hyperscale and and all of that. What was it 20 billion a day? Yeah.

That's that's scale. Yes, you know the funny thing about Facebook where they build a product and they first tested out they roll it out to maybe 5,000 10,000 and then a million and then it's like, okay, let's roll it out to everybody and everybody is like two billions. That's a lot easier.

So yeah it is it gives it a whole new word. So recently have been talking about a concept you call if I get it wrong. I apologize.

Correct me devsec data Ops. Yep. Talk to us about that.

Alright, so so here goes right so devops was really like at least this is my view of the elephant. Right? Like if I have somethings missing, please do correct but like devops was born mostly to tell people the importance of not just building and throwing it over the wall, but to really think about how do you run it to the developer and to the operator to think about how do you codify your operations to involve more developer like practices?

So Version Control infrastructure is code think about these things because it's not the last time somebody's going to be throwing something over and it's not the last time you're going to be rolling something out. It's actually a very repetitive process and you know, the reasons that make it repetitive obviously are this whole Cloud native thing. We're in the application world.

You have to keep doing cicd and building and running very quickly or expanding to new regions or new clouds or all of that stuff right or building new service or whatever. So so that was the Genesis of devops, I think. And you know people started putting the SEC into devops primarily to point out, you know, look you can't just expect all of this to get done and then think okay.

Now, how do I secure this thing? Because it may actually be that the security has to break down some of those practices and also be built into this fabric right rather than built on top of this fabric. So, you know deaf secops started coming up mostly to to tell people look it is something you have to consider upfront right but I think in putting those together, I think we've done a good job at you know, earmarking those communities to come together Etc.

One of the things we forget or I see people forget is like they try to make data invisible right like and it's great to get started. Like I don't want to know where my data is. I just want my models and I can build my application.

So Dave is empowered but the reality is as the business starts to get more data driven all businesses are trying to do that the data architecture starts to get more important and and you know that starts Will be something just like security was before it starts to be something that slows people down after a little bit of you know a Runway to to execute it. Then slows people down to have to re-architect. Right?

So it's it's just the concept is just to think about data also because after all if you are going data driven, it's important to be data first also in your design, right like I'm not ignore that It's a great, you know, we we talked a little off camera and I was telling you. You know, I've been putting on the deaf SEC Ops event at RSA conference. Now this year this April, I think I'll be the 7th or 8th year.

Wow, we didn't always call it devsecops. We called it rugged devops. We called it all different things.

Right and we settled on deaf set cops. I don't know five six years ago not because I particularly loved it, but I realized that that's what the security community and that's the RSA conference is a security show. That's what they needed.

They wanted to make sure that security was right in the middle of it. Yeah, right that people realize security was important. It wasn't an afterthought.

Yeah, and that we need to build Security in now. My personal opinion was the devops. Had that from the beginning it was it wasn't just purely Devin Ops it was all of this built-in doing it, right?

Yeah. We really did it necessarily from a devops perspective need to stick second there. But if that's what it took to get that mindset small price to pay do it, I would do it every time.

Yeah, I think it's the same thing here with devsec data Ops, right? I think what we've seen over the last I don't know year year and a half is that people are we you know, hey stupid. It's about the data.

Right. We we almost lost fact we get we get so hung up on. Developing applications and our infrastructure and for too long.

The database was a bit of a red-headed stepchild right the whole data. Data, not so much data scientists, but the day the storage data analysis. It was always.

Secondary. Yeah. I first I got to make sure I have the infrastructure for it.

Second leaves my application and interfaces and all of that, right? Only recently have we really remembered the old adage. That date is King.

Yep, completely. Yeah taking care of that data securing that data. Is is job one?

Right, we've got without the data. We don't have nothing weird, you know, so if if calling it day a Dev SEC data Ops is what it takes for us to put data top of Mind here again. I say it's a small price to pay.

Yeah, yeah. Absolutely. Yeah, it's like it's almost like trying to make it pity to remember what are the different significant aspects to think about when starting, you know some new project or even revamping an existing project, right?

These are all the different dimensions to think about right so So let's talk a little bit. Now. We're kind of rubber meets the road here with what you doing with Hugo bite around this.

Oh, so, okay. So we talked about how gigabyte is building Cloud native, right and and at its core, you know, the cloud native movement is almost like, you know, the synonymous with devops in some sense, right like when it started and and the reasons because you know, firstly the cloud is failure Pro, I mean, if you look at the fundamental tenants of what the cloud gives you right it Advantage it gives you is it gives you all of this infrastructure that it can provision and give for you in a couple of minutes like and and I'm sure like, at least I remember I'm sure you do but maybe some of our listeners may not remember the days when it took many many months to rack and stack to a point where actually ordering and getting operational machines was singularly the biggest like Paul in the tent. It was just dictate everything like I remember times at Facebook like even for when building Apache Cassandra We used to order the machines before we had built the database and like yeah, we'll figure it out.

How many Mission I don't know but oh no. Hey, look I did. com days.

I help put together a company that was Back, then we called in an asp application service provider. There was no cloud. We operated data centers and we you know racking and stacking servers is what we did right exactly trying to get density and you know one you service to you servers.

That's right. That's right and EMC symmetrics machine. Yeah, that was a job what age of the rack?

Oh, remember all that? Yeah Power pain and pipe exactly. Yeah, you know this generation people who grow up, you know in the cloud native World.

They don't know from that. Yeah, you just order maybe a hundred machines and it's not just that's it. Right.

So so now that that barrier has gone away, right? Like if it took you a year to, you know, get your hundred machines you could do a lot in a year or even nine months six months whatever it is, right, but if you can do it in five minutes, you really can't do much in five minutes. So that whole bottle neck is gone.

Right? So the next bottle neck that it immediately falls on is now that you have your servers how quickly can you stand it up in order to Utilize it on one side and on the other side how quickly can you build your application and start sending your features out so it can be utilized right? And so that gives birth to all of the ci/cd and your you know infrastructure is code all of those type of principles, which is really at the heart of devops.

And what we do at gigabyte is build a database with all of the features and functionality of a well-loved database the most loved database. In fact, which is postgres and we read everything so to the point where as a developer, you don't even have a mental model shift you pretty much go from postgres to you go by knowing 80% of what gigabyte does because it is literally the upper half of gigabyte is postgres code, right but the lower half and the architecture we changed it to enable Cloud native, which means you don't have to be like if you if you if you release your application on top of this database instrument, you don't have to architect. How do you make it available?

You don't need that stand by to promote you don't need Load balancer, you don't need to keep adding and removing IP addresses and you don't need all of that magic. It's just taken care of for you, right? Similarly when you're scaling increases with you know, the postgres days are any traditional database you have to increase the size of your server.

So you have to go from a medium-sized server to a large size server and you have to actually make that physical move and either reattach the disc or copy over the data and switch over your application and that takes both work. Even if it's automated you still need people to do that because you don't want to make mistakes and it takes down time because you have to switch over the application and copy data, which takes time right? Whereas with eucalyte you go by DB the database.

What we do is you can simply add a node into the cluster and magically in the background. It will start moving and shuffling the data while your application is still functional and leverage instead of your three nodes. It's now going to go to four or five or six it's gonna start using bigger and bigger pools of clusters.

You can scale up or scale out whatever it is. We give the flexibility without impacting your application, right? So these are a couple examples of the ways we build into the devops.

Movement, right like and so if you're thinking, you know cicd fast velocity deployment ability to you know, run this on the cloud and secure this and be able to do that 24/7 thinking about things like how do you do like say nightly backups for the last eight days and with encryption with a particular encryption key that's rotated every month. All of these things. We can make really simple because once again the database and the database as a service software around the management software, we're all born in the cloud era right like built for the cloud.

agreed excellent You know what weird. I'm just looking here at the time saying that was I was a quick 15 minutes. Well, it's probably quickly as a quick 20 minutes.

We got to wrap up car. Think people want to get more information. Where can they go?

com. Right? Like that's obviously a starting point to help guide people.

Secondly, I would say we are a very inviting and very big open source project. com forward slash slack, which is like three free to join we have about seven thousand plus people in there like asking all interesting questions discussing interesting things or that would be a great place to jump in here, you know, and and thoroughly our documentation online is a great source. Our social media is active like across Twitter LinkedIn Etc.

So yeah number of number different ways or get a hold of me on Twitter and you know, I'm happy to to Route also. Absolutely. Hey, let's make sure you guys get back here regularly, and we keep up.

It's a great story The Open DB the whole. You know this whole data Ops movement and Dev as we call the dev SEC data Ops, you know, it's something our audience is interested in. Let's make sure we talk more until then though best of luck.

Yeah, thank you. And thank you for having me. It's great.

And yeah, we'll we'll do this. We'll do this sometime again regular updates on these things. Yeah, this is great.

I appreciate it. All right. We're gonna take a break here on Tech strong.

com. The you go by DB. We'll be back in a minute this texture on TV.

We'll be back.