 Hello. Good morning, everyone. Welcome to Keep Day, and I hope you will enjoy a lot of enjoyable talks in this session. So platform engineering has been a hot topic for the past few months, or maybe even a year. We've seen companies on the fence of using it. We've seen companies starting their early days of using platform engineering. But we've also seen companies that have been using it for months, or maybe even a year. So in this talk, me and my friend, Joshua, we will guide you into our journey of iterating Gopay.sh, our internal, in-house built platform engineering that we've been building for about three years now. So Joshua, can you guide us? Sure. For some historical lesson. Let's just mine. OK, thank you, Aditya, for the introduction. So long story short, fortunately, our business grows, our customer grows, and so does our engineering team. From just a simple one column of balance value back then to a full-fledged financial service provider, people are joining up to almost the number of 200 features are being built across 30 teams, and help charts are written for almost 1,000 services, quote, glue here and there. And as the goal flow states, the complexity is unavoidable. This complexity, unfortunately, finally bet us back then when we want to move our in-house envoy proxy control plane to Istio service mesh. We don't know which team is responsible for which services. We had to ask people to introduce changes to un-maintainable, almost 100 help charts. We'll need to ask them to learn a little bit of the Istio concepts like the virtual surface and destination rule. And the worst of it all, we all track all of these in spreadsheets. And as you can expect, it failed terribly in just after one year, only 2% of these services is being onboarded. This kind of issue, we want to bring changes to our engineering. And it failed, tells us that we had to be honest to ourselves that our engineering back then was not scalable. And I want to emphasize that we're not talking specifically about surface mesh or any kind of technologies. This was the one that we found on our journey. And it might be very well different to the one that you might encounter in your engineering team. And these kind of changes that expose and tell you that your engineering team was not scalable. And we learned it the hard way that the motto that our infrastructure team should abide by is to enable our dear friends in the product engineering department in doing the right thing without any worry and hesitation to what would happen to their products and services autonomously. From then, our platform has grown to a full stack solution with observability, configuration, stateful components, canary deployments, cost insights and optimization, and various other features that the product engineers can just use for their services out of the box on their own without any hassle. No home chart needed to be maintained by their own. And we from the infrastructure team just only need to maintain one home chart. This enables us to expose our platform offering to the wider audience in a consolidation that is currently still ongoing to onboard more customers that will bring our platform to this number in the near future. And next, Adito will tell us about how we're making sure that the platform that we're building is in the right direction along the way. Thanks, Joshua. So how do we evaluate it? That might be the question. In the end, we did these four different tasks to ensure that what we have is actually giving value to the developers. We did survey. We did ticket analysis. We did user interviews. We also did some event monitoring that's happening in our platform. All these results in these three different findings, we are able to validate our solution. We're able to pinpoint what are the other gaps. But also, more importantly, we are able to measure the adoption of the platform engineering to the internal tools. But how do we actually evaluate it? So the first thing that we formulate is one thing that we call developer workflow phases. We learn that developer work in this kind of cyclical phases. The first phase is discovery phase, where in this phase, developer discover what they need to do, what they need to work on. The second one is the right phase, where developer actually write the code. The third phase is to test. This is where developer test whatever they are typing, whatever they are working on. And finally, after successfully passed through the test, they go to the integrate phase, where developer deploy the services into the production environment. The last one is verify. This is the part where developers verify that their code deployed to production is actually working both functionally and operationally correct. Then they can go back to the discovery phase again. And the phase goes into the next cycle. And platform will play a very huge role in giving value to developers in the discover, integrate, and verify phase. And this is where the part where we should evaluate our platform, whether or not we've successfully delivered the value to developers. And how do we actually measure it? It's by one thing. We want to measure the efficiency. Because if we go back to the original problem statement, where we want to scale the engineering practice, scalability is actually a function of efficiency. The more efficient you are, the more scalable you are. So going back to the developer workflow model, we know that the sooner we can bring back developer to the write and test mode, then the more efficient they can work. They don't have to wait for tickets to be resolved. They don't need to wait for manual intervention for them to go to the next phase. This become a very efficient work. In other words, if they have to wait for tickets to be resolved, if they have to wait for somebody from the infrared team to go and help them, then this is an inefficiency happening. And so one proxymetric that we track in order to measure the efficiency is the number of tickets. Because this indicates how many helps does the product engineers need from the infrared team. One ticket can probably be resolved in range from half an hour to maybe a day. And if engineers have to wait for this time in order for them to go to work, then this is definitely an inefficiency happening. That's one metric that we are tracking on a daily basis. And this also contributes to what we should build next. We look at the tickets and then we see, oh, this feature we haven't enabled. And for these kind of activities, developers have to wait for our manual intervention. Then this is where we need to go next. That's basically our strategy. And also, on top of that, we also tracked the customer satisfaction. We did a yearly survey. We tracked the satisfaction. And we're glad to report that from this year, we got around 80% of the customer satisfaction up from about 70% from last year. So basically, we did our homework. We deliver. And we basically success. So what are the lessons that we learned from that kind of activities? Joshua? Thank you, Aditya. So even though our customers are product engineers, mostly, we realize that just like any customer facing products, our customer is coming from various backgrounds. And for that, different motivations as well. Some want to make sure to get their deployments right and safe quickly. Some want to get the bird eye view of the overall cost. Some users give very thoughtful inputs and even want to contribute voluntarily to the platform. This is the one that we should need to keep them close by. And some stakeholders are the one that we even found along the way, like the security team or the ITJRC. And we realized that providing what they want and achieving a common goal is not a separate end of the same line. We live by our motto that if we want to go far, we need to go together. And this is how we make our platform from the get-go. We build our platform based the Open Service Broker API so that not just the team that is responsible for the UI facing platform that is able to introduce changes to the platform, but also the other team within the infrastructure engineering team. With their own respective area of responsibility, they can introduce changes to the platform independently to the customers of the platform in the form of add-on providers and marketplace. For, let's say, for the safer components team, they can provide redis and Postgres and even its day-to-day operations. For the foundation team, they can help the service owners to expose domain and so on and so forth. And referring to my previous point, we had add-ons that even were contributed by the product engineering team to share the common tooling together to the wider audience, like the database partition manager. So these kind of marketplace and providers model really work for us. And for the core point, I would show you a detail. Thanks, Joshua. So the question is, how do we build next? What are the things that will guide us to build the next version of the platform? So we come with four different checkboxes that we call the design principles of platform engineering. So basically, we need to checkbox all of these four in order for the platform to be able to deliver value, one. But also, these design principles should cover not only the technical aspect, but also the human and the organizational aspect. So one, we need the platform to be able to provide a best default. So if an engineer forgot to fill in a form or they basically decided not to change any value, that value should be enough for them to be able to operate their services correctly. The second one is to make the platform to be open for collaboration, as Joshua mentioned, we need to be able to fulfill the needs from different teams. But also moreover than that, the platform owners need to closely collaborate with the users and stakeholders in order to align the platform with the actual needs from the product engineers, but also the actual needs from the business. The third part is to only abstract what you need. We need the platform to be crafted as such that it fits with the product developer's mental model. They may not need to know all the configuration of Istio, all the Kubernetes configuration, but they need to work with whatever close with their mental model, which is surfaces, making it logically correct. And the fourth one, because basically platform engineering is an internal tool, then it has to enable test delegation from somebody on the higher up that have huge feasibility over the wide area to the person that have more detailed view on ownership of the services. This kind of test delegation needs to be enabled by the platform. That one thing, but also the second thing is that whoever owns the next action needs to be able to efficiently complete the action. Maybe it's self-surface, maybe they only need another manual intervention, but only as efficient as possible. So these are the four design principle for platform engineering that you can also use for your organization. So we seem pretty successful in this journey so far, but I think one key point that I want to share with you is that basically I think we get lucky. We're lucky because we arrive in the intersection of three different things, three different very important things for platform engineering to thrive. One is that we get stakeholder buy-in. We get the business buy-in from the higher ups. They see the need for engineering to be efficient and they need a systemized workflow for that, and that is the one that is currently provided by the platform engineering. The second thing is we arrive in a very collaborative engineering culture where product developers are willingly to contribute to use the platform, to give feedback, to even give some pushback if they see that this doesn't very fulfill their needs. And this happened in a very collaborative space, very respectful environment with the blameless culture. The third part is we have the info team working on the platform engineering, but they don't only care about delivering feature, but they also care about delivering value to actually solve the problem from the product engineering. So they don't care about, they don't only care about what feature I deliver, but they also care about if this feature actually solves a product engineer needs. So these three intersections give a very, I can say a very good environment for the engineering platform to grow. And finally, I want to conclude this session by saying that your engineering platform will grow together as the company grows. It goes hand in hand. So it's the job for the platform owner to constantly evolve it to cover various use cases that might be undiscovered previously. But moreover, these cases must enable product engineers to be productive, but then on the other side, it has to be able to keep the info reliable. And our lesson from our experience, platform needs to be, there's always need to balance between productivity and reliability. And it's a job for platform owners to balance between these two aspects over the years. And this will make the platform valuable for the business. Thank you.