How to Effectively Manage your Cloud with Ido Neeman, Co-Founder & CEO at Firefly

(Intro Narrator at 00:00:01) Today, we're talking to Ido from Firefly all about his journey into infrastructure as code and the impact it's having in running in the cloud. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:16) We're here, man.

(Ido at 00:00:17) Hello.

(Joel Beasley at 00:00:18) Hey, how are you? Fantastic. Cool. So can you tell me a little bit about your background and how Firefly came to be?

(Ido at 00:00:27) Yeah, so I started my, let's call it career in the Israeli army. I served for the Intelligence Corps in the IDF, did lots of cybersecurity work. So in total, I spent just under twelve years there. When I finished, I went to lead technology for a prominent Israeli hedge fund, but I was always keeping a very, very close look at what's going on in the cloud. I was always fascinated with the cloud. So at some point, I left the hedge fund.

(Joel Beasley at 00:01:01) What were you doing there at the hedge fund? Were you evaluating other companies? Is that how you got the idea for Firefly?

(Ido at 00:01:08) We invested in publicly traded companies with high emphasis on fast growing technology companies, and sometimes not fast growing, but somewhere where we have a lever or an edge over other money managers. And we believe it's our ability to analyze technology stacks and technology companies. So, yeah, I was meeting CEOs, CTOs, CFOs of publicly trading tech companies all day long. Learned a lot from it, even specifically in this macro trend where path to profitability becomes very, very much important once again. So I think I've learned a few lessons on how to turn tech into cash flow, and I hope we can employ that here at Firefly.

(Joel Beasley at 00:01:59) When you were doing this investment research and talking with them and evaluating tech stacks, did they all have this common problem that you still thought, like, okay, I'm gonna leave the hedge fund and I'm gonna go solve this common problem? Or did the idea come from something completely different?

(Ido at 00:02:13) It came from something completely different. So what happened when I was working in the hedge fund, I saw the rise of Kubernetes, and I saw how it impacts. Back then, it was even, you know, it was containers, and Kubernetes was just starting. It was the rise of the containers, services, and applications. And then we saw the emergence of serverless. So I thought this can be a really good opportunity to start something big. So this is what really got me to start leaving the hedge fund and started my previous company, Nuweba. So problem is with serverless, you know, when we started in early 2018, serverless was the future of cloud. But now we are very close to the beginning of 2023, and serverless is still the future of cloud. So in technology, five years' time span is a very long time. So, unfortunately, let's call it, it's still an incubation project, the serverless function domain. But when we started Firefly, we thought about problems that almost everyone we talked to and everyone we saw, my partners and myself in our previous positions, experienced. And one of the core problems that we saw across, you know, startups to Fortune 500s, is the fear of cloud. So maybe I'll take a quick step back and tell you about some of my experience in my previous company. So we developed a solution to rearchitect serverless from the kernel up. So our developers did a lot of heavy lifting around low level software development, and they had no problem with it. Kernel copy and write, checkpoint, install in user mode, lots of very hardcore R&D. But then when they had to ship it to the cloud, they were afraid. They told, no, I won't do it. Let's get only the DevOps people to do it for us because every mistake when you deploy to the cloud can have severe consequences. So this was the first time when I understood that taking your code, deploying it to the cloud, and controlling it in the cloud can be complex, even to the best of the best engineering teams out there. So when I got together with my partners, we all felt this pain together. We all saw it in different stages of our companies, of the market, of the personas we worked with, and this is how we decided to start Firefly. We just found the three of us are very much intrigued by the lack of control over cloud platforms. So this was the initial spark that got us started working on Firefly.

(Joel Beasley at 00:05:02) And so what does Firefly do exactly? Because I'm, so my background, software engineering, but I haven't been doing that for the past three or four years because of the podcast, and that sort of became my full time gig. But, you know, part of me thinks when I was reading the description and hearing you talk, it's like to understand the footprint of your cloud environments. And then there's a couple, and then the past couple statements you said started making me think it was like kind of a Terraform type deal. Can you help me understand exactly what it is?

