Unifying Inner & Outer Loops To Bridge the Gaps Between Devs... Laurent Broudoux & Mathieu Benoit

This talk explores strategies to streamline the transition from local development environments to production, focusing on reducing cognitive load and resource consumption for developers and platform engineers. The speaker discusses the Trader Hicks application as a case study, illustrating microservices architecture and the challenges associated with dependencies and configurations. They introduce Score, a workload specification tool, which helps standardize deployments across different environments by abstracting technical details. Additionally, they present Micro, a tool that enables developers to mock dependencies while developing applications, enhancing productivity by allowing for simulations of APIs without needing the actual services. The session emphasizes how integrating Score and Micro can significantly alleviate resource usage and configuration drift while ensuring a smoother development process.

Yeah. >> Okay. >> All right. >> Shall we start? All right. Good morning, everyone. I hope everybody has find its way. >> How is this room? Is everyone doing? >> Yeah. Excited. Nice. >> Okay. So, thank you for joining this session. So, uh have you ever heard it works on my machine mantra? Yeah, I'm pretty sure everybody has. Yeah. So uh in this session this morning we

are going to explore solutions on how to avoid this situation. How to make the transition from your developer laptop to the production environment and other environment the easier possible the the most smooth possible. And we want to uh yes to to avoid also putting too much cognitive load to the developers to the platform engineers and also to avoid consuming too much resources when developing locally when deploying

environment and so on and so forth. So we have a lot of challenge to address. So without further ado let's jump to uh our demo application. This is the finest trade trader hicks sample application and this is basically an application that was made to illustrate the microservices architecture in a banking situation. So you can place orders, you can uh review positions, you can manage accounts, add users

to accounts and so on so forth. So it looks pretty simple. However, if you look at the architecture, yes, it's still a lot of components in different technologies uh using different development stacks. So, quite a lot of resource and I have made the the diagram the most simple as possible. There are way more components that are deployed. So, here on the demonstration, it runs on Kubernetes. It

uses a fair amount of resources and a fair amount of Kubernetes object. Okay. uh and because it's containers it can also run on your local machine okay using docker compose but here still you have as a developer to pull a lot of images wait for a lot of time each and every time someone updates an image uh it takes a lot of place on your hard drive

okay uh and it consumes a lot of resources so it's possible but the hard reality is that developing the Trader Hicks application could be kind of hard because as a developer you may have no access to the dependencies. Maybe they are not yet ready. A new feature is being developed at the moment by another developer. So it's kind of hard and you have to to wait or

you can access all the dependencies but it comes with a price CPUs memories cognitive load because you have to remember anything to remember how to deploy stuff how to run stuff locally and still as a platform engineer there is also a big risk about having a configuration drift risk between your local development and the Kubernetes cluster in staging in QA grain production whatever. So we do think

that there is another way of managing things that uh allows to to solve these issues. So before jumping a few words on both of us. So I'm Lauren I'm working at Postman and I'm fully dedicated to the micro opensource project. Micro is a CNCF sandbox project and you'll learn more about Microx in a few minutes. >> Hi everyone, I'm Matthew Benoa. I work at Docker. I'm also

a clone native ambassador, CNCF ambassador and CNCF maintainer for the uh CNCF sandbox project named score and we will talk today about score and micro. Let's do it. So yeah, what we want to uh show you so bear with us here is the journey for today for this alpha and our session. We will discuss about uh on your left what we call the inner loop. It's very

much about the developer um environment local environment that's where your developer should be productive right um but then there is a bridge uh because uh developing debugging testing is good locally but how we ship that in production and maybe in integrated environment like staging development etc etc so that's what we call on the right side the outer loop right and the talk today um will be about

maybe some tools that you are already using or your developer are using locally Docker, Docker Compose and maybe a Kubernetes platform more for integrating uh and staging environment or even production. Um actually in the other side what we will see today is how score could help um mitigating some drift uh issue or some inconsistency and some cognitive load on the developer side and as well on the

platform engineering side. uh but what we will see also it's a combination with micro in order to mock certain services that maybe some of the people or some of the environment don't have access to right so that's all about that so I hope you will enjoy this journey with us um first what is score uh and why score right so score is first and foremost um a

workload specification so as a developer I will describe my intent to deploy at some point my application and I don't know where which environment which platform I describe on a very generic aspect the workload metadata the maybe environment variable the service I want to export my workload uh and you could see uh at the very bottom right the resources section and that's where actually sorry I should

