How Cloud-Native Artifact Management Can Facilitate the Move to Platform Engineering

Alison Sickelka: Hello, I'm Alison Sickelka. Welcome to the third and final webinar in Cloudsmith's DevOps Disruptors Summer Webinar Series. In this series, we've been exploring the rise of platform engineering and its impact on DevOps. In today's webinar, we will explore how cloud-native artifact management can facilitate the move into platform engineering and best practices for evaluating and managing change and implementation.

Alison Sickelka: I'm going to be joined by Rob Godfrey of the Financial Times and Antoine Tielbeke from Topicus, who will share their journeys in adopting Cloudsmith. A few housekeeping notes. If you're watching today on a social platform, you can use the QR code to register to receive a copy of the latest report from the analyst firm, Omdia.

Alison Sickelka: Moving to platform engineering does not mean the end of DevOps. Also, Cloudsmith's next webinar is on September 19th. We'll review the EU's Cyber Resilience Act and its potential impact on the open-source software community. Visit cloudsmith. com/webinars to register or use the QR code that's on the screen below. So, I'd like to invite Rob and Antoine on stage to introduce themselves and we'll get started with our webinar.

Alison Sickelka: Hey guys

Rob Godfrey: Hi there. Hello

Alison Sickelka: Rob, you want to introduce yourself to our audience?

Rob Godfrey: Yeah. Hello everyone. Yeah, I'm Rob Godfrey I work at the Financial Times. We're a leading news organisation and I've worked there for over a decade now I look after You Two teams that work within an engineering enablement group at the FT.

Rob Godfrey: A team that manages our sort of cloud platforms and another team that looks after our sort of developer tooling and looks after Cloudsmith. We adopted Cloudsmith about a year ago.

Alison Sickelka: Great. Antoine, do you want to give an introduction to yourself?

Antoine Tielbeke: Yes, I'm Antoine Tielbeke. I'm also a DevOps engineer at Topicus Healthcare.

Antoine Tielbeke: I have a few less years than Rob. I've been here for around four years. I was involved in the implementation of Cloudsmith at our organization with a few of my colleagues. I'm ready to talk about what made us pick the choice for Cloudsmith and why we decided to end up with Cloudsmith.

Alison Sickelka: Okay, great. Well, let's jump in. So, today we're hoping to cover a little bit about platform engineering and engineering enablement and what that means at your organizations, how artifact management fits into that, and then Antoine, as you are detailed, how you go about selecting the right artifact management platform for your organization, what implementation of that looks like and how you manage change within your organizations and then what are the benefits you've seen since you've moved to cloud-native artifact management.

Alison Sickelka: So to kick us off, I'd love to understand a little bit how within your organizations, you think about platform engineering and DevOps you know, Rob, you mentioned engineering enablement. I'd love to just understand a little bit about how you think about those concepts internally and what they mean to your organizations.

Rob Godfrey: Yeah. So I think with engineering enablement, we were kind of, a group of about, I think it's eight teams at the FT. We look after a whole bunch of shared capabilities that we provide to our kind of engineers. So that includes things like, you know, managing cloud services to DNS, TLS certificates, CDNs, observability services, those sorts of things.

Rob Godfrey: and so that this group sort of evolved. From essentially that collection of teams that lived in the organization previously but weren't kind of unified under this sort of enablement banner and so about three to four years ago we came together and kind of started to kind of, on this journey of essentially providing this sort of set of or suite of core engineering capabilities.

Rob Godfrey: The engineers can lean on to hopefully get stuff done more easily, more safely, quicker. You know, those sorts of things.

Alison Sickelka: Yeah, Rob, was there a tipping point? Or what do you think led to the formation of the engineering enablement function within the Financial Times?

Rob Godfrey: What led to it? I think, well, there's always been a need for some of these things.

Rob Godfrey: So some things naturally look like shared services within engineering organizations. You've got whether you explicitly look after, say, I don't know, GitHub on your kind of use of turbo or so a continuous integration platform or whatever, you know, someone in the organization is looking after those things.

Rob Godfrey: I think it's when we got to it, we kind of found that we've gone through this kind of big journey over the last decade, so things like adoption of microservices, moving to the cloud, adoption of DevOps, lots of automation and teams have had a lot of autonomy to do, you know, use the technologies they want to use to get the job done, but that's not come without issues.

