Cloud Native Computing Foundation BackstageCon NA 2022, 26 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Building an Internal Developer Platform with Backstage Plugins - Taras Mankovski

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2023 in Amsterdam, The Netherlands from April 17-21. Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Building an Internal Developer Platform with Backstage Plugins - Taras Mankovski, The Frontside Software, Inc

What does a Heroku-like developer experience look like on an Internal Developer Platform built with cloud-native tools? The answer to this question was elusive for a long time. It's now coming into view as many organizations start thinking about how they can allow developers to deploy to their platforms from Backstage. In this talk, Taras Mankovski will describe the five deployment use cases that an Internal Developer Platform built with Backstage should support to provide a Heroku-like developer experience. We'll cover the following use cases, 1. Creating a service that automatically deploys to the platform 2. Editing secrets and automatically redeploying the service 3. Deploying a branch to a new environment 4. Accessing logs 5. Seeing resources that a service consumes For each use case, Taras will present a solution that a Backstage adopter can implement with existing Backstage plugins.

A

Hi everyone I am so so happy to be here. uh This is really um really amazing like exciting for me, because this is the first backstage con. uh This is for me like the way I see this. This is the beginning of the DX era.

A

From from here, this is the first time probably like even five years ago.

A

We didn't see this kind of enthusiasm for improving developer experience and uh what we're seeing now is and part of the reason why we're all here is because our employers are investing in making developer experience a priority um and- uh and this they're doing this, because they're seeing value um in what developer experience uh the impact the developer experience has on organizations, and it should be of no surprise to anyone that uh Spotify the engineering organization that brought us the squad framework should play such a significant role in this um in this transformation, because.

A

Fundamentally important Technologies they're made by communities and a community has a shared culture. The culture that that Spotify cultivated within the engineering organization is what produced uh backstage and what's really exciting for me, is that now um by open sourcing backstage you've been making a framework available to um to for us to use and, more importantly, creating a community around backstage.

A

What we now get to do is create real magic and uh what I'd like to do is I want to show everyone a demo and for those who are coming in late, are going to miss out on some of the demo. um So, um but so I'll um I will introduce myself. I am awesome, I'm the CEO of runside.

A

um We are a DX consulting company and we were doing DX before uh before. Dx was called DX and um well. Charles was the founder of the company, has a motto that we want to make developers feel like they're flying, and it's always been what we've been trying to do and uh the way we do that with backstage is we offer enterprise support for teams that are adopting backstage um and we're we're honored to be a professional backstage service, a backstage, Professional, Services partner, so demo time all right.

A

So um this demo is something that um that everyone at front side contributed to everyone somehow had a role in putting together this. This present this demo for me to show you so what I'm going to show you today is um is a a new plugin. This is kind of a proof of concept at the moment, but it is a fully functional plugin. We want to validate the architecture. This is this show. This is possible. This is what we call a platform plugin backstage platform plugin.

A

What it is is it's a plug-in that allows a developer at um a developer who's using backstage to download a CLI tool to their computer. That allows them to use a backstage instance. So it's a CLI tool that is created specifically for each backstage instance, so you can install this plugin and then what it will do is once you install the plugin it'll, give you this um it'll give you this command. So you can then take this command into your terminal, and you can drop this in here.

A

What it's going to do is it's going to download the um it will download the binary to your computer and put it into path so now I can do which ATP and then the ADP binary is in my path. So um this binary is generated specifically for for this particular backstage instance, and The Operators, the developers who are building the vaccines and skin control which what what commands it has. So what you see here is the help that is generated from the binary.

A

So if I do IDP help, it will show us the same information, and so what what you'll see here is that this binary, because it is generated from inside of your backstage instance, it has access to the configuration of Backstage instance. So it actually has.

A

It comes pre-compiled with the uh the URL of the backstage API built right into the into the binary, and what it shows you could see is different commands that you can execute so um so, for example, you could do like um ATP info and what I'll do is I'll go and read the catalog and it'll show you the catalog, uh the the current the Cur in the current working Direction. It will figure out which component you are looking at, which component is associated to the current working directory.

A

It will go into the catalog and find out that information and show it to you and give it to you in a console. So that's that's kind of cool, but what's even cooler is that you could do. Let's see if I have it here, you can, you can run the scaffolder. So if, let's say you're you're inside a project, you could say: okay. What we're going to do here right now is we're going to create a new component and it's going to be called the uh backstage con component.

A

The capacity con demo yeah backstage con demo is that better and then we're going to run this.

A

A

