#30 - News Flash - Hashicorp is going closed source?

Hashicorp left a rather cryptic announcement last week about future releases start using the BSL license, which may have huge implications to many businesses around the world.

Links:

• https://twitter.com/HashiCorp/status/1689733106813562880
• https://www.hashicorp.com/license-faq
• https://twitter.com/iamvlaaaaaaad/status/1690039537370824704?s=20
• https://twitter.com/0merxx/status/1690321901120307202?s=20
• https://www.theregister.com/2023/08/07/bram_moolenaar_obituary/
• https://taylor.town/-10x

Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops

Chapters

• 0:00 Intro
• 1:47 Hashicorp's announcment
• 8:34 Who is going to be effected
• 13:24 Open source effects
• 19:29 Licensing protection
• 24:01 Open source model
• 34:25 What can you do
• 42:50 Links of the week

Transcript

0:00

Oh man, ready, armor is ready, and action, no, not with the LV smell, okay, okay, okay, and hello everyone, and welcome to DevOps Topics, and today's topic is going to be a surprise, because Omero told me he has a big announcement that he heard about, it's not my announcement, and it's a very surprise, okay, it's not a good surprise, he wants to tackle me with the surprise, so instead of asking Omero every episode, like every episode that we say, by the way, this is our 30 episode. These are 30, that's a good surprise, it's a 30 episode, okay, so I mean it's party at the end, okay, you can join us to a festive at the end of the episode, let's talk about it, it would be an episode, because Omero said listen, there was a big big announcement, you got to hear about it, it's not about AWS, IP addresses, we already covered it last week, so this week is going to be Omero show, so Omero, no, I'll tell you what, I'm going to, I'm going to, first of all, just put it as is, and even the fact that it's a big thing, I think that's what we need to discuss, maybe I'm exaggerating, maybe it's not that big of a thing, maybe it's just a smile, you know, a small announcement and that's it, let's move on, okay, but the cool thing about this announcement is that I don't know what Omero is talking about, even though it doesn't sound very like, it's hard to trust us that we don't really, you know, do stuff before the show, but I swear, it can go anyways. It can go in many ways, you know, I don't know what Omero is going to say, maybe you're going to tell me, maybe you're going to tell me, Omero, you're overreacting, let's move on to, we had an entire episode planned on something else, let's move there, okay, I'm over here, I'm over here, okay, go ahead, all right, 48 hours ago, Hashi Corp released this tweet, I'm going to read it as is and then we'll talk about what it means, they're saying future releases of Hashi Corp core products will adapt the business source license as known BSL, we know our community will have questions, so please read our blog post to understand why CR FAQ to understand the changes, that's it, that's basically it, okay, now let's talk about what they're saying, before FAQs and responses and stuff like that, basically what they're saying, that from some point in the future they're not saying when, where, how, nothing, at some point the open source projects for Hashi Corp, where today are very much open to the point that you can take them and use them for commercial use, build products on top of them, we're talking Hashi Corp vault nomad, packer, everything, you know, all the wide range of great open source tools that Hashi Corp provide to us all, those are going to be under the business license, which means that is not so much free to use for your business, you can build commercial businesses on top of that and I'm saying can't with a lot of stars in the middle because there's a larger FAQ, I didn't read the entirety of it, but people responded with, okay, first of all, what's going on? What does this mean? We have a lot of businesses running in the world on top of vault on top of Terraform using nomad for their customers because they build stuff on that, what does that mean? Do you now have to, for example, it has been open source to that day, so you were okay legally, do you now have to fork it and start maintaining your own fork? Does that mean it's not going to get releases anymore? Does it mean that it does going to get open source releases, but you have to pay for them now? What's the meaning of all of that? And I'm asking questions that I don't think anyone yet have answers for and people have been talking about, okay, we have a huge enterprise build, I mean, half of it is built on vault, they've called lawyers in to start advising and the lawyers are kind of lost in the woods. So that's the announcement. First of all, I want to hear what you think, maybe I'm over-reacting, maybe I'm exaggerating, but I want to hear what you think first about that and then what you think the effects are going to be. So first, like, if you say so many, what's the first thing that comes up to your mind when you say BSL license? So it sounds like bullshit, even though it doesn't fit, you know, it should be BLS, but not BSL? I wish it's like bullshit. I wish it was, yes. That's the first thing that comes up to my mind, okay? Second thing is I just want to cut it, you know, cut this topic, so it will be as clear as it can. You said enterprises, which are based on vault blah, blah, blah, okay? So let's say just so our viewers listen and understand the meaning of it, okay? If my application is maybe a healthcare application or my application, you know, is a normal application, which is not related to giving like providing services to as a cloud services, you know, a company. So for example, medical care, okay? So my application deals with health or maybe with statistics or anything like that. And we use as customers, we use HashiCorp, Terraform, HashiCorp, Nomad, Packer or whatever. Does this affect us, you know, the normal people, regular customers, but not enterprise grade customers who, you know, okay? So first, let's answer this question. If you're using it on your own, you're building info for your own team, your own product, your own business, you know, so let's take a site, private and personal use personally is free, but as a business, you're a commercial business, you use Terraform to build your own infrastructure. You are good, okay? I'm going to read another tweet with a response they got from HashiCorp to kind of maybe stress that out. So first, that sounds good because my, you know, the company I work for and many companies that I worked for use Terraform and they're not providing info as a service or cloud services. So they're good. You know what? That's perfect. Let's touch on that for a second. I'm reading another thing. Someone replied, can you please clarify what competitive services mean? We're using Terraform to manage customer infrastructure, right? We are at the commercial customer all of Terraform. We use Terraform and we use that for our own customers. Does that compete with Terraform cloud or is that considered internal use? And they answered, hi, thanks for reaching out. If you're a system integrator using Terraform to manage infrastructure for your customers, you are not in violation of the license. You're good to go. It's fine. If you manage infrastructure for them. However, if you are offering a hosted version of to customers, please reach out to our licensing tatata at HashiCorp and talk to us a house. What does that mean? Does that mean that if he uses the hosted version of HashiCorp, does that mean if he uses Hashi Corp with his own provider? I mean, I am taking that a bit to a bit to an extreme side. Yes, you can read the things as is. They're not very clear at the moment about what's going on and it's not a clear cut answer. Sure. Yes, again, if you're using Nomad as your container orchestrator today internally in the organization for your own product, it sounds like you are good. However, your product probably provides some value to end customers, right? What if part of that value means building infrastructure for them? Maybe you again, like this guy using Terraform to deploy certain bits of infrastructure on their side in order for you to communicate with it. I don't know, that's just an example. Same goes for vault, which has a lot of more application in that than siphing because vault at the end of the day is a secure storage for your secrets. Personally, I know when he's really company that uses vault for crypto. They are kind of a custodian for Ethereum if I'm not mistaken and they store wallets and they use vault for some type of encryption. And when I say vault is not actually the service, they use the vault codebase. I mean, they use the product as is as a library within their codebase and they're doing some stuff with it. Is that a violation? I don't know. Do they need to now, again, like I said at the beginning, do they need to fork vault now and start maintaining that? What does it mean? It's a lot of questions. A lot of questions. I'm very few answers. Okay. So again, I say, let's cut it. Okay. A lot of questions. A lot of untills. Let's try to be as clear as we can. So first, it sounds like if your application does not deal with provisioning infrastructure for customers or stuff like that, but you only provisioning infrastructure for yourself as a business. You know, even as a business, you're good to go. So medical care statistics or any other, I don't know, like gaming or any other thing like that that is not related to directly providing cloud services or infrastructure as a service or stuff like that, then you're probably good to go with the license. Of course, you should consult with the lawyer blah, blah, blah. But if you are like maybe zesty or any like do it international, I don't know, any other cloud reseller or any other cloud service provider that and you do provide infrastructure, maybe as a service or provision cloud infrastructure with Terraform or build maybe AWS, AMIs, you know, EC2, AMIs, Amazon images with back here or anything like that with HashiCorp or use vault to store secrets, as Almer mentioned. And you use it to like to provision resources for customers. I'm trying to understand the yeah. Yeah. So how okay, so let's classify each one, but we're not going to do a different one. It's really hard. Terraform is quite easy because it sounds like if you provision infrastructure for customers, like let's say white label customer, let's say a custom tenant for a customer and you use Terraform for that, then it still sounds within the limits. I'm not sure what I was about to say. Look, I wanted to talk about the ripple effect of that. But the first time in my life, I'm happy that for our company, we use CloudFormation for that. I think nobody ever said that. Think about Amazon. They can make like great things out of that HashiCorp all of a sudden breaking kind of breaking again. And maybe I'm thinking that too much, but it's kind of breaking Terraform in its free version sense. Amazon can do a lot of stuff on top of CloudFormation. Now, maybe that's going to take, you know, another huge step forward because companies will kind of lay in on that instead of going all the way to HashiCorp. And I mean, the ripples effect go even further. Think of the philosophic around open source now. People looked at what I think elastic did last year or two years, I don't remember. Yeah, with open search. Yeah. So they kind of closed stores their service, they're free to do so, right? But when you build an open source product and you let people use it, they're relying on it. So it's different and you can do it in many ways. And elastic think of that it was huge, but it was one product. HashiCorp are not doing that. First of all, across the board. And someone said and rightfully so, maybe you should start looking at open source different. Maybe when I'm looking at open source, I'm only going to a neutral sources like CNCF, for example, if it's coming from CNCF, it's not backed by a company that will close it tomorrow, right? So I'm good to go. Like when Kubernetes used to be Borg at one time and it was Google, Google could very much, you know, today we're using it. It's open source. It's backed by the open source community. Nobody can take ownership over that and start charging money, but if it was Google and developed within Google, they can do the exact same. So people are starting to think that's kind of a supply chain attack, right? Like the cyber security attack when you attack people through the dependencies, that's kind of the same because something that you rely on and used to be free and maybe your product is entirely based on that. Maybe that's starting to cost money that can kill your business model. I mean, huge enterprises can can think thoughts and do whatever they want. I guess with an extent, but smaller businesses can actually dive. There's really, really complicated and philosophical idea. They're saying HashiCorp, maybe it will go under the radar, like Docker did, right? Docker started charging money and it was very graceful. They told us, I think, a year earlier, they told us you have a year to do things and so and so, but then we're going to charge for Docker hub and it was very soft. It wasn't, yeah. So it felt like you have the alternative of using maybe Podman or any other container on time. And you knew what was going to happen, right? And you exactly what was going to happen. It was soft. Like, I don't think it was like a boom. And with Docker, you know what was going to happen. It's soft. I can take my entire set of containers. I have a year to do that, to take my containers, put them somewhere else, start paying for Docker, which makes sense, whatever. This is kind of a, this, I mean, the ripple effect is going to be huge and they're saying someone said, again, the philosophical idea that you're hurting the open source community because people are now going to start thinking twice and three and four times whether to use a project or not and starting to see who are the owners. Who is it backed by? Can I use it for, you know, the lifetime of my product or my company? And that's a, that's a different question. Okay. So let's put a few hats. Okay. So first, let's put a hat now that we know that this can happen. Let's put the hat of choosing open source. Do you think it will really affect you to select open source projects differently than you used until this date that you heard this announcement? Honestly, yes. Yes. I mean, again, elastic is just with air quotes as search platform. Docker is just a container runtime. HashiCorp is an entire company taking the entire set of products and not killing it, but I don't want to say load sourcing, but when the license, when the license changes huge. So I'm going back to vault because I think this has the most use cases to be kind of the base layer of products because it's great in securing secrets and encrypting them and being able to fetch things in a secure manner. That is the base for many, many, many companies. And now when you're building a product or an open source project or surely a commercial company, you need to think a lot more times on what you're basing your things on. Again, we know she I'm working myself on one right, but there are so many startups basing their product and their stuff on AWS. HashiCorp, until this day, or whatever the date is, have been giving things for free. You don't know what that I mean, the license is so open. You just take it as is, which is weird on its own. I, for the longest time, I've been kind of amazed by the by HashiCorp's ability to keep themselves alive. They have far more users open well, not abusing, but using it as opens or software, it's like, you know, volunteers doing stuff, but it's not really fun. I have a question about, okay, so first we cover the fact like, how would you select open source? Now you're taking it to a different place and I want to touch that. Yeah, to remind you, HashiCorp does have a cloud platform, for example, terraform cloud. So if you want to provision resources with the CI CD of HashiCorp, you can use terraform cloud and you can manage your environment and have you ever used it? No, have you ever considered it? Yes and no, yes for a second and then I was like, but it's easier to do it all my own, but again, it really depends on the company. Some companies doesn't have a DevOps engineer. Some companies are made out of maybe a CTO, two engineers, and one CEO, that's it. So they want to do as cloud is can, as cloud as they can, if it's a word. Okay, so they do have this additional services they provide, like cloud services, right? Let's take a look at Grafana for a second. Okay, so you know Grafana, most of us, I think, DevOps engineers knows Grafana, where we can visualize our logs and matrix and whatever. Or yeah, and Grafana also did, I can say the same thing because it didn't did a, didn't do a closed saw or whatever, but they did add a Grafana cloud. So I don't know if you know, but I did use Grafana cloud. Okay, so in order to visualize my metrics, in order to have them backed up, where someone takes care of it and not me. So there is a Grafana cloud, I think AWS also, yeah, it's like a big service. It's a big thing where you can push metrics from your Prometheus locally to, you know, from your clusters to Grafana cloud, I think, by the way, sorry for cutting you out, but Grafana is a fork of Kibana. So it kind of touches the same point, although it is a fork, right? It took it from a certain period in time where the license allowed it. I think it still does, but in the certain point in time for sure, it did allow it, and then they built a company around that or a product, rather, just another example. Okay, but, but what's, so I'm trying to understand now, I gave Grafana as an example, like, I know there is Grafana and Grafana cloud. Good for them. Now there is Terrafo and Terrafoam cloud. Good for them. Now I'm trying to understand why do you think there's such a big difference with this BSL, because it sounds like it only affects businesses that provide cloud services, you know, like that provision, I don't know, infrastructure to cut. I'm looking at Terrafoam because this is the one that I'm mostly using. So that's just an info structure for so look, customers, but that's exactly the point. Just the fact that both of us are now hearing that and we're unsure. So if I were to build something or just to build something within my company that touches customers or anything, if I'm tomorrow to build something in Grafana, I need to think twice and maybe involve our legal department in it. That's a problem in its own. I'm sure that many potential customers of HashiCorp who, that was none of the question till they stay. You could just, I mean, use the open source version of HashiCorp, of course, whether that's vault, homemade, Terrafoam, whatever it is. I think you'd be surprised because people, okay, so engineers who work at companies, like I do, where compliance is a thing. So you'd be surprised, I'm not sure if you know, but you'd be surprised that each package that we use in our application across all of our applications, each package license, we take it to the lawyers and make sure it's legal to use it. I think everyone should do that, but yes, especially when you get up, but that's what I'm saying. You gotta do it if you're compliant. It's part of the compliance. Yes, yes, it's part of the compliance. So it's not something that I even need to push. It's something that our compliance team says, guys, we need to list of all the versions and all the applications that you use. And we need to understand what's the license according to that, see if we can still use it or not. So maybe companies that are compliant, you know, with, I'm not even sure which, you know, which regulation or which state event, but like what they need to meet, you know, which rules, but they know how to do it. So we shouldn't surprise any company that meets compliance requirements. Let's give a tip for one second because you touch on something really, really important. And I'm kind of moving away from this thing and touching this license for a second, even if you don't have to comply with something, using projects in your open, I mean, open source packages, but maybe using them for commercial use, for what you're doing inside your company may not be 100% legal, not in the fact that you're not a, you're not in violation and anything, but maybe you're exposing yourself to future lawsuits. So one thing that you probably want to do is define an array or a list of licenses that you're okay with, whether from, that's from your legal department or whoever, ask your VP on your indie and in the CI step, like add a CI step throughout the entire set of pipelines that scans for those licenses are cross every package that you have imported because dependencies is while this is one thing that can kill you. And it might not be a supply chain attack. It can be just a lawsuit coming from something that you're using or kind of abusing the license. So just a tip. Yeah, you can also integrate so many companies that do that for you, where you can just integrate an agent or something like that, just like you mentioned, you know, that has this list of licenses. And again, companies that work with compliance and need to be compliant for anything, they do use that. Yeah, so this is usually for people who are not really aware to, you know, lawsuits and compliance and regulations and probably young startups don't really understand that, you know, it's more for mature startups. It's not that the proper HIPAA, you know, something that is more, it's harder to achieve. Right. But when you're a mature company, maybe you have a legal department to fight that lawsuit. If you're a small startup, and that's going to be the thing that kills you, that's a really shame. So maybe think of doing that from the get go. It's not that big. It's just there are great open source scanners. Maybe we leave something in the description. It's just one line to run and make sure that before you merge stuff into production, make sure you're using it. I know you won't believe me, but you started this episode, we're talking about how to change the world right now, you know, or how should co-op change the world. And my, you know, in the corner of the week, so my topic was, did you know that this week I was able to import, like I was about to tell something very happy about an experience that I had with Terraform from version 1.55. So it's also very specific. And instead of, you know, now I don't really want to talk about it, because I want to investigate. I think I will, but I want to investigate more about HasheCorp before I give them the stage for that, you know what I mean? Look, I think, yes, but we shouldn't take away what HasheCorp did and gave for the world. I don't think I'm ever going to do that. They gave so much and they all deserve the credit. And I think we should talk about this thing is maybe it's a good thing that there's such a backlash over this announcement, because people will look into it and HasheCorp will look into it and everyone will think about what they've said and done. And I'm sure at the end of the day, I mean, knowing HasheCorp, I hope it'll go fine. I mean, they'll handle it gracefully. Maybe it wasn't the best announcement, but they will find a way to handle it. And things will be okay. But it's it sounds like a illusion. Well, I don't know. Maybe I'm too optimistic, but I hope so. There's another thing here, by the way, that we need to think, yes, open source is a problem. We need to think about what open source tools we use. But let's talk about the business model for a second. If you're seeing a company that gives so much open source, I mean, so many services for so long for free. It's kind of a red light, isn't it? Or a red flag? Because I've, again, I've been thinking of this thing. I don't agree with that because I saw no, because as you can see terraform cloud or maybe they also have HasheCorp vault as a service. That's usually the way that's new. Usually what those companies do, they open source, and then they give you maybe the pla, okay, local stack, local stack. Remember, I talked to you with you about local stack, or you can run AWS locally on your machine as a container, which is an amazing for tests and everything. So they have a poor version. And I really liked it. You know, they, you have basic services like systems, men and jail, S3 or very common services in the free open source version. But if you want to use complicated services like maybe AWS, Cognito, or any other kinases, or maybe it's also include an intimate remember, but Cognito, for example, I can tell you for sure, it's only for the poor version. And it costs money. And it makes sense, you know, people worked hard for it, and they want money for it. And it makes total sense, right? So it's a bit surprising. So when you say a company that gave away for a long time and open source, blah, blah, maybe it's a red light, I'm not, I'm like, no, usually they provide a cloud service, or usually they ask for more money for a premium service, but they don't take away the open source project and say, listen from now on, you can't use it anymore. You know, that's that's harsh. So here's what I think I agree with you. I very much agree with you, but maybe that's where you draw the line of what is a, you know, you have a free tier. What's the free tier? And what's the premium version? What are the premium packages of the premium features that we kind of charge for? With their form, there isn't really, it's not really a premium. It's free. You can take it. The only thing you get from the server, I mean, it's not the only thing, but the main thing you get from the service is a managed state, right? They manage the state for you. And maybe you get a nice map that visualizes things. And it helps you with a nice UI. Fine, cool, perfect. It's a good feature, but I think 99%. I've seen one company and I think I worked with well over 30 one company, one team that uses the cloud version of Terraform. Maybe I haven't dealt enough with enterprises. Sure, sure, it's my perspective on one thing. Only I get that. But one company did that. And the only reason they did that is one, it wasn't even for the state. It was for the visualization. They really liked it. And they didn't care paying for it because the VPR and they really liked seeing their infrastructure kind of mapped out, which is fine. But managing state in Terraform is so convenient. It's like directly like about two S3, DynamoDB protects you, etc. So we don't have to dive into that. But it's so easy. And it works for everyone, right? It works in huge scale. I think they also offer the actual plan and apply. So I think it's not just managing the state. I think they also offer the plan and apply like actual runnels that will actually run the plan and apply with the recovery system and whatever. Perfect. Also, also, I want to add about Terraform. You're saying, listen, it's frame you will do the other line. So for example, like Terraform has this option where you can, you know, when you plan something, when you want to plan, you can say a lock timeout or maybe how much time do you want it to timeout before it breaks? When the lock is locked, you know, when you use a lock in Terraform. So for example, in the premium, maybe you can say, okay, in the premium, you can set it for more than 10 minutes, just giving an example. But in the, sorry, yeah, in the frame, okay, in the open source, you can make it up to 10 minutes. But in the pro version, we allow you to set it to an unlimited time, just to give you an example that if you're used, if you're a small company, that's okay, but you can still build a product and add features to it without breaking the frame you use. You know, and eventually adopt them as premium users because eventually, look, look at me using Cheji Piti. I use the free version. I enjoyed it so much. I decided that I want to support this project. I really like it. And I want to use the Cheji Piti model for. So I'm paying every month, even though it's free. But here's the difference. You got the model for and you can use it further. You get a lot more tokens, right? You get, I guess, a faster service. What I'm thinking is specifically with Terraform. We can touch other services in a bit, but Terraform specifically, I think the line drawn is not in the right place, right? Because you gave a local stack as an example, local stack tells you you can use these services as three, say, two fine, all the normal services. You cannot use Cognito. Cognito. Okay, fine. If Terraform would do the same in it, they would limit the providers that you can use. Sure, you can use open source ones. Maybe we give away the AWS provider, one of the most widely used Terraform providers of Terraform. If you'd limit to that, maybe it would make sense for people to pay. No, they should limit in features, not service, not services that they support. I get that. I'm just saying the structure of Terraform is kind of weird. I'm not saying I do it the same. I'm just saying the line is drawn in a place that it's very hard to charge for. And that's why most come. So I gotta give you an example. Okay, I gotta give you kind of like corner of the week in three seconds. You know, I'm pushing it here. All right. So this week, I wanted to create GitHub Actions Windows Windows, right? So I need to create an easy to launch template and then change the user metadata and do a lot of stuff manually. Because before I do something in Terraform, I like to do it manually in the console, see that it works. Connect to the instance, see that the runner is registered properly to GitHub Actions, you know, to check the whole flow before I'm running, plan, apply, plan, apply, commit, push, whatever, you know, doing it manually in the console, like in AWS console. So I did all that. And then I was like, man, I wish towards a way to import my launch template because I created a very good launch template. Like I was very satisfied with my manual work. And then I'm like, I wish there was a way to import my launch template in such a way that it will also write the Terraform resource for me. So not only import it to the state, but it will actually take it like the things that I did in the graphical user interface with AWS and write down a Terraform TF file with the generated things that I've done. So I, if I totally surprised, there is such a thing from version 1.55, which is absolutely new, you know, especially if you use Terraform, you don't upgrade every day. Like I think I, before a 1.55, I think I used 1.4.7, something like so, I don't upgrade every day, you know, it's a big change. Okay. And you can do that. So to give you an example, like this specific feature can be a premium feature, you know what I mean? It's a big feature. I really like the way of doing it. I mean, I like this feature. Think about it. You're doing things manually. You don't even have to write Terraform TF files. So after you, you just with a few clicks, you did in the AWS console, yeah, you, you plan and you get a Terraform TF file with everything that you already done in Terraform in the console, which is amazing. Isn't there an Israeli company doing that control monkey I think? I think that's what they're doing. It's interesting to see how this feature release is going to affect them. This one and the announcement, but it's very interesting. I think that's what they're doing. They're kind of importing your existing info into Terraform code and then starting managing that from there. Okay, so Terraform, like they created generated the version of the things you did in the cloud, like in the graphic user interface. Amazing. So what I wanted to say is, so that's like the cut point in my eyes, like giving those away, those features, which are amazing, like more than managing a state and more than supporting providers and whatever, they can also create maybe a customized Terraform provider where the plan takes less time because it's more efficient because it works with with a different algorithm. Just giving you exactly. I have, I can shoot infinite examples of how you can make a product premium. I'm just thinking with Terraform, it's kind of more complicated. Here's a very straightforward, I'm keep going back to it, but a very straightforward thing that can be a service, which is what sometimes people be there from using what it's, I think it's the far best and the most superior product you can find, not even open source, just the best source of secrets management, but not everyone, including me, are not using it because managing your own secrets is kind of scary, even if it's not backed by backed by a product that you run, maybe it's backed by DynamoDB, something that you can air quotes, trust. It's a service, it can easily lock away, you can easily hurt it, misconfigure, et cetera, et cetera, using a service, feels more comfortable, feels nicer, feels like I'm securing my stuff even better. That's something I'd pay for. When you say use a service, you'll be felt to AWS secrets manager or AWS ponytail stuff. No, no, no. Vault is a service by HashiCorp, like paying to HashiCorp. Okay, so I once compared it to first of all secrets manager, but AWS have systems manager with KMS, which basically gives you kind of the same, it's not exactly the same. I compared it to what vault, what they want for that, and it was so expensive, I didn't even think of that. It's relatively new, I think it's one or two years old, the fact that they have a service for a vault, but it was so, I mean, I was so happy when they announced it, and then I went checking the pricing and it was just not relevant in any shape or form. I, baby, it changed over time, I don't know, but that's something that for an example that would be, that's the perfect service in my eyes. That's the perfect sauce that they can provide. I mean, put no matter side, that's classic open source, terraform, classic open source. I mean, vault is the classic open source tool that you can and should charge for and many people would buy it. In my eyes, it was too expensive, maybe it had changed, but that's just, there's also, it's, I can say the same four palm issues, where Amazon provided AMP, Amazon palmittios or something, which also costs tons of money, you know, you're like, why would I use that service if it's cost way more money than I can do it on my own, where it's not such a hassle to do it on my own, right? It's not a huge hassle. There are services like, it really depends on your use case, of course. So if you want to do maybe something like tunnels or Victoria metrics or anything where you want your metrics to be backed up, and you have to meet regulation, and it's scary, and you don't want to dedicate too much time for that. So maybe yeah, using the managed service is okay, but I can say most of the time, but specifically for palmittios, it's not a hassle to spawn your own palmittios controller with the health chart or anything like that. So moving on, moving on, moving on, let's put another hat, okay, another hat we like hats. Okay, so the other hat that I want to put on our heads is I'm in a company that provisions infrastructure is code with Terraform to customers, and my company does exactly what HashiCorp wants me to stop. Okay, I don't have any other way to say it, but I'm going to violate the BSL license or whatever. Yeah, somehow, because I'm using packer, because I'm using whatever. What do you suggest that I do? Watch, okay, so when I realized this is the case, we talked with our lawyers, they said, listen, it's an issue, please seek other products, please seek for an alternative. What's your plan? Like what's your go-to plan when you hear this kind of thing if you were wearing that hat? Again, far from being a legal guy, but here's what I think you should. First of all, map out your products and understand whether you are in violation or in a risk of violation. If you do think you are, think of whether that's really hard to mitigate in terms of moving to another alternative to a different technology, or just write to HashiCorp to that. It even says so in licensing at HashiCorp.com, but I mean, getting, getting line. There's so many people angry there in the comments. I think it'll take them time to get to your specific question, but do that and make sure with them maybe maybe you'll find something you didn't expect. So I think that's the approach. It's as simple as that, right? If you are going to be in violation or you are scared of that, check with them, think of alternatives. I don't think it's going to be, again, it started like, it sounds really, really extreme. I don't think it's easy to do that. I want to really go to plan. Like, what would you day one, Omer, your CEO tells you, listen, we gotta move. You're using, we're using telephone to provision infrastructure for customers. What do we do? What do you do? By the way, there's always the option of paying for the service, right? We don't even mention that you can pay for the service and that's it. But assuming my product is so well integrated with telephone and I cannot pay for the service because it's too, too integrated, you know? It's like maybe I need to pay for the license, but you want to check and alternative. So what would you do? Would you transform it to cloud formation? Would you consider using maybe AWS SAM, which is also some sort of information? I think not because if you're okay, if your product is the ground of that is therefore, and you're using it, if everything terraform has to offer, probably what you're going to do is either pay for this, like pay for a license, if it makes sense, or if it's too much in the sense of what you're doing, maybe you have thousands of customers using that and it doesn't make any sense, maybe fork it because it is open source as of today and the current license allows you to fork it and start maintaining it. Not the best solution in the world works, right? That's what happened with open search. There's a community fork of something huge everyone uses and you can either use that or pay for a license. So I think these are your options, but again, this thing is far from being over. It's going to have a lot of phases. We're going to hear more from HashiCorp and from people using that around the world. The ripple effect is going to be huge and it's going to be, it's going to be here for a while. I think it's going to push a prophecy that I have. We talked about this prophecy a few episodes ago a long time ago, where I told you that I think that Kubernetes, eventually is a state management application. So for example, for Terraform, if you want, you can replace Terraform with Kubernetes if you think about it because eventually it's a state management framework where you can manage your infrastructure with deployments and everything, just like Terraform does. But the only thing is, you need to support all relevant cloud resources, which takes time. This is what Terraform currently have. They started only with, I think their first module was VPC and then they started growing up and also provided EC2 and all the other providers. But if you do the same thing in Kubernetes, where the state management's just like Terraform does, then maybe this will push open pods, open source projects to use Kubernetes as a state management. I don't know. So here's my counter argument. First of all, I remember with the prophecy counter code. Last time we talked about it and I told you that's kind of inception. You use infrastructure as code to provision Kubernetes and then you use another infrastructure as code to provision the state inside Kubernetes to start building more infrastructure. I think that's kind of a use of Kubernetes and it feels like the world is going there at the moment. Everyone are deploying everything, including serverless into Kubernetes, pushing everything database. Everything is pushed into Kubernetes and it will work to some extent. First of all, you don't have a, and you can't do everything within Kubernetes. If you want to use a DNS services, which I wanted to talk about today, we'll push that to another time. It's hard to create a DNS service or a server within Kubernetes. I don't even think you want to manage your own DNS server. Maybe you want, again, when you say DNS server, just to be, this should be sure, around 53. If you want to use route 53 and use infrastructure as code, that's not something you can provision within Kubernetes. I mean, I do it with external DNS. Do you know the service? Yeah, that's kind of different. That's how you manage your internal DNS routing. It's not literally a DNS server that gets requests and replies with the, who is this IP and your, okay, okay. I mean, I was, I was more, more referring to a service that can create route 53 records for you, you know, external DNS does that. So yes, that's actually, yeah, okay, right, right, right. You're right. I didn't think of that sense. It's a good example for using something. So it's not within Kubernetes, it's just using Kubernetes to provision that externally. But again, by the way, it's the same as if you think about it, this is exactly what her from does. So when you add those annotations, if you're using the service, the Kubernetes service external DNS, if you add the certain annotations to certain service or specific source, whatever, it will eventually create the route 53 record in AWS, which is the same as a like telephone, UK, you write down a code and then you see it in AWS, same thing as external DNS does. And you can add the same thing for everything, right? External DNS, external secrets can do the same with vault or secrets manager. Yeah, exactly. You can write exporters for everything. And it's different from Kubernetes. It's different from creating maybe a Kubernetes deployment for example, because this is internally in Kubernetes, you know, but when you use annotations or stuff like that to manage cloud resources, it doesn't sound that bad. So that's my office, the owner. So again, I'll be the, the counter argument. If you push everything into the same I'll take Kubernetes as a point, although it's not really a point because it's an orchestrator. And as such, it is a platform. There are many nodes and many pods, but at the end of the day, you're relying on a control plane. Hopefully you're using a service or it's a control plane. If that breaks and maybe I'm using route 53 to kind of balance out different deployments, right? If I'm in a control plane at the end of the day, let's talk about the R is contained in availability zone. It's no, it's contained in origin. Maybe you need to shift to another region or do something else if you're in your entire application or your entire company, sorry, is kind of dependent on the external DNS system. And that does everything for you within one cluster, you are in a problem. If you do it just for the specific cluster, fine, but if you contain everything and anything inside one cluster, that's going to be a problem. I mean, Kubernetes can break, it can find its edges at the end of the day. It's also, I think I understand what you're, yeah, so you touch exactly what R from does. So how are you, how are we as the ops engineer? I think usually use Terraform is provision infrastructure like VPC and stuff like that with Terraform, but the workloads you manage with Kubernetes, the application itself, the deployment itself, usually you manage it with Kubernetes, not Terraform. So Terraform is mostly for infrastructure, but not for applications. That's another approach. By the way, you can kind of distribute yourself between technologies. For example, not by not thinking about this tradition, but we happen to that, Terraform in our case is used for kind of high-level stuff, VPCs, connections, bearings, routeings, DNS, et cetera, everything that has like an applicative concept like literally the applications, functions, stuff like that, they're managed by at the end of the day's cloud formation. It can be serverless as a framework, but at the end of the day, it's just cloud formation, stacks deployed. So that creates kind of a separation between the two, and we can offload ourselves to one or another if we need. Okay. I think it's time for the corner after you shocked us with this BSL a bull. Sorry, I really didn't want to talk about it. Okay, so let's move to the corner. I already talked about what I did this week, importing, you know, stuff that I did in AWS console to Terraform templates, which was amazing. But again, like wild Terraform version 1.55 or something like one port 1.5, like the latest indicators. And Omer, I'm doing effects only for you because you are only in the corner. You are alone in the corner this week. Okay. So are you ready? But look at the effects. Okay. Cool. Okay. Yeah, we did. So in the corner, Omer is going to talk about an experience knowledge or anything that he did this week last week, last year or next year. Omer, go. Okay, two things. Let's say the first thing would be continuing a sideline, sad news this week. Shame on me. I forgot my name now, but the creator and maintainer of VIM passed away this week or last week. So that's was a very sad news to the community. VIM, yes, it's an open source project managed by our really big community and a supportive community. And it has its forks, VIM 8 and new VIM, et cetera. This dude, which we all loved has passed away. So the community responded to that. I'll leave a link to the announcement below. And a project that I wanted to share is not really a project. It's just let's take it to a more funny concept. We had a bad, a very sad episode. Very sad episode, I don't know, very sad. So let's go to see I'm using stuff. There's not very recent, but a nice blog post that's called, you know, the concept of being a 10X engineer. There's a really 10X engineer, like 10X. There was this notion of being a 10X engineer. The one that knows the code best and uses, I don't know, black background. And you can, it is kind of counted as 10 engineers and it does everything and it's really great blah, blah, blah, blah. And that was really funny back at the time when someone wrote about it. And now there's a blog post that's called, how to be a minus 10X engineer, how to be the worst engineer ever, to become their productive, like interfering with others' work and stuff like that. That's really funny. So I'll leave a link to that below and it's a fun read for the weekend, I guess. Okay, amazing. So that's it for this week. Next week will be episode 31, 31 next week. Yeah, loin. Okay. So next week is the 31st, 31 episode. And that's it for this week on anything else. No, I hope Elvis is fine. I haven't heard him for 30 minutes. No, he's good. He's good. Oh, he's alright. Okay. There he is. Yeah. Good. So see you next week. See you next week. Bye. Bye.