(Ido at 00:05:31) So I think you got the parts correctly. I would say it's the line that connects between understanding your cloud footprint and the Terraform and other infrastructure.

(Joel Beasley at 00:05:41) Oh, okay, cool.

(Ido at 00:05:42) Parts out there. So, basically, what Firefly does, it's a cloud asset management solution. Okay? We help DevOps, SRE, and platform engineering teams understand everything that they have in their entire cloud footprint, and then we map unmanaged, misconfigured, or inefficient resources out there on your cloud. But when we find them, we're not just leaving you with those alerts because, you know, no one has sufficient staffing in their cloud ops teams. And even if you have the budget, good luck finding the right person to do it and having them onboarded. And even if you manage to find those, you know, in SRE, there's always a fire to put out. So once we find those problems or those challenges, the unmanaged, misconfigured, or inefficient resources out there, we give you automatic fixes or remediations for them. So you can really increase the business velocity or the efficiency of your cloud operations while minimizing the risk for service failure. And I would say, you know, to your point in how it connects between footprint visibility or understanding into infrastructure as code in Terraform is that, you know, if we think about the more common IT asset management or how we manage on-prem data centers or legacy IT. In this domain, asset management and configuration management database, CMDB, is a huge, huge section. I mean, this is a section that sells a few billion a year. Probably the largest player there is ServiceNow, which sells a lot of CMDB. Because when you manage your own data center, everyone understands you need the source of truth about your infrastructure. Right? Where do you have those Juniper routers? How do they connect to the Cisco routers? How do they connect to the secure web gateway? And what are the definitions of them? But now when we took the infrastructure to the cloud, the cloud became even more complex than the on-prem IT because we have more services that are changing much more quickly by more teams, and the adoption of new technologies is at a much faster pace. So how come we took this very established, highly adopted concept for managing on-prem data centers, but we went to the cloud, which is more complex, more fragmented? We left it behind where we should have someone, something that is next gen, much more improved CMDB or asset management solution. And this is how we go about it. We believe that the cloud asset management for the cloud should be empowered by infrastructure as code because infrastructure as code and Terraform as a prominent example is the language of the cloud. So when we manage those, I give the example about routers on-prem. So when you talk to the Juniper and Cisco and Fortinet and so on and so forth and Huawei, you had to understand those APIs of each and every one of them. When you move to the cloud, you can speak in one language. It's the language of infrastructure as code. Let's say, for example, it's Terraform, or is it Pulumi? Or it can be CloudFormation or Aurora or Helm for Kubernetes environments. Right? And some would say even Ansible. So it's the same language with different dialects, but essentially, it's the same language. And our cloud asset management solution is very much proficient and like the Harvard professor for this infrastructure as code level.

(Joel Beasley at 00:09:31) I've got a bunch of questions for you, but I wanna give you a compliment first because people that listen to the show are always trying to become better, grow in their career, in their presentation, and professionally. And you did something that I really enjoyed in your last statement. Before you said the acronym, you said what the acronym was, and I can't tell you how many interviews I do where people just start shouting out letters as if I'm in their vertical twenty-four seven, and then I have to go back and ask them to explain. And I know it's pretty common people learn when you're writing a paper, you're supposed to say it before you use the acronym, but in speech, they don't do that. So you did this really good habit I enjoy, so I wanted to point it out. Now to the questions. Okay. So the first one is, does your solution work across multiple providers like AWS and Microsoft and Google, or is it just one?

(Ido at 00:10:21) So we currently support AWS and Google Cloud, which was formerly known as GCP. And Azure is coming very soon. But currently, it's AWS and GCP and Kubernetes everywhere, but also OpenShift. But Azure will be supported soon. So we, as we see it, will support the majority of the multi-cloud plus Kubernetes ecosystem.

(Joel Beasley at 00:10:44) For these misconfigured, unmanaged, I guess, automatic suggestions that you mentioned, are these just suggestions, or can I click a button and have it take action on that suggestion?