Okay, so what it's doing right now is it's actually using the scaffolder API, that's running on your server and it's executing the Scout folder and it's writing the output into your terminal. So um right now it's it is doing the same, exactly the same things that you would do in a browser, but it's doing it in CLI and it's reporting the feedback in the CLI. This is failing, but it's not supposed to be failing anyway, so so all right.

A

um So now that we've cloned this component, what we could do is we can actually uh sorry now that we we've generated this component. We can clone it, and this is one thing: that's really cool is that you can clone it without actually having to leave your terminal to figure out what the URL for this thing is. You could just do IDP clone and it shows you the components in the um in the catalog that have a have a repository annotation attached to it.

A

So if you have, if you have bitbucket or if you have a gitlab, if you have GitHub according to whatever backend you're using, is going to look up those annotations and it's going to report the the things you can clone so here what I'm going to do is I'm going to clone my backstage con demo, and so now, what it's doing is it's it's using the platform API, that's provided by the plugin to figure out what the uh what the URL is where you can clone this and it picks up the URL and it just clones, the Clones, the um clones clones, the project for you, and so now we have in our working directory.

A

Here we have our backstage con demo and we come in here we can go. Okay, let's do um backs the let's do IDP info and so now we're getting the catalog in for for the current working director for the component of the current working directory and here's where I think like this is what we've done here is: we've set up kind of the shell of what we can do, but I think with the real meat of what we want to be doing here.

A

Is we want to be able to go into a component, so a developer working, so a developer? Who is your user? Has this? Has this has this? We can have this binary, this executable on their computer and they can go into any working directory where that is connected to a like a deployed service, and then you can just go IDP logs and what they'll see is logs that are being streamed directly from their service. So this is, these are the logs of the of the service that is currently running um on our platform.

A

This is the this is the workflow that we kind of this is the workflow that we're after uh thoughts who thinks this is cool, because I've been working on this for like three weeks all right: okay, okay, awesome, okay, great! Thank you very much relief, all right, okay! So um all right! So now uh the demo is finished. So, let's talk about, um let's talk about why? Why would you actually want to do this?

A

So um why is it not enough for us just have backstage app, because because the backstage drop is pretty awesome and um and but the reality is that our developers are not developing in backstage. They are not using backstage as a development environment they're using backstage to get information so when they are in their editor, they're doing code when they're in backstage they've context switched into backstage and as amazing and like I.

A

Think backstage catalog is an incredibly important piece of software that it that every organization needs, but the reality is that developers are writing code in their editor, and if we can bring the information that we have from the catalog into their editor, we can Empower them to focus on the work that they're doing without having to switch out into a different system to to get the information they need so um and the other.

A

uh The other challenge with with um with backstage currently, is that it only supports some of the use cases so like one of the use cases of the catalog is that you can go find the components that you want, but that is going to.

A

That is really important and it's a really important piece of part of the work that we have to do.

A

um But that's only one of the things uh you know being able to template is also a really important use case, but it's only one of the things like the kind of things that it doesn't support, for example, is being able to get runtime information. So if you have a service, that's running in the cloud, and you want to get information about that service, what do you do? You have to go figure out? What this thing is is connected to go into that platform.

A

Look at that information and, like you, have to do a lot of jumping around. You can use a kubernetes plugin, which is great, it's very helpful, but there is a lot of other information that goes along to um that. You need to know beyond the kubernetes runtime services that is not available just in kubernetes.

A

um Our backstage app cannot manage secrets. So, if you wanted to, if a developer wants to be able to change secrets for their environments, what are they going to do?

A

They're going to go to AWS, secret manager or they're, going to go to Azure Vault they're, going to go hashicorp Vault, like they have to jump into a different system to to do the work that they need to do if they want to manage releases managing what what they can deploy and what is available for them to deploy is not something you can do in backstage today and- uh and you know, one of the things that is most tedious is having to go into Cabana and like type in just the right query, to be able to get just the right log out.

A

But to actually be able to see you know, did your service start or not, um and that information? um What ideally? What would happen is that we have all this information in our backstage app, um but also it would be available in in our editor.

A

um And what we really are after here is not replace the backstage catalog UI or replace the backstage UI, because both tools play their role in the actual process of making software. But you want to give developers the opportunity to choose and the the option to choose is really important, because what you're doing is- um and this is what backstage catalog has done really well already.

A

Is it's taken the the infinite number of tools that are that make up the internal developer platform and it was able to it, provided us a place where we can condense all that information and stick it into a single page. So you can see so instead of having to look, um you know going to the AWS and look at information specifically to uh or going to like Cube CTL and look for information specific to a service.

A

You can get all that information displayed in one page, so you go into one page and it fans out and shows you information from all external services. That is really really powerful, um but we can do more because or there's an opportunity to introduce a new context, because the editor context has additional benefits that we do not have if we're just using the browser.