Rob Godfrey: and so, you know, we've ended up with, over the years, lots of different technologies you can use across the FT. And things like governance and security get harder. We kind of just heard over time that engineers were kind of frustrated with how many decisions they were having to make, how much stuff they were having to look after.

Rob Godfrey: and they kind of got to the point where they said, we want actually to be a bit more constrained with some of these things that aren't Making a difference to our lives. So that's really where we kind of sort of like, we need to focus on these pain points that exist within that kind of engineering community.

Rob Godfrey: and that's the motivation was you were hearing lots of people. Yeah, we were kind of seeing teams spinning up their kind of almost mini platform teams within their groups to solve some of these problems. So we could see sort of slightly. So, things that were indicating that, yeah we needed to focus much more on this.

Alison Sickelka: Yeah, great and Antoine, what does that look like at Topicus? How did you get to the point of looking at Cloudsmith and evaluating some centralized tooling in Topicus?

Antoine Tielbeke: Yeah, so this kind of became an important decision for us when we were the kind of noticing that we have one of those dreaded shared Nexus instances where everyone is just like a black box.

Antoine Tielbeke: You throw your images, your stuff there, it's our life cycling, and someone is managing multiple hours per week. Increasing like disk and that person would just like, let me do my work. Let me write software. So we kind of realized like, hey, we should focus on our core business, which is writing software that has like impact on people, their lives, and healthcare applications, and it's not increasing the disk for a Nexus instance or a Jenkins instance.

Antoine Tielbeke: So then we kind of realized the way to go is probably to get a hosted solution and software as a service. So we set up an internal group to kind of think like, hey, what are our requirements? Who are the stakeholders? And just some basic competitive analysis, like, what do we want and what fits our needs?

Antoine Tielbeke: And that's how we ended up here.

Alison Sickelka: Yeah, that's great. So, a few good, threads in both those answers. So for topics, you know, really emphasizing getting your developers back to the delivering your businesses software instead of worrying about everything else around that. So fully managed sass was important for you.

Alison Sickelka: And then, Rob, you touched a little bit on, you know, as you give autonomy to those businesses. developer groups, you lose some of the governance and control. So how can you both enable developers, but also make sure that your organization has the security and control that it needs over certain tools and over your software artifacts?

Alison Sickelka: So that's great. I'd love to understand a little bit, Rob, when you brought that team together, how you prioritized and decided what sort of tooling you were going to look at and what the evaluation criteria were when you went into that evaluation.

Rob Godfrey: yeah, we went and interviewed a lot of engineers initially, and we kind of mapped out the tooling that they were kind of using.

Rob Godfrey: and we could see, when you kind of step back, we could see like the, almost the disparity of, you know, there were multiple different you know, CICD kind of technologies in use. There were kind of, you know, we were using Nexus and, you know, some people weren't using Nexus by choice, they were kind of pushing to public registries because they found that just less painful.

Rob Godfrey: But you know, obviously there's trade-offs and consequences to those sorts of things. And so yeah, we basically did this mapping exercise where we kind of interviewed teams and kind of worked through, okay, what to use, what programming languages to use, where are you storing code, where are you storing your packages, images, all this sort of stuff and just had a big conversation and mapped that out.

Rob Godfrey: and then aggregated that up to, we did it for one of our internal technology groups. And that proved quite insightful, and it certainly allowed teams, we kind of got some sentiment about whether teams would like to recommend these tools to other people versus they thought it was a really poor option. And Where their pin points were, what they wanted to try, that sort of thing.

Rob Godfrey: So just kind of getting a feel for what was in use and where people were struggling, really, that was where we started.

Alison Sickelka: Yeah, that's great. So out of that survey and out of those discussions with engineering groups, you identified you wanted to implement a centralized artifact management platform.

Alison Sickelka: What was important to you out of the solution that you would ultimately choose for that?

Rob Godfrey: Yeah, we were running Nexus on a little EC2 instance in the cloud and it was, yeah, we had those issues Antoine mentioned about, you know, having to, you know, increase disk volumes and things like that. Yeah, having to patch it and upgrade it and, you know, secure it, do things like SSO is painful.

