Speaker 1:
Welcome to DevEx Unpacked. I'm Alan Carson, co-founder and chief strategy officer at Cloudsmith. We're solving the challenges of artefact management and are on the path to becoming the software supply chain itself. In this weekly podcast, we share knowledge from Cloudsmith employees, customers, and other great guests from the software industry. Along the way, we'll unpack topics like the cloud security supply chains, and of course the developer experience. Welcome to the podcast. Great to have you here. Kira, I've been looking forward to this one. It'd be great if you could just give us a quick introduction to yourself.
Speaker 2:
Yeah, I'm Kira Care. I'm solution Engineering Cloudsmith. So I started in developer relations. Was it three or four years ago?
Speaker 1:
It was nearly four years ago. It was over four years ago I think.
Speaker 2:
No, no, no, not over
Speaker 1:
2021, right. It was like And we're about, let's call it four years ago.
Speaker 2:
Yeah, that seems fair. Yeah, so four years ago I started in developer relations in a much smaller Cloudsmith and developer relations was really hybrid role at the time support. We were doing support sales calls, a bit of developer relations, a bit of documentation, so a real classic hybrid startup role, and I loved, it gave me such a good flavour of what a startup is. I've always worked for those big American companies and it's amazing to work at the near enough to the start of a company. And now I moved into solution engineering about a year ago, and yeah, I'm really enjoying it.
Speaker 1:
Yeah. Good. Well, tell me a little bit about your background before Cloudsmith. So you were a developer at one point?
Speaker 2:
Yeah. Yeah, so I was a developer, started as in vision system engineering. I have a master's in vision systems, so I was a developer and I would own the cameras on the manufacturing line. So the software and the harbo. It was quite a nice role actually. You can, you touch a boat, there's not very many roles where you get to do software and buy a camera and do the whole setup. So it was nice. And then when I was in that company I moved into, it was Hela Packard. I moved into a smaller kind of product role that was just purely software for making it easy to print, which it is so difficult to print
Speaker 1:
From.
Speaker 2:
So we did not solve that problem, but we tried and in a way that was a little startup because they felt like they were doing something new in Hewlett Packard, so they kind of had a little startup feel. And then from there I moved to a software engineering role in FireEye, and I was just working on security products, endpoint security products and all backend stuff. And then I took a year out during C, and when I came back I was thinking about going back into software engineering, but I was talking to a recruiter and I was like, no, I don't really want to be a pure software engineer anymore. I want to expand that role a bit. I had never heard of a developer, a relation role, and he was like, oh, you might like this. And then I was talking to you guys and really the product really connected with me. I had a lot of those problems when I was working as a software engineer working with trying to, it was like, where is this? Why isn't this working? All that kind of thing, and how can take hours out of your day weeks?
So I really connected with that. Also, my last role was the first time I really used open source. So when I was a vision system engineer and even after then mostly we were using proprietary software. It was like you would pay for a library, and I was only really introduced to the open source role when I moved to that security company. So I was there for a few years and then so it was a good time to move into Clyde Smith. I feel like I understood it a little bit more as well.
Speaker 1:
Yeah, no, amazing. I think when you come in, Dan had, obviously we've already had a chat with Dan. Dan had obviously kind of defined that role as a bit of everything, and it was like, here, can we get somebody else to come in and do a bit of everything? So you were great when you came in and just rolled up your sleeves and tried to tackle any of the problems that we had or challenges that we had around supporting customers and getting out there and doing talks and events and all of
Speaker 2:
That stuff. Yeah, I didn't even mention that, but yeah, and Dan has been a great mentor for me as well, and I've followed him into solution engineering as well. Where to next, Don?
Speaker 1:
Yeah. Yeah, really liked the progression of when you came in and the things that you did and then you've ended up, it's always been kind of very customer focused and always sort. Okay, you're now sort of pre-sales engineers, solutions engineer. Yeah,
Speaker 2:
And I think though starting, I did an awful lot of support when I started, and I think that gave me a really great grounding. I think it's like, can we get everybody just working to talk to customers for a few weeks? And I remember I had never really talked to customers before. I was a backend engineer ear and I, I'd be talking to them over our entire chat botter, and it took me ages before I pressed the send button. So to break that, oh, what if it's not perfect? But it was great to break in and then ultimately all I do is talk to customers now and show them the product and show them how it can help them solve their problems.
Speaker 1:
Yeah, no, I remember those challenges around support as well. You would always have one window talking to the customer and then another window talking to Lee or Dan or whoever could possibly help validate the answer.
Speaker 2:
And we still continue that today with all our Slack. I mean, I'm constantly talking to product, to engineering just to make sure that I'm solving it correctly and telling them if there's features people have requested and giving that feedback. So I've continued that on that feverish talk to product.
Speaker 1:
Yeah, I mean, it has become that there's a fire hose of information from customers from internal. It must be hard to pick through to get to the point where you've got the right answer or at least a close approximation.
Speaker 2:
So yes, that would be something we work on. There's some classic answers that we always give that are, and I love it when we get those ones, but often it's those left field answers that are like, does it do this? And this scenario, if I'm wearing a hat and it's a Friday, I'm like, give me a minute and then I'll, but usually if it's anything to do with integrating or anything like that, I kind of feel like we can do that. If it's working with another product, generally, that's fine. APIs, webhooks, CLIs, we can get that to work. It's only a matter of time maybe to put the work in to get a little demo going for that. But there a lot of, there's so many, this feels like an infinite amount of questions that customers can ask. So yeah,
Speaker 1:
No, well, I'm always fascinated because artefact management and software supply chain, it does feel like everybody should be using the same tools and the same systems and the same open source software that's validated and has no CVEs and everything, but that's just not the reality. Everybody has a different stack, everybody's using different tools. It becomes this sort of infinite matrix of things that we need to support and communicate that we can deal with.
Speaker 2:
Yeah, I think a lot of the time when a developer is bringing in an dependency, see really that's not what they're doing. They're not thinking, oh, I'm bringing a new dependency. They're thinking I need to solve this problem that I'm working on. I have two few days to get it going and I want to get it working as fast as possible and then I can move on to the next thing. So I think their motivation is sort of different. It's not like they're concentrating on completing their task as opposed to bringing in the perfect dependency or something like that. And so that's why that tension is there where it's like developers want to just get their job done and then I'm sure that the security professionals and their managers as well want to make sure that they're not bringing in new risks into the supply chain.
Speaker 1:
Yeah, I mean I always think when we started Cloudsmith and we wanted it to be by developers for developers, that what we wanted to do was build guardrails, not gates and not blockers, so that you could make it easy for somebody to bring in that dependency, but at the same time allow the information to flow to the security teams and understand what dependencies are coming in and everything. How have you seen that play out when you're in, because obviously in your solutions engineering role, you would be talking to different profiles and personas when you're going through that kind of buying process.
Speaker 2:
Yeah, I remember one of the classic things I always think of is that whenever I'm do my demo of enterprise policy manager, which would be our way, our guardrails for how you can control and take actions on any dependencies that are coming in or packages. And I always had my demo was like you would have less strict on your developments repositories, so you might allow a lot of maybe packages with certain cvs. You would allow that continue in the development environment and your development repos and then in the production repos that you would be really strict. You wouldn't allow anything to go on anything like that. And then making sure that you don't have any vulnerabilities in your production repositories. But actually after talking to customers, a lot of the time it's nearly like the opposite. Well, not really. Everything is so nuanced, but you never want your production bill to break, so you don't want to quarantine stuff in production in case it breaks something. But of course when it's, it first moves into production, you obviously want to make sure that there's no vulnerabilities in your packages, but after that you don't want to quarantine your production dependencies because I mean, that's your product, that's your business and the show must go on. So that's one of the things that I picked up from talking to customers.
Speaker 1:
Yeah, no, that's really interesting. I mean, that obviously is a very sort of shift left approach, but I have to admit, I think I've also told that story where it's like, oh, let your developers do whatever they want, but tighten it up before it goes to production. But actually it's tightened up at the start and then hope for the best that when you get to production, nothing has crept in. And I guess give warning rather than block the pipeline, you
Speaker 2:
Can say now you could still continue to scan your production repositories and then tag things and then over time fix stuff as opposed to breaking things and fixing it, which seems faster, but maybe not ideal
Speaker 1:
Sort of enterprise policy management. How has that been going in terms of engagement with new customers? Do they like the flexibility?
Speaker 2:
Oh, they love it, especially since we're generally not talking to the dev devs. We're talking to maybe DevOps engineers, platform engineers. So they have a lot of their policy tools might be a lot of click ops, but they love Terraform, they love coding, they love automation. And so when you show them our enterprise policy management, you write your policies as code and Rigo, it's built on open policy agent, and you can define these really nuanced policies that help you control your packages in your organisation. And it can be different for different repositories. You can have exemptions for certain CVEs that aren't affected in your code. You can use not only the CVSS score. So before we have a policy tool for over a year, maybe two years, and it was using the on different things, but one of them was the vulnerability management where you could set the severity level, but now you can set the severity, you can use your policies using the severity level, the CVSS score, the exploitability score, your knowledge of the repositories, the signing information, the tags that are on the packages, and they can create these nuanced policies that make sense for their organisation, the teams they're working with.
So they're eating it up. In fact, it was like the first person that tested it was a prospect and poor product team we're like, no, we want a friendly customer. But once you show EPM to people, they want to use it. So
Speaker 1:
Product. Yeah, no, that's fantastic. It's good to see. And I actually think I'm really proud of the fact that that whole feature kind of came out of the hackathon at the offsite. That was the first time, certainly for me, that was the first time it was kind of introduced and it's been a really nice transition to see that actually go get built and go out to customers and get good feedback on it.
Speaker 2:
Yeah, I think it was like in Patty Carey's our, one of the principal engineers in Clyde Smith, I think it came from his hackathon project with his team, and he's had a big say in its development as well.
Speaker 1:
So that seems really powerful in terms of what it can do. But I think the interesting thing is everything around that feature. So what are typically customers looking for when they implement enterprise policy management?
Speaker 2:
I think they're want to make sure that they can control their open source, that they can block risky packages that they can, and then also have a way for you to monitor maybe packages that you don't want to block but you want to possibly investigate a little further. And so in Cloudsmith's moment for enterprise policy management, there's a number of actions that you can take on policies that are triggered. You can tag a package, so you could say, oh, good to go, or ready for production or something like that. Or you can quarantine a package. And so you can say, oh, if this policy is triggered, we're going to quarantine it. And a quarantining cloud means that you can't download the package, you can't be promoted to another repository, you can't deploy it to infrastructure. So it's blocked. And of course, and also there's plans in the future for you to be able to move a package. So you could use that around package promotion where you can automatically, once it passes your policy, you could promote it to possibly a production repository, something like that.
Speaker 1:
So it feels like there's a lot of power and a lot of things that you can do. Is it easy to set up a policy?
Speaker 2:
So at the start it was all API based, it would be you would have to create your a i create your policies using API and clearly then you would maybe you could simulate the policy. So you have APIs around simulating what would happen if I enables this policy, what would be the result? And so that's great so that you don't turn it on and then block all your packages by mistake. And then we also have another API for decision logs. So you can see it's complete audit trail of why this package was triggered, why this policy was triggered for this particular package, all the data involved, the rego, the data that we use for triggering the policies based on that package and then the results, and then it true to the actions it took as well. So it's complete audit trail. So that's great for if there's some sort of regulation reason that you want to set up a policy, then you're completely covered there.
But recently we have added UI elements to that, and then they're coming on more and more. So you can create your rego in Cloudsmiths in the UI, and then you can attach the actions, all that kind of thing. And you can see what's triggered for that policy. And our lovely UI team for EPM are working on creating a templated way of creating the rego. So you wouldn't, even if you prefer, some people prefer using the building blocks for creating the rego, you might say, oh, I want to put in a threshold score. So if the CVSS score is seven or above, put that into the rego. And then as well as that, I want to use the EXPLOITABILITY score, I want to scope it to a particular repository. Oh, I want an exemption list. And you can use that using the templated way in the UI itself. So there's work going on for that at the moment. And so some people for the UI way, some people for API way, so we cover for both.
Speaker 1:
Yeah, no, amazing. And as you're engaging in customer calls and everything, I suppose you don't get you roll off before you get to see the customer actually implemented.
Speaker 2:
Yeah, I was actually thinking about this at the moment. One year on, we should do a talk about the most popular rego policies that people are using. So the really popular one is using CVS, SCO and EPS sco. That's classic scope in a TUR repository. That's always going to be a good one. Another one is licencing. So if you don't want copy left style licences, we actually have our classic policy that covers this at the moment, so we don't really talk about it much, but you can do this using EPM as well. And then there's other things that you can cover. I'm quite focused on the use case for vulnerability management and headlights, but there are other use cases for EPM could be used for, especially when we get the move action using it for package promotion. Automatic package promotion will be a really powerful way to use it.
I heard Patty Carey talk about EPM as not being, it's not just vulnerability management. It's like Cloud scriptable, Cloudsmith. The power of it is beyond vulnerability management. It's like doing everything you want, doing all your setup using EPM. We're not quite there yet. You can't do all your setup using EPM, but I think that is the focus. The North Star is like this is making everything easier to automate, easier to understand, more, easier to understand why decisions are made using our auditing. So there is an even bigger focus from vulnerability management, but a lot of the use cases currently are around vulnerability management.
Speaker 1:
So EPM is very powerful in terms of developer experience. Who typically uses it within an organisation?
Speaker 2:
So the security team and the infrastructure team would be using it would be setting up the policies. So they will be creating the policies and setting it all up. And then the developers will be probably the other end of it where they'll see if any packages are quarantined, that's where they will come in and see it. So they will either when they're building in their CICD, they'll get a 4 0 3 when they're trying to use a risky package possibly that's been quarantined or if they go into Clay Smith as well, they will see the UI elements, maybe they'll get the dashboard for EPM, they'll get the quarantined flag on the package in the repository. So there's different people using it, the end user, the developers, and then the people setting it up. And also people who are using, if they're tagging things for further investigation, maybe they're tagging something as orange to further investigate, they'll be going into the system and checking that out as well.
Speaker 1:
That's pretty powerful for the security team. And in the past, I think security has kind of come towards the end of the process in terms of development and okay, there's been this sort of shift left movement to try and bring more and more security in, but this feels like it's real control that's kind of co-owned by both the development teams and security teams.
Speaker 2:
Yeah, exactly. SO'S like a tool. It's sort of like a bridge between security and development. First off, before any of this EPM stuff, I think artefact management is that kind of tool. It's a place where, I mean over 90% of packages that are in software are open source and it's very hard to get a handle on what developers, what software is in your product. And before any of this EPMS stuff came about, Cloudsmith has been that using upstreams, bringing in your open source where it's cached and proxied in Cloudsmith, you have one place to see exactly what people are using. And then I think that's the first step of security is visibility. Where am I? What am I using? That is number one step. And I think EPM, none of that makes sense without RA management and being that single source of truth.
And I think that's why it's sort of taken off that EPM thing where people are so they're like, oh yes, it makes sense, it makes sense, but it's because we have that base layer. We already gathered so much information about any packages coming in, scanning from malware for vulnerabilities licences, and that information is perfectly aligned with open policy agent, where great open policy agent, the engine is amazing and the rego is to create policies as code is amazing, but it's the data that make it really something, make it something that people are going to use. So we've already have that visibility and now the controls come along and you don't have to quarantine packages, you can tag packages, you can, and you can do workflows that way. And because enterprise policy management is quite nuanced, you can have an exemption list for CVEs. You can make sure it's targeted only at certain repositories, certain products. So you're not like this big hammer of every CVE higher than seven is blocked. You can build on that.
Speaker 1:
Yeah, no, I suppose it's worth saying because it's sort of in many ways EPM aligns with clouds from original premise, which was build with simplicity but be powerful underneath. And it feels like EPM perfectly encapsulates that too in that you can do really simple things with it, just block everything with a CV of seven and above, or you can get really nuanced and go and dive a lot deeper into the different pieces of information. So yeah, that really resonates with me.
Speaker 2:
So you can say now that was actually the idea. Sure. Potty.
Speaker 1:
Oh yeah. Well I'll take credit for everything.
Speaker 2:
Oh, the seed of that was long, long
Speaker 1:
Before, yeah, no, I hired Patty, so there you go. Patty's great and has brought a lot. I take no credit for anything. So maybe we could talk a little bit more about your pre-sales engineer role now or solutions engineering role. I keep naming it the wrong thing, but it essentially pre-sales in that sort of meaning a prospect and taking them to get to the finish line in terms of becoming a partner with Cloudsmith. So how have you found that? Do you get nervous when you do the first call with a customer before you've met them before?
Speaker 2:
Yeah, for nearly a year now. I used to get really nervous. I'd be worried maybe something would happen with the demo or be asked a question I didn't know the answer to. There's so many questions I dunno the answer to. So I think it's accepting that you can always email them afterwards. It's okay, it's not. That was my only opportunity to, wow. So I do get nervous before a call more than others. So I love showing Cloudsmith and every week I try to add a little bit more to my demo. Maybe lately I've been working on the demo so long and feeling like I know the product really well from four years, but it's actually really hard to demo. Dan made it look so easy, but it took me a long time to be able to go through the product in a way that made sense that would really show the power of Cloudsmith. And so I felt like I have that down and my next stage is maybe to bring more of the customer itself into that demo and to make sure that we're solving the problems that they're looking to solve. And then I think that's when it really speaks to them. When you can combine the two knowledge of the product with understanding of why they're looking at CL Smith and that's the sweet spot.
Speaker 1:
What's the best part of your job?
Speaker 2:
I think meeting people and helping them and working with Dan. So I think it's, and it's so great when someone we're running the POV and they're enjoying using Cloudsmith and then it's a great buzz when they choose Cloudsmith and you've helped them understand its value. I think that's the best bit when they go through a POV. The POV is the best bit. Yeah,
Speaker 1:
Yeah. The
Speaker 2:
Proof of value.
Speaker 1:
Yeah. No, the funny thing is in the early days we didn't do any of that. That's the kind of crazy thing is it started out as being a self-serve platform. You put your credit card in, you get access to private repositories. There was chat, you could talk to us via chat, but I don't think we did a customer call for the first couple of years. We would talk to people if they wanted to, but it was certainly not part of the process. And that has come on leaps and bounds over the last couple of years. How have you found, we've been building that out basically over the last three years I would say. How have you found that kind of transition of, it just feels very different than what we do now to what we did before.
Speaker 2:
We didn't have a customer success team as it was four years ago, but soon after joining, I think that the customer success team has been seeing that being built out. And even within customer success, there's different roles architecture, there's customer engineering where they do more of that integration stuff and the migration tooling and then their customer success managers and how they continue to do, it's actually funny because I think a big part of the last few years has been me and Dan removing ourselves just for me personally, just removing ourselves from the little things we used to do to help people on board. We don't need to do those things anymore. They just sort of work by themselves. They have teams that do all that. Even product. We used to be more involved in product and now obviously the product team is being built out by Allison and yourself and they're just working really well and you don't need to do all that work that we used to do.
I remember it's very hard to dedicate yourself to say you wanted to have more partnerships before having the partnership team. It's so hard to get that going. And now seeing Cloudsmith having all these teams and roles do all that, it just makes everything faster and makes everything just move along faster. And for the sales process, we just hand over to customer success. Obviously we stay involved, make sure that handover is successful and we're talking to the customer success people all the time. And we still join some of those calls as well, especially close to just after they joined Cloudsmith.
Speaker 1:
Yeah, I'm curious, I'm curious on that. Kira, how does, when a customer signs up and you've obviously sort of shepherd them through the process and then now it's coming to the end and you have new prospects to go and talk to and we have to hand over to our customer success team who are also lovely people. We have done a good job of hiring lovely people all the way through the process so that our customers feel supported. But how does that transition look from the customer's point of view?
Speaker 2:
I think we don't want it to look like we're just throwing it over to customer success. That's not what we're doing. We're haunting it over to team that are going to look after them. And so from a customer point of view, we have a few meetings where we're all on the call. We from in the backend, we're creating a document that we share with customer success based on the POV based on information about the company. And then at this start, we're constantly talking and so we have our customer success team. They're not coming at this blind. They're not like you join a meeting. They would never say, oh, what does your company do? Why would you want to use Cloudsmith? There's a continuity there. And part of that is because the customer success team are lovely to work with. Thanks for hiring nice people and I think that makes everything a lot easier. So we just make sure that continuity is kept on.
Speaker 1:
Do you ever miss taking them further into the process?
Speaker 2:
What do I miss do? One thing I miss now, this isn't to do, it's from developer relations, maybe being able to do a lot of research on a topic in supply chain security. So I still do a little bit to do with them. I'm always reading stuff on supply chain security and trying to bring that back. But to be able to go headlong into something like that, that's what I would miss from the developer relations role. But I know I do, it just seems so busy you don't have a chance to be, it's not like, oh, I want to still talk to that customer because you're moving on to the next thing. You're doing new POV, so you're kept busy, so you don't have time to miss it.
Speaker 1:
The other thing I'm really curious about was when you were in the dev rail role and you did events and you did a bunch of different talks, those, how did you enjoy that? Or was that nerve wracking as well?
Speaker 2:
It was quite nerve wracking. I remember one, it was probably one of the bigger talks I did for, what was it, the open source one, and it was on securing your open. It was on how has Europe helping been secure, your open source or something like this. And just before the talk, I had my notes in front of me. I had my presentation and I used heavily used the speaker's notes. And then just before my talk I was like, I can't see my speaker's notes. And she just said, I'm so sorry, and then just backed to away. So I do remember that. So never rely on your speaker's
Speaker 1:
Notes. Notes,
Speaker 2:
Yeah.
Speaker 1:
That's one of those nightmare scenarios where
Speaker 2:
Yeah, I think as well, your topic generally your topic and if you can get to the stage where you just talk about it, that's the place to be. And I think a lot of people as well, they say the same talks over and over, maybe slightly different. So that really helps as well.
Speaker 1:
Yeah, I have to admit, I've never been able to be consistent about just talking about the same thing over and over and
Speaker 2:
Over again. I haven't tell you that was my, I think if you do it though, I think it probably gets better and better. Like a standup comedian on their 10th go, you're finally funny.
Speaker 1:
Yeah, yeah. I'm always hanging back as well. I was on a panel at DevOps live, I think this was last year. It might've been the year before. And they were all, you can go to the back and get micd up and then sort of walk to the stage. So I was kind of hanging back and I was the last person to get micd up. Boy, that was a mistake because everybody else was then in front of me and they just all walked up and started to take the positions away from the speaker course. So I ended up in the speaker right beside the speaker. So all the questions, the first question was to me, and I was like, I had thought I'd been being clever, being at the back and waiting and then I would be last to it was a nightmare.
Speaker 2:
Would you prefer talks or a panel? Panel talks? What would you prefer?
Speaker 1:
I think a talk. You don't really know what they're going to ask you on a panel.
Speaker 2:
They always seem like it's just your opinion on things as opposed to, it seems like you don't have to practise as much, but I'm sure maybe you have to practise more because there's a wider scope.
Speaker 1:
Yeah, I'm always worried I'll get find out that I don't know everything. But yeah, no, well, I mean panels are good from the point of view that if you don't know that the answer, you can kind of handed off to somebody else, but then you're in full control of a talk, so you've only yourself to blame at the end of it. If it hasn't gone well, really. But I used to be petrified about getting on stage. This is maybe six or seven years ago, but I really, really struggled to do it. But it is just one of those things, the more you do it, the easier it gets. Even though I still get nervous, I was nervous before we did this. I was scared that you had asked me a really hard question.
Speaker 2:
It's not how this works. You're the question ask, but
Speaker 1:
This is why I'm host, right? So that I, but like Alison in the first episode, she basically, at the end of it, I was like, is there anything else you want to talk about? And she was like, I'm going to ask you some questions. So that really backfired
Speaker 2:
Actually. Yeah. I can ask you a few questions now that you've mentioned it on enterprise. Okay. So for enterprise policy management, where do you want to see it go? When I talk about that use case of vulnerability management, that seems to be a big focus at the moment. Where do you see it going from there?
Speaker 1:
It's a good question. I mean, I think we really want to lean into the automated workflow side of it. I also think we want to be able to basically present customers with pre-packaged templated things that we have done a good job of. This is what works. We have a customer base, they have used it in all these interesting ways. This is what boilerplate looks like, and if you just turn this on, you're automatically going to be more secure than you were yesterday. And then obviously they can go in and start to pick up on nuance for their business. But I think that's they want observability, they want control, but they also don't want to have to spend a huge amount of time trying to create those things. So it's more like, can we use all the data and all the knowledge that we have to make it as easy as possible for people to be secure?
Speaker 2:
Yeah, that's what I was going to say too.
Speaker 1:
Yeah, glad we're on the same page.
Speaker 2:
Yeah,
Speaker 1:
It's been a bit of a journey over the last couple of years really leaning into API first and building an entirely new EI on top of everything. How has that transition been?
Speaker 2:
I know it was probably harder for Dan than it was for me because I hadn't completely fully felt I really owned that demo because it was like a year ago and I think maybe we launched the UI in October, November, was it something like that. And so it was like, oh, I can start again and have the demo for, because with all these new APIs are, we had a new UI based on it, so it was a UI that was really API first. And so I was happy to jump into the new ui, new demo, new workflows, but it was an awful lot of work for our team, especially Dan had been doing his demo based on the old UI for a long time. And some people like the old ui, which is there is this, we were talking to this young guy last week, he was like early twenties or something like that. He was like, oh, it's real retro, which I thought was really funny.
Speaker 1:
Yeah, I had a lot to do with that EI when it was sort of initially created and it was all my thinking that got poured into it from between 2000 and 2006. So yeah, it is kind of retro.
Speaker 2:
Yeah, it is. But I just thought it was a really funny take on, we should have dark mode and then
Speaker 1:
Yeah, retro mode. Oh, I'm definitely going to open a ticket for that I think.
Speaker 2:
Yeah. But I like the new ui. It's really nice to use. Some of the workflows are much nicer in the new UI, I suppose. Trying to close the gaps so you get as much functionality from the old UI that you do in the ui. That has been a lot of the work the last while. And then trying to convince people that have been using the old UI that like it to change, that's probably going to take a lot of work. You don't want to learn new things if you already have so much to do in work. It's hard to force people to use the ui, and so by making it just a bit delightful to use probably is the best way. So to get them to switch over.
Speaker 1:
Yeah, no, my favourite part of the new UI is the fact that you don't have to hit F five to refresh to find out whether our package has been synced or not.
Speaker 2:
That is a little bit delightful.
Speaker 1:
It's so funny because that was just one of the things we never got to. It was one of those, we definitely fix that. We will pull out all the stops and we'll get it fixed and then it would get bumped for something else that a customer cared about. And that's my favourite thing about the new EI is making sure that we finally have that seamless list update.
Speaker 2:
I like the organisation of some of the admin level settings. I think that it makes more sense. And also adding an upstream is really easy. It's like, and it'll click. So they're probably my two favourite things. And now the dashboards. Do you know what the dashboards are? Good.
Speaker 1:
Well, a lot that has been of evolution and evolved out of the original Cloud. Smith built back in the day didn't have any upstreams, so that was kind of added and bolted on. So it was nice to be able to go back and reintegrate those into the workflow and come up with a new
Speaker 2:
Way of working. Yeah, we think about this was, it's something that made sense at the time, maybe also made sense, plus the limitating factors of the technology stack or whatever. And it's probably was nice to relook at it and kind of turn it on. Its a bit, what else? Oh, I like the usage page. I think that's really good. And the Beamers having it in the app itself, it's like where product, any new features that are released to Cloudsmith, you can just click in and see them. And I think I like this for when we're demonstrating because I feel like it shows how cloud Native Cloudsmith is because it's like, oh yeah, by the way, we have all these new features. And I click in and I go, and of course because we're cloud native, you get them straight away. There's no upgrading, none of that. You get access to those features straight away. And then I say, what version of X and Y you currently on? They're like, oh, it's a really old version. We didn't get time. So did, I'm like, of course he didn't.
Speaker 1:
No, that's a big win for us. Yeah.
Speaker 2:
Yeah. That's a good one.
Speaker 1:
Well, look, Kira, thank you so much for taking the time to be on the podcast today. It's been a lot of fun and I think we've learned a lot about EPM and lots of different things in your world. So thank you very much.
Speaker 2:
It was great to be here. Thanks Alan for having me on.