(Ido at 00:10:56) So it depends, but it's most of the time, it's an action. Sometimes it's just a suggestion. So let me give you some concrete examples. So when we say unmanaged, we basically mean that something is running in the cloud without you really controlling it via infrastructure as code. So we distinguish between codified assets and unmanaged assets. Because when you run large scale, fast changing environments, if the infrastructure isn't codified, it's de facto unmanaged. It's not versioned. It's not controlled. It's not immutable, and it's not reliable, and you can't support high scale operations without it. So we scan your cloud, and we tell you this part of your cloud is properly codified using Terraform, CloudFormation, and Helm charts. But this other part are unmanaged. So now a small startup can have like 500 assets that are unmanaged. Some of our enterprise customers have 15 million unmanaged assets, but those are some of the world's largest cloud deployments. So let's say you're somewhere in the middle and you have now 2,400 unmanaged resources. Just imagine how much time, effort, and investment would it take to a person, to an engineering team, to codify each and every one of those 2,400. It's just an immense amount of engineering hours that you don't have. And then when you start doing it, you do the first one. You're fresh. It's all good. You go in between the AWS documentation, the Terraform documentation, and your internal documentation on how you do stuff and how you run your modules, and it's fine. But this is just the first one. When you get to the twentieth, you're already burned out. So this is how errors start to sprawl in. Okay? So what we do, we take all of this, for this example, 2,400 unmanaged resources, and we allow you to codify them automatically with a single stroke of a key or an API call. And you can take all of them. You can take a bunch of them. You can break it down into environments. And we understand how this environment lives in the cloud, and we break it down into infrastructure as code. Now you can decide if you want to codify it into Terraform, codify it into Pulumi, CloudFormation, ARM, Helm, Ansible, any way you'd like to take it, Firefly supports it. So this is how we save errors and significant amount of engineering hours and allow you to really control your entire cloud and have it all codified. So this is just one example. Another one that's probably worth mentioning is drift or misconfiguration. So let's say you wanted to deploy to your cloud an IAM role. Right? So you gave it a bunch of permissions. And now someone super quickly wanted to make a change to the cloud, so they just use the AWS CLI and change stuff without going through the infrastructure as code pipeline. So this is what we call drift, and this drift can have severe implications. It can have security hazard implications. It can have performance issues. It can be just cost issues if we're talking about instance size. And all in all, it's very bad, and most of them end up in errors or service disruptions. So the minute you create a drift, Firefly detects it and sends you a notification. Let's say to your Slack or PagerDuty, if we're talking about some of our customers leveraging PagerDuty alerts for production environments. So you're getting this notification with all the drift details, what happened, how it happened, who created this drift. But also, again, instead of just leaving you with the alert, you know, now it's 2 a.m. PagerDuty woke you up at 2 a.m. on a weekend, and you need to understand what do I do with this IAM role or this VPC definition. And you're really hungover because it's a weekend. So what do you do? What do you do? You can struggle. You can waste some very precious uptime, or you can leverage Firefly's automatic fix for the drift. So we understand where this piece of code and this state for the infrastructure as code lives, and we understand how to make right or how to fix or remediate this problem. So, again, it's an automatic process that takes a few seconds, and you're back to safety. So these are just two examples on how we give automatic remediations for problems in your cloud.

(Joel Beasley at 00:15:49) That's pretty cool. I love what you guys are doing. I also heard that you're doing a survey on the state of infrastructure as code. So what is this survey? Tell me about it.

(Ido at 00:15:59) All right. So Firefly is on the one hand a cloud asset management solution, but we are very much built on top and just great believers in infrastructure as code. And we see ourselves as part of the infrastructure as code community or trying to be ambassadors of infrastructure as code inside DevOps and platform engineering. So we just released a survey about the state of the IaC, state of infrastructure as code, where we share knowledge within the community. We're gonna close this survey really soon, and we're going to release a very good report and a very thorough report with lots of insights and data that we collected about how different teams and different companies employ and utilize infrastructure as code across their stacks.

