Platform Engineering for startups | Zander Hornung Havgaard

Hi, my name is Zander. Welcome to my talk. It's called Laying the Tracks in Front of a Moving Train, - Platform Engineering for Startups, - which is what my work at Green.ai feels like, - because when I started a year ago, - we had some challenges, namely that we're a small startup. At that time, about a year ago, we were two developers, - myself included, plus four data scientists, - and we were creating all the software that makes up the business and - operating all of that software. We had about 40 workloads in production at that time, - and they were deployed with four very different deployment flows. They also had different operational concerns, - different ways of doing telemetry, and so on. So there was a lot of overhead in maintaining all these different ways of - deploying applications. We also had a nice ClickOps infrastructure. If you don't know what ClickOps is, it's when you open the web console of your - favorite public cloud provider and you start clicking on buttons to create - things and inevitably something will break and you will have a hard time - fixing it because you don't know what was created, when, by whom, - why, and so on. And because we're a startup, we know what software capabilities we need today. We don't know which ones - we will need in the future, only that they will be different. So my colleague Matthias and I, we sat down and we looked at it and we - decided to build a platform. Nice. Okay. How do you build a platform, right? What should the platform do? What are the requirements for the platform? So in order to figure that out, we asked ourselves the question, - what is the smallest platform that we can build to solve our challenges? And in order to inform that, we asked ourselves, - what do we need right now, i.e. what are the must-haves , - and what can we add later when we need it, - i.e. what do we also need right now, but we can live with doing it manually, - and then when it gets too expensive to do manually, then we automate it. And answering these questions led us to what we sort of call the minimum - viable platform, the MVP. So the requirements for the MVP, as we saw it, - is that we needed an extendable control plane - because we want to automate things and we want to automate things today. But we also need something that can grow with what we need in the future. Paved-roads is a trope in platform engineering. It's about creating sort of streamlined processes for doing things. We also want to do this, but we're nowhere near mature enough to know - what our paved-roads look like yet. But we still wanted to create these nice streamlined ways of doing things. So instead we sort of had this idea of let's carve a path in the jungle and - maybe lay down a little dirt track. And then it's just good enough that it gets the job done, - but it's also very easy to implement. It is very easy to go off-road and do - something custom. We also needed single panes of glass, - i.e. we wanted one place to operate all of our workloads, - one place to operate all of our infrastructure, - one place to view all of our telemetry, and so on. Everything must be declarative, so everything has code. It's been a year. We have gone from four different deployment flows down to one. We have onboarded 110 workloads in production. We have automated our deployments. This was one of the things that we could live with doing manually - in the beginning, and then once it got annoying enough - bumping version numbers all the time, then we automated it. Since we did that, we have done more than 1,700 automated - deployments of our business logic, and we have done more than 2,000 changes - to our declarative configurations. And while these numbers are probably pretty abstract, what I think the story - they tell is that our platform is evolving and maturing and changing. Here's an example of one of the jungle paths we've created. We have this Helm chart that we deploy all of our services with. Recently, we adopted Argo workflows. And for our platform users, switching to Argo workflows was as simple as - changing out two keys in their Helm values file. So that was nice. Subjectively, - my colleagues say that they like to use it. So that's nice. And finally, I will leave you with the question, - what is the smallest platform that you can build today? I have a lot more to say on this. Please come and find me. I would love to talk to you about it. Thank you. That's all from me.