A

The editor allows us to say this developer is working on this thing specifically right now they are the code that is open in their editor is the project that is open so, instead of it being like you know, when you go to the to the catalog page, there are multiple different kinds of people interact with that different. You know the sres, you know product managers, different kinds of people, get value from that different from that page, but when a CO when code is open in the editor, you know it is a developer.

A

Looking at that code and their work, there is they're sitting down to do their work, so that added context is actually helpful because we could use it to distill information in such a way that is going to give the developers exactly what they need when they're working in the editor, so that so that they could, they can choose whether they want to go into a backstage app or they want, or they they choose to stay in their in their CLI or if they find that they need to go to the platform and look at the dashboard.

A

That is somewhere outside of Backstage. They can do that, but the ability to choose the size of their context to be able to go from their terminal to Backstage, to to the you know, to the tool outside of Backstage is a way for developers to throttle their um throttle. The cognitive load associated with parsing, all the extraneous information that they have to see when they're, looking at when they're looking at any given system, because it every time you go further away from the editor, there is more information.

A

The developer sees that is unrelated to what they need to do.

A

Sometimes it's sometimes that's very useful because you know, if you don't, if you don't know what you're looking for you got to be looking places where you're going to see information, that is, that is going to help you find something you don't know you need, but when you are looking for something very specific, the best case scenario. Is you just get that thing and you move on and that's what um that's that that's a problem.

A

That's kind of it's a really big problem, specifically on internal developed platforms, because internal developer platforms are, they are a combination of all the tools that developers use to run their software so and there's a lot of tools and in some cases there are multiple tools within a single uh like in a single internal development platform. There might be multiple tools doing the same job so like It's, Not, Unusual to have AWS uh and Azure or um that's usually, the combination.

A

Google Cloud people tend to use Google Cloud, but but for, but you know it's quite common to have, uh or maybe AWS and Google cloud like that's that's something that happens like the same thing happens with um you know like at each each aspect of the of the platform. There is lots, lots of things that developers have to interact with you know in orchestration, there's kubernetes cross, plane, observability, there's all of these different aspects of their developer.

A

Workflow and all of these tools have um all of these tools have a role to play, but it's a lot of information to parse, and so um what backstage allows us to do.

A

An internal developer platform is to is to really focus the what developers sees in Backstage on the things that they need to see to do their work and from all the different things that are available, that you could integrate into backstage the things that are probably like the the thing that we see people asking for and the thing that developers need to know about. Are things like what are our runtime environments? Where is my service running? We see this in every every customer that has backseats deployed they.

A

They want to show that information, because the developers want need to know that information. How do I edit? My secrets- and this is particularly you- know- challenging in environments where you have a internal developer platform, that's in flux or or it's moving, because the um because you might start off with doing a a secret manager today and you might use um hashicorp Vault tomorrow.

A

But now you have developers who have to learn two different tools, just to put their secrets, like most developers, just want to put their secrets and move on with their life, and so, if we can make Secrets available in backstage, we can eliminate the the the need for them to have to learn those tools to do their work, but also, if they want to, they could still have the option to like.

A

We could still link to the original source of data, and if they need to access that information, they can still go there, but they don't have to. um And uh of course there's you know the ability there. There are lots of tools involved in the process of releasing software. So if we, instead of having to jump into um instead of having to jump into something like fluxdb, what they could do is they could see. Okay, here are the three things that are available.

A

Are you having to look into the Container registry like they could just look in there backstage UI and say here are the things that I can release? Okay, can I press a button to release it? That's the kind of workflow the developers are after and of course, the same you know goes for logs, because kibana is fantastic, but what you really most of the time, what you really want is you want to see like can I can I see the thing, that's that I need to to see to understand.

A

If my service is running properly or did it start or did it not start um and being able to see that within within backstage, really focuses developer on seeing the information they need to see within the context of what they're trying to trying to accomplish at the moment, and so this is what um I think this so like what I have here, just kind of Concepts to get folks thinking about like what you know, what would it look like to have the um to have these features integrated into backstage?

A

um So what uh what we're looking at here is the is a essentially a card that shows the different environments that are deployed. There's a couple of interesting features that you might you know your developers have probably want. What are your platform supports it or not? It's a different question, but the kind of things you might want to be able to do is you might want to be able to clone an environment.

A

So if you want to be able to make like an informal environment, so it's nice to be able to say like here's, my development environment, let me just clone this thing and then be able to uh be able to uh you know, associate it with a with a branch and now anything that's pushed into the branch gets deployed automatically to the uh to this environment, uh of course, being able to edit secrets for a specific environment. That's really helpful too, because sometimes you want to be able to experiment and to be able to experiment.