(Joel Beasley at 00:16:49) Okay. Do you have a newsletter on your site that people can subscribe to where they would end up getting that notification when it's done?

(Ido at 00:16:56) Yeah. In our website, gofirefly.io, there's a contact us page. You can sign up to our newsletter and you get notifications when this report is going to be released. Also, it will be very much publicized on our website and across some other media outlets and community websites. So just, you know, I think when you search for State of the IaC, you'll get this report. And I can tell you even with a sneak peek that some great findings there that can help any platform team out there understand how other teams are leveraging infrastructure as code.

(Joel Beasley at 00:17:33) Amazing. Okay. I got a kind of nerdy lower level question here because I'm just curious. Okay. So it was really clear to me on the example of the 2,400. You find these unmanaged resources. Right? And then I can see 100% how you could look at the current configuration, detect that it's not driven by infrastructure as code, and then essentially generate infrastructure as code based off of the current environment. Right? I can understand how you can generate it. But like, how do you get that into the deployment pipeline of the application that didn't previously have infrastructure as code?

(Ido at 00:18:10) Fantastic question, and I didn't mention it before. So how we go about it is we don't want Firefly to introduce more risk to your cloud. So every change that we suggest for you to the cloud, can be codifying a cloud environment or fixing drift, is via a pull request. Okay? So it's a Git pull request.

(Ido at 00:18:32) We connect to any Git that you have or the most common Git that you like — GitHub, GitLab, Bitbucket, Azure DevOps, to name a few. And then it's inside your CI/CD pipeline. So some just take it as a general pull request created by a developer in the organization. For others, we are already a step in their Jenkins processes. So they know when Firefly's step, the drift step, is automatically approved. So for them, it's completely automatic.

(Joel Beasley at 00:19:05) That is pretty cool. And so it just comes from your application? Like, the pull request will show as, like, your application as the developer?

(Ido at 00:19:14) If we really want to take it low level, it's our API, but yeah.

(Joel Beasley at 00:19:18) Yeah. Oh, that's pretty cool. Is it like a little graphic of a firefly?

(Ido at 00:19:22) Yeah. We have a very cute animation of a firefly humming its wings across. So yeah, it does it when it thinks it doesn't.

(Joel Beasley at 00:19:32) I like that, actually. When I saw it the other day, I was looking at — what's your website again?

(Ido at 00:19:37) It's gofirefly.io.

(Joel Beasley at 00:19:41) Yes. So one of the things I really liked about it, I just pulled it up, is that you had some button where I could see basically, it was one click to a fully populated dashboard where you could see exactly what it would look like if it were filled with information. That was pretty cool.

(Ido at 00:19:58) Yeah. We invested a lot of time and effort in building an experience, what we like to think is very nice. Okay. It takes minutes to onboard. So just a few clicks and you see your entire cloud in one place. And then, yeah, fantastic. So if you can go to — this is the main dashboard, but if you go to the inventory, it's just a full inventory of your entire cloud. So let's see how big is your cloud deployment. Alright. So not too shabby. Three AWS accounts, one Kubernetes cluster. You didn't add any SaaS application, but essentially, what we're saying is that if you are the VP of platform for a large organization, yes, you have your AWS, you have your GCP, your Azure, your Kubernetes stuff. But for you, Okta and Cloudflare and maybe, you know, GitLab are an integral part of your infrastructure. So we also integrate with those tools and allow you to see them as part of your cloud inventory.

(Ido at 00:20:59) So now you want to see how they were deployed using, in this case, I see you use Argo CD, which is fantastic. Again, we also use it internally, so you can see how it was deployed. You want to filter by a tag across all of those, you just go ahead and do it. You want to filter to see if you still have some assets that were deployed in 2019 and still, for some reason, running, you can do it.