double check sorry that's an example and I will show you live Um but on the resources section uh at the bottom that's where the developer will be able to describe their uh dependencies. I want a radius database. I want a posgress and I may want to expose my workload via a public endpoint a private endpoint. I don't know right but what I don't know at this stage

is a technical detail implementation. Is it in Azure? Is it on Kubernetes? What are the technical detail implementation TLS? I don't care. as a developer I don't care right uh again I was not showing but at the top um above the resources section that's where the developer will describe their um metadata about their workload so that's the first part of the score project but now here is

the opportunity to have a concrete implementation right because as platform engineer now you will have what we call a score um first uh we have for example score compose Right? And that's a way to translate your score file into a compost file. Right? So that's one implementation. But you could have also the Kubernetes one from the same exact score file. Hey, I want now to go in

Kubernetes and I may want to go in other platform. Fly.io that you may know about and other platform that you may recognize open coro cratics radius. So the goal is very much to have this abstraction um for the developer perspective and the concrete standardization from a platform engineering and platform engineer perspective. The other um opportunity for the platform engineer is with this implementation now what about a

radius database in compos is it a container in kubernetes is it a container or a manage service for radius for posgress etc etc. So you have the opportunity to define wellsupported golden path and how you want uh to actually answer the request that hey my workload need a radius here is how the radius will be provisioned right so al together platform engineer will select the wellsupported implementation

the platform actually right uh they will provide the uh supported resources and dependencies and all the developer will be able to interact with that on the left that's what we call the abstraction and the opportunities for standardization here. So what I want to show you very quickly is actually Lauren mentioned uh this application you remember and actually um this application is already deployed um on Kubernetes cluster.

So here what I want to show you is how it was deployed and I hope you see uh the screen wonderful. So the goal here again if you have never seen a score file uh that's a score file. I'm for example the developer of the trade service and I will define here some metadata right environment variable uh maybe the image that I have access to the service

I want to export this uh the port I want to expose this service uh and all the resources section right again that's dependencies I depend as a trade service to another service people service position service trade feed and maybe a database right so that's where you will be able to define uh everything here um how it was deployed right you remember what I mentioned about the core

kubernetes implementation that's how you will do that if you uh see here we are in the CI/CD pipeline right we are deploying in production in Kubernetes we are taking all the scar files so each individual workload will have a scar file I just show one but you have uh seven or maybe nine of them here and the goal will be to here generate all the Kubernetes manifest

is it ingress config map service deployment stateful set secret etc etc it's 600 of lines for the final rendered Kubernetes manifests that will be deployed in production right but this part is abstracted from a developer standpoint right so what was uh done here is it was deployed on a Kubernetes cluster and we could see the pod running and again. Now I have access to the exposed DNS

and I could look at this um at this uh application running in my production cluster. Right. >> Right. >> Wonderful. So what I want to show you very quickly here is a second part because you remember I have one score file and one score file per workload maybe nine in this case multi- uh microservices here. Uh but look at this. Now I could do the exact same

workflow but with core compose I'm aggregating all these core files right same we don't ask the developer to modify to update their score file depending on the platform right and what's going to happen here is we will generate the compost file and guess what someone will do docker compose up on the compost file but the scar file was the same and I have now a compost file

maybe 70 lines of compost file. So I don't need as a developer to know how to do compost file uh here and docker stuff here. I have my running container nine microservices and guess what I could go there and now I'm using this application on local host and it's working etc etc. So what what we just did right because here we show the score kubernetes generate I

want to deploy in kubernetes from the abstraction on the uh workload spec and score file same with score compose so what we kind of uh answer here and simplified a bit it's the cognitive load on knowing the actual platform and technical detail implementation on a developer standpoint maybe some configuration drift but here Laurent I think you have something for us because >> I still have a lot

of dependencies. I still have a lot of CPU memory and um >> sure you we can make things better regarding how we are using resources and how we are uh lowering the number of dependencies and so on and that's where my crocs enter the game and uh my supplies very simple strategy as a developer if you need something but this thing is not yet ready or not

available there is this simple strategy you just have to fake it until you make it or until you actually need it and that's typically why the principle of micros and luckily how we how are we doing that luckily we are in a service oriented world you know uh this is an application the distributed application of services represent uh promises of business features and uh they are uh

those business promises are codified as API contracts and the nice thing about API is that the high stands for interface. So interface is how things look like how they what they pretend to be. You don't have uh any details on the implementation and that's typically what we are going to use here uh within micro. So thanks to API contracts, thanks to interface, we have this ability to