Rob Godfrey: You know, there's a bunch of challenges with the existing solution we had. So when we were looking at something new, we already had a pretty good idea of how we ideally, what we look for in a kind of one of these centralized capabilities, we have a bunch of principles that we attach to them and they kind of look for and key to that is really one of them is really like we can adequately own it and support that service internally and provide a good service.

Rob Godfrey: kind of experience for our engineers. And so that was really where we started. So both sorts of developer experience of the tool, can they get started easily? Security is ever present, you know, those, those are the sorts of top, top-of-mind kind of criteria we were looking for.

Alison Sickelka: Yeah. and Antoine, you mentioned going through an evaluation process.

Alison Sickelka: What were the key criteria that you were looking for in an artifact management solution?

Antoine Tielbeke: Yeah, so when we started to look for an artifact management platform or solution, we kind of just grabbed every solution we could find online. So we grabbed, you know, JFrog Artifactory, get the packages, Azure, Nexus, the stuff Amazon has, which they don't really seem to care about.

Antoine Tielbeke: and we just checked like, hey, can you start data in EU? Is the customer support, is it in the same time zone? We had problems with that one before where the support's in a different time zone and you just can't really seem to get in touch with each other quickly, so does it support SAML, infrastructure as code, vulnerability management, and of course, costs? What's the cost of the storage? What's the cost of the bandwidth? And then we kind of ended up narrowing it down to just get the package, Artifactory, and Cloudsmith. So we just started creating a test plan, like these are requirements, so what do we want to test, and GitHub packages kind of fell off immediately.

Antoine Tielbeke: It's practically just a big hard drive where you can store things and that's where it stops. Actually, in the first, initial tests we did, Artifactory managed to beat Cloudsmith by a few points. It was about caching Terraform provider for Cloudsmith being quite new and no image duplication. [ 00:13:32] Antoine Tielbeke: So then we set out to meet with both parties. And in the end, as you can see, we chose Cloudsmith partly because of the cost-effectiveness, but also because they promised the features we were missing, that they were on the roadmap and soon to be added to Cloudsmith. We just felt the Cloudsmith people were more in touch with us.

Antoine Tielbeke: We had a better feeling with them. It felt like we were a partner and not a customer because we, other options, we felt like, hey, you put, you purchase our software and we give something in return. It's like really, but Cloudsmith felt like a real, we're working on something together and starting a partnership, which felt good.

Antoine Tielbeke: So I had to go back and convince my colleagues like, hey, for now, Cloudsmith is scoring lower, but I think in the future it will be better. And you know the famous saying, never buy software based on the promise of future updates. And I did the exact opposite, which is kind of a bad practice, I admit. But one year later Cloudsmith delivered on all of their promises.

Antoine Tielbeke: and they even added more stuff that we had in the test plan, which now puts them actually head and shoulders above the other options in our comparison, so that's how we ended up with Cloudsmith.

Alison Sickelka: Yeah. Thanks for that visual colour there, Antoine. That was great. Go ahead, Rob.

Rob Godfrey: I can concur. I mean, we had a similar experience when we were doing the evaluation.

Rob Godfrey: I think the level of support and engagement we received during the kind of trial was excellent from Cloudsmith. And yeah, we kind of felt that, you know, JFrog and Artifactory and their platform, there's a, you know, it's been around for a long time. It has a huge feature set. We actually felt it was too cumbersome for our needs.

Rob Godfrey: There were too many knobs and dials you could use to configure things. And, so we found that you know, for our needs, you know, the sort of feature set of Cloudsmith, you know, was a good fit and, you know, we're just really impressed with the engagement we had.

Alison Sickelka: Yeah. So there are a few things that each of you mentioned there that I just want to call out.

Alison Sickelka: So making sure that you had a partner in the platform that you were choosing. Antoine, you also mentioned the Terraform provider. So I think we'll get in a little bit around implementation and how you drive adoption, but being able to have that automation around there. You also mentioned SAML. So, so, so user management

Alison Sickelka: and, are they going to make this easy for me? Do they have the integrations I need to be successful? I think that was really important as you guys were evaluating. One thing I didn't hear, but I do think was a consideration for you, Rob, was around governance and control. Things like license evaluation.

Alison Sickelka: How much was that a consideration when you were looking at your artifact management solution, things like open source license, what licenses are in use, vulnerability management, things like that.