(Joel Beasley at 00:21:19) That's pretty cool. This is actually really interesting. And I think we almost reached the limit of my knowledge here with some of this stuff, but I can definitely see the value from a business standpoint of having these unmanaged assets. I think the most interesting one to me is the drift because that happens a lot. People will go in and, like, tinker with something, you know, with the live version of it, and then it can get off. Is that what drift is?

(Ido at 00:21:45) Yeah. So drift is, you know, if we're talking at a bit higher level, drift is a gap between the desired state of the cloud and its actual state. Today, the standard is to codify the desired state of the cloud in infrastructure as code. So the architect or the developer creates the desired state, let's say, for, in this case, an auto scaling group. Right? So you do this configuration of the auto scaling group, and it goes live on production or staging or anything that you'd like. And then someone logs in manually to the AWS console and changes some definitions of it. So when it's done, now it's not meeting the desired state that my architect wanted for it. So in this case, for the auto scaling group, it can be just something that impacts performance or impacts cost. But I can tell you that every week, we get lots and lots of feedback from our existing customer base telling us how drift detection helped them prevent a downtime or service disruption, which is amazing. So when I log into the AWS console and change something manually, I'm creating this drift and I want to stop it before it happens because it's just a bad practice. The other side of drift is drift is not just created manually, but created by a third party vendor. So let me tell you some examples that we saw recently. So, for example, you have this cloud cost optimization tool that goes onto your AWS root account and searches for larger instances. And then it automatically moves you between different instances.

(Ido at 00:23:36) So it can go — let's say you are deployed on some T2 extra large instance. Now I moved you to an M4. So it's a drift, right? Because now if you want to redeploy this environment, it's going to be deployed using that T2 extra large because this is what my Terraform sees. My infrastructure is code and not what my current environment has. But if I'm in at one of the, let's call it, one of the teams that maintain the cloud, I'm doing all the changes on this medium sized server. So all the changes that I made in the past few days are going to be gone. And this is how drifts affect uptime and drifts affect service quality. So we see this one good example of non-human intervention created drift. The other way for it to happen is with security tools.

(Ido at 00:24:34) So another example just from last week. So this DevOps team is working with a new vendor. They need a relay. So they have a VPC, which is close to the internet, and now they need to ingress from the internet inside. So they open this VPC to outside traffic and it's all working and it's fine. After three days, a security tool scans this VPC and sees that it allows ingress. But the security tool's policy says, no, you can't allow it. So now it's going in and changing the configuration because this is what the security tool should do and make the security more tight. So now security is tighter again, but the DevOps team can't have connection to the relay that they wanted. So they don't understand what the problem is. They spend a few hours understanding why they don't have connection. You know, obviously, you start with blaming the DNS, then they see it's someone changing the ingress rule, so reopen it. Another week passes. Again, the security tool comes in and does it again. So what's the source of truth? Where is the place where you define that this specific VPC should allow ingress from the internet into the organization private network? Where does it live? Where is what we call in legacy IT? Where is the CMDB, configuration management database?

(Ido at 00:25:57) Where do you have it? And the answer is, unless you have Firefly, you don't have where to state it. And for sure, you don't have how to detect those drifts and stop them from hurting your production environments.

(Joel Beasley at 00:26:09) When you're out there selling this because you're the CEO, so you're on sales calls and things like that, what's the one or two reasons why people are making the decision to put out the money for this product?

(Ido at 00:26:23) Alright. So I can segment it into two basic stories. One is, let's call it, the more cloud forward, the best of the best teams. They just see it. Joel, you pulled up a quick environment of Firefly. We have this metric that shows you your IaC coverage status, which part of your cloud are codified, unmanaged, drifted, or ghost. Ghost meaning that you think something is running on your cloud because we see it on the state files of the infrastructure's code, but it's actually missing. Those top professionals, the teams that lead the pack in cloud engineering and platform engineering, they sometimes see this and they adopt it because they understand the pain of constantly maintaining a fully IaC covered cloud, and they know they have to be as close as possible to 100% codified. So this is one aspect. These are the most easiest sells for us. The other side, when we're talking to the more established enterprises, there we sell a peace of mind. We sell a cloud safety net. We sell them the ability to know that they control the entire cloud. And if something is not properly controlled, they don't need to invest too many engineering resources because automation will do it for them. And if something changes, let's call it a drift, for example, or a new unmanaged resource was deployed, Firefly will give them the peace of mind to know that we have their back. We'll let them know about that. We give them the fix automatically. So they're always in control, and they're always keeping their teams efficient.

