Ep. 8: Understanding GitKube with Tanmai
Description
Links Mentioned in This Episode
Transcript
Rahul: Welcome to “All Things DevOps Podcast” at the Bigbinary, and today we have Tanmai from Hasura. So, Tanmai is the founder of Hasura, and I’ll let him introduce himself. Hi Tanmai.
Tanmai: Hi Rahul, hi everybody who’s listening in. I’m Tanmai, I‘m one of the co-founders of Hasura, and we’ve been working with Docker and Kubernetes for a long time. We started using Docker and Kubernetes both just around the time they were both hitting 1.0. We’ve been using them as tools internally to implement the platform and a toolkit that will make life easier and life better for developers who are looking to build out applications, so the primarily our aim is to accelerate process of kind of backend development and to accelerate the process of Devops, and internally we use Docker and Kubernetes.
Rahul: That’s great. So, a little bit…I’m just curious to know about, why did you choose Kubernetes as in platform? You have mentioned that you are working from what Kubernetes origin 1.1. I still believe 1.1 was not that production ready and Kubernetes was just evolving, so what made you guys to take a call that, “Hey, this is Kubernetes, and this is what we’ll be building our product or tools to simplify the life for developers?”
Tanmai: So, I think around that time one of the four pieces that we built out was Data-layer, and the data-layer is still one of the kind of the best pieces of the platform today in our opinion. What the data-layer does is that the data-layer basically creates the data API on top of an existing data base like postgres. So it gives you kind of a high performance Graph API on top of the database. So, it gives you API in JSON, it gives you API as in Graphql which we added recently. So this system basically, we would deliver this layer in fact and so we would have to Develop is the binary on top of existing databases. At the time Hasura as a platform hadn’t come together. At the time we were kind of just building up this. We were just working on this particular component. We were kind of shipping these binaries and we realised, “Hey, you know, this has to become little more convenient. This would be painful.” Building this binary and then moving it around. We just need a better guarantee that it works everywhere. And then there was an associate who is using python, so like shipping a binary and making that portable across different system is not so hard, but then we also had a piece in python and then we were like, “Okay, we need something to solve this problem.” And so then we came across Docker, and we came across containers being used for packaging.
We started using containers and we were pretty excited about it, and because we were so young in this ecosystem we started putting in production without knowing maybe probably shouldn’t have been put in production, but I guess we learned how to do it right. So, we started putting these components inside containers, and then we started installing these containers and deploying these containers, and when we were developing and then working with these components for different plants we realised that it’s just a gigantic plain to do things, like at the time Docker didn’t have that flex, right? So you would have a container and then it will not be supervised. This restart flag itself got later, or the biggest problem at the time, and the single biggest problem was port mapping. So if you are kind of developing with containers and you’re deploying containers on a system we establish heads staging environment for all the developers. You have to do this trick with port mapping, right? So you have to say that, “Oh, okay, the database come the data layer plus the API layers, plus the API gateway. These will run on these particular ports.” But now you have a shared staging environment, right? Where you want to run multiple containers together, and then you are like, “Client one is on port 30,000 to 30,100, client two is on port 30,100 to 30,200” So, we did a lot of these fairly tedious stuff, right? And we were like, “Hey, you know what? This has to become easier. We need some kind of orchestration to either set up these containers, figure out what the right ports are, set up the mapping, build little bit of supervision at least so that we don’t have to manually manage so much of it, capture the loads, keep it somewhere.” And then we started kind of figuring out what kind of tools to use, and around this time also or maybe a little later Dase Evan was coming out. They had written their own orchestration. They had written their own kind of orchestration system on for-for containers, right? And when we wanted to figure out how to do this orchestration we came across Kubernetes, and then we kind of studied the architecture and the abstractions, and a few of the pinpoints that we were looking at solving, and the elegance with those particular problems were solved by Kubernetes. We were basically sold, and as I said when we just started using Kubernetes, and it was absolutely not production ready, in fact I would argue that it’s hard to run today also for developers. You need to dedicate Docks people, you need to dedicate Kubernetes people to be actually running it. There’ll be some… so, we’ve run some of the largest head in Kubernetes structures in the world, we have a huge multi-client cluster that is running kind of code and coding production. It power so it’s not really production for our users, but it’s production for us. We run into all kinds of weird issues with Kubernetes and today things are just impossible to debug, things for which there’s been no kind of monitoring that has been implemented yet. So, it’s been that kind of long journey with Kubernetes for us, but making that decision at that time was absolutely the right thing to do, and along the way things like swarm and volumes came along, and we were like, “Hey, you know what? It’s not going to happen.” I think Kubernetes is basically it because is the plugging architecture and whatnot, right? A lot of things make sense. It was clear that the Kubernetes had an architecture that would make it easy for the ecosystem to add more tooling to the Dockers Station System, and that’s what happened over the last few years, that’s where it has become so exciting, it’s become so popular.
Rahul: Yes, great. I thought like Docker was there but did we needed orchestration tools and basically the problem is like port mapping, super region, then we have deploying and enrolled with Kubernetes, and I think that’s the reason most of the people choose Kubernetes over Dockers swarm because of its simplicity and it did what people expected it will come from a production ready orchestration tool, that sounds interesting. As you mentioned you are running your tools, something based on postgresql and postgres is a used database and as far as they start with containers and ecosystem it is said like containers would at least in all the stages containers is for stateless applications. So, when it comes to some services like databases and some persistent data retaining thing, what is the strategy on containerization, whether it maybe Dockers swarm, Kubernetes, apache mesos, ECS or something. If it is about eight full applications that is always going to be pinned, but do you have been using Kubernetes. So, I’m just curious like how are you managing database as in it’s obvious with your role in deploy with your container, this starts with Kubernetes, and how is your Kubernetes hosted, how is it scaled, and just a brief high level overview in case, just because or why are you still struggling or running legacy or database services on containers?
Tanmai: Sure, so I think… I mean it’s a very broad question. So, what I’ll do is specifically just zooming into postgres and zooming in just databases on that part. What we’ve been doing is we’ve been running postgres or we used to run was postgres as a replication controller the first time more than a year ago with our back buyer volume which we used to kind of manage with some ad hoc tooling around it, and then over the years we kind of moved most people on…we moved most of the instances of our platform to have a single instance of postgres. So, as a developer if you are creating an account in Hasura and you have an instance of the Hasura platform, then that instance come with its own instance of postgres and this is a single node version of postgres which runs on top of the deployment pack by PTE which is absolutely okay, i.e., almost zero management overhead because postgres itself is very resilient to arbitrary starts and being reshuffled around so, that’s generally not a problem. We end up having to do a little bit of not doing cattle things, but doing pet things. We end up maybe to do a little bit of that, for example if you need to freeze postgres to run on a particular node, and then you have the PVs also being mounted on that particular node. I mean you don’t have to actually came out at the PVs on that particular node, but you kind of want to run the postgres deployment stateful set on certain nodes. So, we kind of want to freeze that to make that decision making faster for the Kubernetes for the control loop so that it doesn’t have to shuffle postgres around the different places. So, we do a few small things like that to make it easier for us to run postgres, but ho
United States