Rob Godfrey: Yeah, we, we have a, a kind of, I put together, it's like a secure package management strategy. That we were kind of looking for and kind of having, you know, universal package management as part of that problem, but also things we were concerned about were things like, you know, open source and With the EU Cyber Resilience Act coming down the line, things like S bombs and, and kind of understanding kind of what, what we are using and what's kind of what's deployed out in the wild.

Rob Godfrey: So those sorts of things were kind of it. It's certainly important. I think the maturity is still low in terms of kind of, you know, making sure that we're kind of you know, we know, for example, there are some open source things we would rather not be using because of the kind of terms that they apply and things like that.

Rob Godfrey: So we, and particularly around vulnerabilities it's a, it's a big area. It's a, there's an active kind of big initiative going on in the FT to try and make vulnerability management better because it's just really hard. Yeah, it's just, too much, too many vulnerabilities, too much noise, you know, it's really hard to triage, you know, actually kind of helping engineers solve the real problems.

Rob Godfrey: It's just a massive problem. So, yeah.

Alison Sickelka: Yeah. So evaluating your artifact management needs, but also having an eye towards how is our, organization going to mature and grow in the software supply chain space as well, and making sure you picked a tool that would help in both those areas.

Rob Godfrey: Yeah. I think, yeah, the fact that there's kind of capabilities embedded within Cloudsmith is certainly a plus. And, the fact that that's easy for engineers to kind of go and go and kind of access is also a plus.

Alison Sickelka: Great. So I want to talk a little bit about implementation and rollout. So once you've decided, that cloud native artifact management is an important part of your centralized tool chain now you have to actually get teams to adopt and use that use Cloudsmith and use that new solution. So what did, what did rollout look like within your organizations and how did you help drive adoption within your engineering teams? Antoine, maybe you can take that first.

Antoine Tielbeke: Yeah, sure. We kind of approached the implementation and kind of maybe unique, but also really simple way.

Antoine Tielbeke: And that is just ultimate everything, the whole process, user onboarding, team creation, just write very good documentation and be very transparent in the progress. So we were kind of thinking, how do we communicate this to the teams and we just ended up with just all of the documents we wrote off the meetings we had with the group for doing the competitive analysis and just, you know all of the comparisons and all of the numbers, all of the pricing, we all just made it public in our organization.

Antoine Tielbeke: So developers could just read what we are doing. It was a very transparent progress and I think it's very important to do that, to involve your stakeholders, which are the developers early on in the process. And if you announce the change very early on and they see the progress you can share a timeline with them and they kind of know how to mentally prepare for it and I think the most important part is don't force teams don't be like you have to go here by this date. I think if you make the transition very smooth and natural, you always have to show the other party, what's in it for them to show? Why they have to migrate and I think if you have the good documentation, you have all of the transparency. I think they kind of just start talking to us like, Hey, we're on Cloudsmith, we have these cool new features

Antoine Tielbeke: and then the other team is like, Hey, I also want that and the ease of sharing and all that stuff. So we kind of did the implementation in a very natural way, which ended up working out for us. So that was very nice.

Alison Sickelka: Yeah, Antoine, that's great. So, enabling some, self-serve, for those teams, what did the timeline look like for rollout at Topicus?

Antoine Tielbeke: I think the first team, which is my team, of course, because I'm the rumble out, I go to my PO and be [00:20:00] like, Hey, can you put this on the backlog? So I think within starting to go with Cloudsmith and my team using it and of course, there are some differences between all of our Maven packages there.

Antoine Tielbeke: and then all of our Docker packages there. But I think in just one month, two months, we set up the whole all of the stuff, all of the documentation. And it's very easy because you don't have to write a big blog. We're going to do this because you've been transparent from the beginning. So it's already there and you do it.

Antoine Tielbeke: You don't have the big bang, but the natural flow. So I think around two months the team started flowing in and migrating at their own speed.

Alison Sickelka: Great. Rob, how did Financial Times manage rollout and implementation and encourage change within your organization?

Rob Godfrey: Yes, I think initially the setup of things like, you know, how you're going to do IAM and laying out teams and access and repositories that were, you know, we took a little bit of time similar six to eight weeks, something like that, two months to get the kind of you know, basic Cloudsmith configured the way we wanted to do.

