How Starter Kits and Platforms Accelerate Delivery

Hey, my name is Adriel Perkins. I'm a principal engineer here at Liatrio, and today I'm gonna demo for you what a good platform onboarding experience would look like for building new microservices using a starter slash keep going kit. Now, first of all, I want to talk about excitement. It's really important to capitalize on excitement when new engineers get hired at a company for the very first time. It is also important to capitalize on that excitement when they've been tasked with building a new microservice. Happy engineers build happy products for customers that ultimately are happy because they have a good experience. We feel that the optimization for this time to deliver value is under a week. If you can enable an engineer or a technologist to deliver value within one week of starting to try to accomplish that goal, they're going to be happy. They're going to be able to accelerate that delivery of value to the customers, and they're going to have a joyous time doing so. Now, for this scenario, we're going to specifically talk about what it would be like if an engineer that already exists at the company is focused on breaking apart a monolithic application. Maybe they've decided they found a specific area in the monolith that would really benefit from turning it into multiple microservices. So they need to get started quickly on building those services. They need a paved path to production to accelerate the delivery of value. Well, that's maybe not an easy task. Certainly writing all the code from scratch can take some time. So the paved path to production requires a certain set of things—a set of capabilities that really will make this experience enjoyable. It needs to provide a startup microservice that actually has instrumentation fundamentals available to it in order to operate in production. It needs to have well-known CI components that include things like security scans, linting, and builds that are actually fast and provide feedback quickly to the engineers. You need repositories that are secure and, of course, have configurations and settings that match the team requirements. You need the ability to develop locally. You want to be able to natively support your IDE out of the box and have everything needed to be able to write tests effectively, debug your application locally, and have all of the LSP considerations in place. You also need to version it. It needs to be semantically versioned, and you need to tie those semantic versions to the actual SHA. This is an important aspect for understanding what is actually deployed at any given point in time and whether or not breaking changes are coming into your system. Because of your use of semantic versioning, you should have automated dependency management that includes onboarding your application into the platform. It also includes all of your libraries and pipelines that may be shared across the organization and may change outside of the scope of your repository. Of course, you also need to be able to onboard to the platform, and it needs to be quick. It needs to be a good experience with low overhead so that you can continue to stay in context and innovate. The platform should include things like well-known secret management that is very easy to adopt but also very secure. Authentication patterns should be ensured to be available so that you can check policies against them. You also want to automatically have your DORA metrics for free and any of the capabilities that go along with those. You want to be able to automatically have good observability telemetry into your system so you can analyze and alert based on real-world interactions. Your microservice should be promoted through all environments very quickly, automatically, and with minimal approval. These are core capabilities to having a good paved path to production. What could that look like? This example is a good first iteration, especially for companies that have processes that require change requests and other governance steps. Lots of processes are in place. Consider, for example, the scenario we outlined. The first thing that the developer would want to do is access an IDP—a landing place, an internal developer platform. For the sake of this demo, we're going to talk about your IDP as Backstage. But realistically, an internal developer portal can be anything. It could simply be a wiki page with some automations laid out. Backstage is an open-source option that provides you with a very good framework for building IDPs, and so that's why we'll talk about it here in this demo. So, say your developer goes to the IDP, and they realize they need to build this new microservice already. They can go, hit the template, and trigger the App Starter Kit template. That template is going to automatically create a repository with the new application and source code already out of the box. Then, they can trigger the IDP onboarding template to get that application deployed to dev. An onboarding pull request could be opened, then reviewed and merged, and then it would automatically be deployed to dev. This should be accomplished within the first 30 minutes. You should have all the fundamental puzzle pieces in place to be able to accelerate this. Now, what happens after that? The engineer will then be able to deliver small batch code changes and have them immediately approved by their teammates. When they open a pull request, the CI completes the test run and ensures that everything is in place. Once reviewed, approved, and merged, they should have a very fast release created. All security and automated governance compliance requirements should be automatically vetted against policies, and that change should be automatically deployed to dev. It should be picked up as a dependency and immediately deployed. This should happen in five to ten minutes—it should be very quick. From there, let's say their service is ready to go, and they’re happy with it. Now they’re ready to start deploying changes to production. They can go back to the IDP and trigger the onboarding template again, but this time, select production. During this onboarding process, they may have automation in the backend that says, when a pull request is opened for production, a corresponding change request should be created in the system of record. The approval still happens at the pull request layer. The team approves the pull request, it gets onboarded, and it automatically maps and integrates with the change request to ensure that audit records are maintained. This would be an iterative first step in accelerating value delivery across the board. Now, let’s show an example. Here, we have Backstage as our internal developer portal. If I was a new developer ready to build a new microservice, I would select the GoLang template, fill out the form, and onboard the service to a team. Once the repository is created, it automatically includes CI actions, dependency management, documentation, security settings, and instrumentation for observability—all out of the box. Now, let’s say we want to make a quick change and deploy it to dev. We edit our file, commit the change, and trigger the pipeline. The new version gets published, the dependency manager updates the version, and within minutes, the change is deployed. If we want to deploy to production, we trigger the onboarding template for production. The process is automated, approvals are streamlined, and the change moves through the pipeline efficiently. By the end, we have a fully onboarded microservice with security, governance, and observability baked in. This approach ensures that developers can focus on building features while the platform handles the complexities of compliance, infrastructure, and deployment. This is what a good platform onboarding experience looks like—fast, efficient, and developer-friendly.