(Joel Beasley at 00:28:03) I like that. Yeah. Because that's what I was going to think a huge driver would be. The expense of downtime is easily calculated, right? You go to an e-commerce company or a SaaS company and you ask them how much downtime costs, they know it. They know this number. And so to help prevent that would be worth spending money on.

(Ido at 00:28:26) Yeah. And I can also tell you, one of our first customers, it was one of the reasons that got us really started with Firefly. As a company, I can't use the name, but let's say they used — they were one of the larger IT consulting companies when they came in, and they decided to do what they call an IaC migration, infrastructure as code migration, adopt infrastructure as code, and start covering their infrastructure with Terraform. So they paid this consultancy 250K for the project. It took four months, a lot of ongoing work from both sides. So it cost a lot of upfront cash, but also a lot of time and effort from this team. And it was successful. But three months in after they paid it, everything was already drifted. A lot of new stuff was deployed to the cloud, which is now unmanaged. Some ghost appeared because of the CI/CD leakage and some Terraform errors. So now they're saying, okay, we paid this consultant 250K plus all of our time, and now we need to call them back after one quarter. So do we need to invest, like, every quarter 250K plus a lot of time? It just doesn't make sense. So with us, they're doing it, A, at high scale and much improved speed, and B, it's continuous. And it's not like every once a quarter, a lot of work because we just help you take it in bite size. Every change is monitored. Every drift is fixed. Every unmanaged resource can be codified in seconds.

(Joel Beasley at 00:30:12) Can you help me understand? Like, can you just educate me for a second? I don't know how useful it will be to the audience, but people who aren't experts at infrastructure as code might be interested. When you have, let's use Terraform, what are the policies called in Terraform? Are they called policies, recipes? What are they called?

(Ido at 00:30:29) So sometimes manifests are probably the most commonly used.

(Joel Beasley at 00:30:34) We can talk about this. I don't know if it'll make it into the interview, but I just really want to know. I'm really kind of curious. Are people storing these Terraform manifests in their Git repositories, or are they storing them in some sort of hosted Terraform environment? How are you looking at, like, which ones have — like, when you look at the server, where are you looking to see if it's been codified? What are you peeking into? Their GitHub repositories, some other system?

(Ido at 00:30:59) The best practice, obviously, is to store infrastructure as code and namely Terraform in your Git repositories and save state files in a dedicated solution for state files. Most commonly, it's your own do-it-yourself storage buckets on your cloud, for example, S3 on AWS. But there are a lot of other solutions. Very, very popular ones can be IaC pipelines by GitLab and GitHub, which gives you out of the box integration to manage it, but also some other solutions. Like, Terraform has Terraform Cloud to do it. But what we see currently in the market is that do-it-yourself or the current CI/CD pipelines are the strongest ones. So our ability to know which parts of your cloud are properly codified versus unmanaged is by comparing two different scans. One is the scan for your cloud. We just scan — we build a complete picture of how your cloud footprint looks like. The other is where we scan your state files, and then we're able to understand how your cloud should look like from the infrastructure as code perspective. When we compare them both, we understand which resources are codified and which aren't. So which resources we see in the cloud and don't see in the infrastructure as code files, these are unmanaged resources. If there are some resources that we see in the state files but are missing from the cloud, those are what we call ghost resources.