Rob Godfrey: and we worked with colleagues at Cloudsmith to, you know, to help us do that. And then we've basically been going ecosystem by ecosystem. So, you know, we started with Python which was close to home that led us into the data science kind of ecosystem. So we were looking at R and Conda in addition to Python then.

Rob Godfrey: and we had some Ad hoc requests for sort of Terraform and then we've now entered Maven and Node and Docker and those sort of things. So we're still kind of rolling out ecosystem by ecosystem and kind of we've hit all the big ones now. But there are, one of the nice things about Cloudsmith obviously is its, you know, support for lots of different package formats and ecosystems.

Rob Godfrey: So as, as teams see that they can use it and they go, Oh, we can use it with Helm charts. Then, you know, they start to organically use that. We have what's the word, especially kind of paved the road a little bit with so we use CircleCI as our sort of de facto kind of [00:22:00] continuous integration tool.

Rob Godfrey: and so we've implemented some, what are called orbs in CircleCI, some essentially, you know, Bits of code that make, make the kind of integration with CircleCI very, very simple. So we lean on the OpenID Connect support within Cloudsmith so we don't need to store long-lived secrets and keys within pipelines and things like that

Rob Godfrey: so that's really nice. An engineer just adds a couple of lines to their pipeline configuration. They're pretty much configured with NPM or Maven or Python to kind of hook up to Cloudsmith. So try to make it, because we have so many teams and so many pipelines, that's, that's the challenge, you know when you've got a thousand pipelines that potentially need some change, some of them are templated, some of them aren't you know, you kind of, it's quite a bit of effort and then also helping engineers to update their, their laptop configurations

Rob Godfrey: to use Cloudsmith as well as also we've put a bit of effort into the tooling to help them do that as well.

Alison Sickelka: Yeah. So Robin in that migration strategy and rollout plan was most of that self-serve for the developer development teams or did they rely on your team to get set up?

Rob Godfrey: Most of it has been self-service, but the bar, you know, bar kind of initially kind of granting access to people.

Rob Godfrey: The application, which is done for kind of our service desk you know, then it's all kind of seamless SAML integration, that sort of thing, they get set up in the appropriate team and get access to the repositories they need. That's all pretty much self-service we have been doing onboarding sessions with teams just to give them a bit of a demo and basically to be quite clear about what we're expecting of them.

Rob Godfrey: So it's like, you know, you do need to upgrade your pipelines and this is how you do it and you do not need to configure your laptop and this is how you do it. So just kind of walking teams through things and then if needed, we're going out and kind of pairing with engineers to actually do some of those updates.

Rob Godfrey: So they kind of feel confident that they can, use Cloudsmith. One, of the nice things we've done is we've just kind of figured up streams to point at our old legacy kind of package manager. So in theory they can just switch over to using Cloudsmith and there's no package migration per se that's needed.

Rob Godfrey: They just kind of pull a package via Cloudsmith that goes up to, in our case, Nexus and pulls, pulls any packages it needs.

Alison Sickelka: Yeah, that's great. So since you've made the change to a centralized artifact management solution, or Antoine, in your case, to a fully managed SaaS quadnative solution, what are some of the benefits you've seen within your organization?

Alison Sickelka: Antoine, maybe we can start with you.

Antoine Tielbeke: Yeah, definitely, for us, the biggest benefit is the common language, speaking the same language with your colleagues. So we noticed that Transcribing the collaboration and the barrier to entry really lowers if you're all speaking the same language.

Antoine Tielbeke: and what I mean with that is, if someone has trouble, he just stands up, walks to the team next to them, which is also using Cloudsmith, and they can ask, hey, how are you doing this? How are you doing that? Then the other colleague opens their config. You say, can you send that file to me? and you just copy-paste it, edit some parameters and you're off to go.

Antoine Tielbeke: And I think it has a really, really big benefit of that common language that you can just, everyone can help and everyone's on the same level. And I think that's really, really valuable for us in our organization. Automatic onboarding for SEML and Terraform is amazing, since we have set it up, I have almost never had to intervene manually.