A

You need to be able to configure your system to use a specific token, for example, and um and being able to focus your focus. Your allow developers to edit environment specific Secrets could be really helpful. The same goes for for logs M time check how am I doing for time. Five minutes. Okay, all right! Thank you very much. Okay, we're gonna go through this quicker all right, so all right, um we're gonna, be able.

A

So, of course, the same thing with secrets you know being able to see Secrets uh in backstage and be able to edit them uh what I really want to get to is I want to get to. How do we do this, because this is a lot of things that are that we can kind of iterate on as a community, but um but the really, the really juicy part isn't like you know: how does the? How does the what the demo that I showed actually works?

A

So um so these are some of the uis that I'll share the slide, so folks can check out this, and we can talk about these things in the future as well. It's a really ripe topic for conversation, um so these are. These are what you know logs might look like in backstage as well. So here's what this is. The part I wanted to get to is the the this is what this this is.

A

What cloud native has been after for a long time like hiroku, has been an inspiration for people for for the last 15 years, and part of this is because hiroku provided a lot of functionality. That was really valuable and has essentially become part of every internal developer platform, like every internal developer platform can now um basically allows developers to provision databases when they need them. You can push a repository. You can push a commit that is going to get deployed to a vsci or that's going to get built via CI um you can.

A

You can deploy a container uh using something like fluxdb um you, you have automatic rollback built into kubernetes. You have Auto scaling built into kubernetes the. What we don't have is we don't have clean uis. So this is one of the things that people really loved about. Hiroku is that you have the you have a clean UI that gives you all the things in one screen, but also you could do all the same things from the CLI and that's really what that's really this.

A

This is what we're with what I believe is the missing piece in this, our Cloud native ecosystem, that this community can can really fill in the Gap with in, and so what does it? What does it actually look like at the implementation level? So what we would have is um so we have a. We have front-end components that are consistent, so every regardless of what backing you're using you on the front end, there's a same set of components for for editing, Secrets.

A

um You have a CLI that you can download from your platform and then that that CLI is um yeah. So this is so. These are the components you have. You have a CLI that you can.

A

um You can download, and the CLI runs on every uh and every platform so like with the binary the um what you saw that I downloaded it adjusts the installation, script downloads, appropriate binary for each platform, so we're using genome, which uh which allows you to to write in typescript, but Dino will actually create a binary that it that has no dependencies, that a developer can download directly from platform API um and um and so then what happens is so. These binaries are provided by this platform plugin.

A

That is responsible. That provides a platform API. That gives all the data that the binary needs to run and it Powers the front-end components as well, um and um the binaries I mentioned are written in typescript and um here's. Here's some some of the juicy bits, because each each internal developer platform is different.

A

How you integrate your internal, develop platform into your backstage instance has to be different, so there's going to be resolvers that you can specify which are basically functions that are going to that are going to return data that matches the API that the front end and the CLI expects um and those resolvers are backed by adapters. So you don't have to the idea is that you wouldn't have to uh re-implement everything from scratch, so we can reuse.

A

So if someone implemented uh AWS secret manager API for uh for the for these plugins, you can just install that uh it's install that adapter and it gives it a functionality. We want to be able to as much as possible reuse the work that we've done so the the design of this should allow us to allow for that reuse, um and um that is me, um I hope you, like my presentation and uh thank you. Everyone.

B

Questions thank.

A

B

Taras, maybe.

A

We have a couple of minutes for questions yeah.

B

You can get it tomorrow.

A

But uh sorry, but for everyone else, um so it's so it is software that is like we have it in our like our repo. Our backstage instance is open source. So it's all there, but it's it's I mean it's a good example of how this could work. It is works. I showed you in a demo, but there's still a lot of work to actually make this like robust. As you Damon know, um any other questions.

B

Local workstations uh that sets one side, but what about virtual workstations? Have you considered like a gitpod or code spaces like these types of of developing environments,.

A

um Yeah I mean that's an important piece of the ecosystem, but I think what's I, think in both those systems you can ins, you can run. You would be able to run the binary in those environments because they're, basically Linux environments, so there there are lots of use cases that I can even think. I can even see like this kind of binary being useful for running uh NCI. So, for example, right now we have to to configure Tech docs we have to.

A

uh We have to give Tech docs access to S3 buckets or some kind of storage container, so, instead of using instead of giving it instead of accessing the bit bucket through the storage container, we could you could upload the documentation using the CLI directly through backstage authentication system, so that would that would reduce some of the friction. I think in setting setting up um Tech docs, so there's I could see a whole bunch of the environments that could work any other questions.

A