build not only sandbox but full sand castles that represent that fakes the reality until the reality is really available. Okay. And uh what's nice about this sand castle analogy is that it looks real. It's not made about the same building blocks that your production system, but thanks to the API definition, we have this ability to to build real dungeons, ramparts, and toers and so on. So, how

does it works? Basically, it's really easy. You have to collect the different artifacts that may be already there into your organization. So, it could be open API specification, could be postman collection, graphql schema, gRPC, protobuffer and so on and so forth. and you just put ingest everything into micro and from all these artifacts micro will provide just uh API endpoint simulation on the fly. The more information

you put into Micros the smartest the mock will be and they will be they will represent the real life and the real behavior of your API. Okay. So what we want to achieve here is uh as a developer I want just to focus on my application the purple box on the left and I will fed my crocs with all my API contracts and it will provide me

API endpoints and those API endpoints will be automatically wired into my application. So I will work with simulation even without knowing this. So one thing that is very important in micro is that we you may think that contracts are just simple syntax definition but we just don't rely on contracts. You may in fact put many different artifacts into micros. So open API contracts for example are the

primary ones but you can also complement with postman collection with recording of existing traffics using HTTP archive. You can provide YAML files with examples. You can also plug in your favorite skills to have your LLM enrich the data set and the more artifacts you put in micro the more representative will be the the simulations. There is a ton of uh features you can activate to have really

smart mocks. You can use templating. You can use scripting. You can also have stateful mocks if you want to simulate some interaction this kind of stuff. The very important thing here is that all the core engine micro also leverage open telemetry. So at any point you have this ability to observe uh why you receive such uh such response from the mock engine and to fine-tune the behavior

to be really able to to have representative Okay. So now we see how we can simulate things, how we can lower the resource and let's see how we can use together score and micros. Wonderful. And Laurent, you did a great job because I'm the platform team, platform engineering team. And the developer saw your uh value prop with Micros, and they want to be more productive, right? Uh

they want to innovate faster. Uh and here is the opportunity. We discussed together the developer and the platform team. Why why not trying to fake mock some dependencies that this developer doesn't need? So I am on the front end side right on the left. I don't need to pull all the AV images and having the space and maybe having some um blocker because I don't have access

to them actually. So here with micro on the right we will mock all the five um component here and uh let me show you how we did that actually. what we did you remember I have my score file and what we did is a seamless integration with the micro uh concept and technology here because we didn't ask the developer to touch and update anything on their score

file. They still have this score file here, right? And you remember the resources section, right? We didn't ask them to touch anything. But here is what we did via score. And in this case, I will show you first with core compose. We just said, yeah, just tell me which workload you want to deploy and I will fake all the other one, right? And I will mock all

the other one. So if you remember the previous command it was nine 10 microservices and workload specification now it's more it's just four right >> so you so you mean score will figure out what you need what you rely on and actually if you don't need this component but uh need it as a dependency it will pop out a micro instance and feed it configure it automatically

>> exactly look at this I just did score compose generate just the one I actually have and please mock the other one. And we could see that the five are now mocked as a dependencies. Right? So again, if I look at my compost file, I will have a simplified one here. Right? what you could see as well in term of pulling and deploying and running actually the

container, I'm just running the four I need, not the five I don't have access to. Right? So here what's interesting is now I still have access to my you remember local host boom I have access to the entire application thanks to the contract with Microx and the mox from Microx perspective and I could still be productive here but I'm using just the resources I need right um

so yeah what do you think Lauren >> yeah cool so I can imagine so yes we used a Not. So what you did is just reusing your compos implementation but still introducing a new provisioner in the game the micro the micro one and so score figured out what we should use as real image but what we should also fake using micro that's pretty cool and the results

are really interesting here. So >> and actually Laurent >> I forgot about that. Look at this Now I also have access locally to the micro UI kind of the control plane. So it's not magical. Look at this. We were able on behalf of the developer to register the mock in my right. So that's the five uh microservices now mocked within my right. So what I could do

again uh very quickly because uh I want to show you something very interesting here is I could have some interaction um on the uh local host actually. Thank you Laurent. Um here I could test and play uh with my application but when I go back here I could also see more information for example I want to see in action what's going on >> right so that's a