Antoine Tielbeke: And it's a really big change because before we had like this big slack channel where people are like, this is my email. I need access to this report's stories. Can someone do this? And now it's just completely set up for IDP and it's just magic how it just works. And one of the really big ones that surprised us is because all of your packages are in one place.

Antoine Tielbeke: Developers just started being like, Hey, you have this package. We have practically the same one, [00:26:00] like a custom one. Can we just make a generic one and share it? And teams started to kind of like, just share more packages and be more collaborative and this was not expected. It was not in our requirements that developers could easily share it, but it kind of just happened automatically because developers want to be smart or lazy, whichever one you want to call it, and they want to share that stuff. So I think that is really, really cool and that was a really, really big benefit for us.

Alison Sickelka: Yeah, that's great. Rob for the Financial Times, have you seen, what are some of the benefits you've seen since you've implemented Cloudsmith and moved to this centralized single source of truth for all your software assets?

Rob Godfrey: Yeah, I mean, so the last point Antoine made about the ability for teams to now easily share kind of code artifacts and also docker images is, yeah, that's a big win. I think I mentioned OIDC. So, with that, it's, you know, we've been hit by, you know, issues with, you know, breaches in SaaS vendor suppliers that, you know, we've had to respond to and that takes a lot of time.

Rob Godfrey: So moving to OIDC for us is a this means we're not storing secrets that can be exposed. So that's in certainly with the number of pipelines, the amount of effort it takes us to kind of reconfigure those in the event of a breach. Fortunately, it's only happened a couple of times, but these things do happen from time to time and they're painful when they do.

Rob Godfrey: So, we're keen on using our IDC anywhere, everywhere we can really. So yeah, that's, that's the kind of big one. I guess the other thing is just visibility. Gedging is a point where you can actually see, what open-source stuff is being consumed within the organization. You've got all the, the kind of the download logs, package logs we, we, kind of shunt those over into Splunk and then produce some nice dashboards off the back of that.

Rob Godfrey: So we're getting some interesting kind of stats on which teams are using Cloudsmith, which users, which packages and that sort of thing. Yeah, so it's it's kind of giving us insight that we didn't have before.

Alison Sickelka: Yeah, that's great. We're reaching the end of our time. Do either of you have any closing thoughts you want to deliver before we wrap up?

Antoine Tielbeke: Well, for me, it's, I'm being a little bit jealous of Rob here because we are looking at implementing OIDC because we want to get rid of most long live credentials and that was also back to the point that Klaus feels like a partnership instead of being a customer. We were like, Hey, we don't really want to enable OIDC on our production environments.

Antoine Tielbeke: can we have a second out and then the kind of an acceptance at fire, we can, we can test it out before we do it to production. And the team was like, yeah, we definitely understand it and here you go. And that's, so for us, the next step is to implement ADC and also get rid of all the long live credentials

Antoine Tielbeke: but that again, proves the point that it's a partnership, not just a customer.

Alison Sickelka: Rob, any closing thoughts on your side?

Rob Godfrey: No, it's been a really kind of pleasant experience so far. You know, it's, it's, you know, I say that that kind of partnership element is, is really key. And, you know, whenever we've had an issue, we just jump on Slack, you know, ask a question and you get used to getting a response, you know, same, same.

Rob Godfrey: You know, same day, same, you know, within an hour. So, so, yeah, it's been really easy from that perspective and it's been a pleasure to work with the people we've dealt with at Cloudsmith so far.

Alison Sickelka: Yeah great. Well, we'll leave it there. Thank you both for joining us today and sharing your experiences on implementing cloud-native artifact management as part of your platform engineering journey.

Alison Sickelka: I really appreciate you taking the time and chatting with us today as a reminder for the audience. If you're watching today on a social platform, you can use the QR code to register to receive a copy of the latest report from the analyst firm. Dia moving to platform engineering does not mean the end of DevOps.

Alison Sickelka: Also Cosmo's next webinar is on September 19th. I think Rob gave a shout-out to the EU Cyber Resilience Act so the webinar on September 19th we'll review that. Cyber Resilience Act and its potential

impact on the open-source software community. You can visit cosmic dot com slash webinars to register or use the QR code on the screen below.

Alison Sickelka: Thank you everyone for joining and thanks again Robin Antoine for taking the time to chat with us today.

Antoine Tielbeke: Thanks for having me. Thank you.