(Joel Beasley at 00:32:37) So if I plug this into my environment and I've got 2,000 servers and maybe there's 100 that are unmanaged, is it possible that the reason why it's coming up as unmanaged is because I haven't hooked up a secondary Git account that actually is containing those configurations? Does that ever happen?

(Ido at 00:32:55) Essentially, if you didn't — so the state files are not saved in the actual Git. It's a different storage. But if you don't constantly use this state file management process, it's essentially like you don't manage the state. So the next time you want to change those servers and it could be your RDS databases or anything that you'd like, your Lambda functions, it's essentially very bad practice. So if you don't manage the state, and it's something that we do see and we do help solve, understanding which state files are properly managed, which are not, which are empty, which are out of sync, and so on and so forth, it's essentially not really leveraging infrastructure as code to its fullest. So you got to manage your cloud through those state files because what it tells — let's say you have those 2,000 servers, and now you want to deploy the 2,001. So you make an infrastructure as code plan, let's say, a Terraform plan for 2,001 servers. Or let's do it with the containers. It's even easier.

(Ido at 00:34:06) Right, because they are ephemeral. So if I want to deploy the — let's go back to server. Sorry. I don't really need to deploy 2,001. I can just deploy the extra one. How would Terraform and any other infrastructure as code tool know that I need to deploy only one is by reading this state file that tells me you already have 2,000 servers up and running in the cloud. So we, as Firefly, we have the ability to actually question and scan the cloud in real time. So we know it, but the basic technology beneath the infrastructure as code is by not scanning the cloud, just remembering or managing the state of your cloud using those state files.

(Joel Beasley at 00:34:53) And do the state files live on, like, the server, or do they live in some other locate — where do they live?

(Ido at 00:34:59) They live in a different location. So let's say you have your server deployed in the cloud. You have the code for this server in your Git repo, and you have your state file kept in GitLab infrastructure's code pipeline or in your own storage bucket on AWS. So it's — if you're talking about Terraform, it's a .tfstate file. Now, there's a storage bucket where you have all those files, and when you run the Terraform plan, Terraform apply commands, they are executed against this storage bucket that holds this state file.

(Joel Beasley at 00:35:37) Okay. Cool. I'm getting an education here today.

(Ido at 00:35:40) Yeah. You know, we have some open positions for platform engineers. I'm counting on you.

(Joel Beasley at 00:35:47) There we go. Well, hey. If you have open positions for everyone who's listening, who's interested in this stuff, and who is possibly just bored by the basic explanation of me learning something that everyone should know in infrastructure, yeah, where would they go to apply to look for a job?

(Ito at 00:36:01) So I don't think—my HR manager will kill me—but I don't think we have a career page on our website. But just leave us a note on our contact us page on our website. We do have many open positions across engineering, sales, marketing, anything that you can think of. So not a barista, not yet, but many of the more common departments in startups are recruiting at high speed.

(Joel Beasley at 00:36:30) When that barista position opens up, let me know.

(Ito at 00:36:33) I will get you here for coffee.

(Joel Beasley at 00:36:35) Thank you. Quick question about the Firefly animation. When I saw it, I was blown away. Is that CSS animation?

(Ito at 00:36:44) Yes. Yes. We have some of the best front-end developers who do really great stuff with code. So, you know, they are creating in code instead of in Figma.

(Joel Beasley at 00:36:55) Yes. It's demo.gofirefly.io if you want to just see the animation. Right? Oh, it gets a little faster too. I didn't notice that.

(Joel Beasley at 00:37:05) It's slow at first, and then when it loads, it's faster. I love design. I'm a huge fan of design. So whenever I see really beautiful stuff, I'm always intrigued. And when I saw that, I was like, oh, I hope that's CSS because that is brilliant.

(Ito at 00:37:19) Yeah. And it allows us just to do better work without overly relying on CDNs.

(Intro Narrator at 00:37:26) Yeah. That's awesome.

(Joel Beasley at 00:37:27) We made a podcast. How do you feel?

(Ito at 00:37:29) I feel good.

(Joel Beasley at 00:37:30) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.