kind of uh also productivity tool that you have locally and you have access to uh with that so >> so you're just not blind these are not dummy mocks you have the ability to also inspect and observe everything and all the different interactions with the mock if you want to fine tune stuff and so on. But just using the default, you can see what kind of results

you can you can achieve. And so on the resource consumption side of things, we drastically uh lower the number of image to pull, lower the size on disk, lower the concentration of resources. And so when when dealing with very big and complex uh application, this is really a gamecher regarding uh how fast as a developer you can iterate, you can pull new image, you can deliver stuff

without having to think about all these Okay. So using Mox really nice and with material we we talked about this opportunity opportunity because uh you know that in real life it's not just the developer laptop and the production environment in between you have a lot of different environments and maybe these environments are just used fraction of their of their time. Maybe it's 10% of of the real

usage but you still have to provision and to manage full environments. So there is an opportunity here also on certain stages to integrate mock because if you want to do uh some QA testing on the web front end for example you don't need to have all the other back ends being there so there is a real opportunity but a question arise if you're using mock on different

stages how you the transition between mock and real life how you can smooth the transition and that's where uh this practice of using mock can be also used with this other practice of using contract testing and guess what Microx is also providing contract testing for free. So based on all the artifacts you have previously put into Microx it has this ability to generate a full test suite

for your API endpoints. So once your API implementation are developed and deployed here in green it can automatically test them. So you show you didn't introduce regressions breaking changes and so on. And guess what? This can be automatically integrated within your CI/CD pipelines. Okay. So here, for example, for the trade service, I'm able to use Micros for the dependencies on the right, but I'm also able to

use my crox on the left to be sure that the trade service still conforms to its API to be sure that it will still fulfill the promises it has described. Okay, >> wonderful. And actually, that's a good point. development environment, the inner loop, the outer loop in production, but we want to bridge the gap in between in sta in dev in staging in Kubernetes in order to

have more quality test guard ray. Right? So what we want to show you very quickly and you know what Lauren look at this what we were able to do as the platform engineering team right look at this I'm able here to do that I will ask you as a dev to still use the same score file you don't touch this again right and um sorry and you

remember as well on the make file here for my example to speed up the demo I will still ask you just to provide me the one the workload you need to deploy and I will mock the other one as well. >> But here you're on Kubernetes, right? >> And now I'm on Kubernetes. I'm not asking you to change anything. So I'm deploying that in my CI pipeline

in dev in staging in a Kubernetes cluster. Right? So that's what we will be able to do. Cool. And look at this the manifest now it's not 600 of line it's 300 of line. Right? And we are using um the power and the features of Microx here. So I will have all the Kubernetes resources. We could see that we have less resources than before. That's expected, right?

And now look at this. I have access to my staging environment. Sorry about that. Here. And if I go if I go there, I could test now my application in staging. Boom. It's entirely mocked via >> Yeah. But still the same one, still the same behavior >> and still same uh configuration as well as a developer standpoint. Right? >> And again I could test my application. And

here if I show you very quickly the UI of Micro the control plane in this Kubernetes cluster now, right? Look at this. I have access to all the API services. Same principle here. Right. I could do the live traces as well, right? Everything. And you mentioned contract testing. We want to make sure there is quality here, right? So what I could do is going there and I

could add a new test and here I'm doing clickups but you could automate that via GitHub action and CLI and I could say hey please make sure that my mock and now the live one maybe in integration staging environment is compliant and uh successful, right? >> Yeah. To be sure there is no diff between the implementation and the contract. That's exactly pretty cool. >> Thank you. >>

Okay. And so basically here again score Kubernetes with the micro provisioner and that's it. And so that's what we have for today. So missions done. >> Yeah, I think we we >> green everywhere. We have solved the access to dependencies even if not yet ready. We have solved the consumption of too many resources. The the cognitive load is also lower now for the developers. So there is

definitely another way of doing things. And so we've shown that on these uh two loops in a loop s loops you can use core to uh avoid totally the risk of configuration drift uh drift with this abstraction layers of the compost file. And with micros we have this ability to accelerate the development mocking dependencies where they are not ready or if they are too heavy weight for

the developer laptop and so on. And you can still use micro in your Kubernetes clusters in auto loop for performance testing and also to lower the cost of your environments. And that's >> wonderful. We want your feedback please and please visit us. We have two kiosk for micro on Wednesday. So tomorrow and Thursday for score. Please come visit us. Encourage us. Ask your question. We hope you

enjoy this journey and this story uh we went through today with you. Thank you very much.