How to Build a European Cloud Orchestration Platform From With... Maximilian Techritz & Johannes Ott

This talk presents a case study on building a cloud orchestration platform in an enterprise environment. The speakers, both from SAP, share their experiences of open sourcing their project and contributing to the Neonos Foundation. They discuss the complexities faced by engineering teams due to the multitude of tools required to manage cloud resources and the need for a unified approach. By adopting Kubernetes resource models and leveraging tools such as Crossplane and External Secrets Operator, they streamlined the orchestration process. The presentation emphasizes the importance of user engagement and education, as they provide enablement materials and foster a community of practice to empower contributors with varying levels of Kubernetes experience. Ultimately, they aim to enhance operational efficiency and collaboration across teams, demonstrating significant improvements in their cloud landscape rollout times.

Hello there and welcome to our presentation of how to build a European cloud orchestration platform from within an enterprise. This talk will be definitely more relaxed. We are at the second half of the day. So sit back, relax and enjoy our story. We basically want to share our story how we've identified a problem within our enterprise 3 years ago. Um how we've open sourced our project and

our methodology now donated even to the Neonos Foundation which is part of the Linux Foundation Europe. So definitely sit back, relax, and enjoy. >> Cool. Thank you, Max. Well, who are the two of us? We're coming from SAP. We are working or we are speaking here for the Neo Foundation. Johannes and Max, both software engineers. I'm also focused on the community growing inside and outside of the

organization. But more importantly, we are working with a team of uh roughly 45 engineers that are fully devoted to this project. And already today, we are serving a community of roughly 500 plus stakeholders and are engaging with almost 100 plus contributors. More importantly towards the end of this talk or throughout the talk I hope we can excite some of you here in the audience to also um

make use of the methodology we're sharing here and maybe even see one or two or even more of you as contributors in this pro project. What is it that we're actually trying to mitigate? What problem are we actually trying to tackle here? And for that, let's step back for a second and look at how does a simplified software usually look like. And for that, well, you have

a runtime that actually runs your application logic. You usually talk to a database. You expose your application through a domain name service. You have your secret stored in a vault. And at the end, your engineers are talking or the application your engineers are building are talking to a bunch of APIs from cutting edge clean ones to really dirty old uh legacy ones, big range that we have

to cope with in order to power one application. So far so good. That's not really where our uh criticism or our our pain begins. Let's look at how most engineering teams or many engineering teams are configuring how they're achieving exactly such a cloud landscape. And for that here at CubeCon should be quite straightforward. Well, in order to deploy our application, we deploy them to Kubernetes. There's a

zillion cool tools. then there's the database. There are all these proprietary services we just uh heard about. We see GitHub actions. uh we see Jenkins pipelines being used all over the place to really orchestrate and configure whatever is left and right in many parts of many organizations. We still see a clickops based approach or some issue based handling of then configuring a domain name service um while

other parts might be configured through terraform or other tools. And this is where especially if you look through it from an enterprise perspective, we see a big dilemma because you can't redo this for each and every landscape. We're rolling this out to public uh landscapes in different regions. Uh we're shipping it to private landscapes. We're also shipping it to sovereign clouds and this let's do something using

this tool. Let's do something that tool does no longer grow. This will really bring us into hell. way too many tools involved that are not aligned that are not compatible with each other. It introduces gigantic complexity that each and every engineering team has to cope with. It leads to errors and it leads to a big big time that is spent on exactly that work throughout our engineering

work. So we looked around what can we do about it? How can we solve this pain? And in a nutshell, we wanted to bring our engineering teams from using many methodologies to one for as many bits and pieces as possible. And how did we actually get there from a technology side? This is what my colleague Max will show to you today. Well, and the solution for it

seems to be quite simple actually. Let's grab every aspect that Johannes was talking about earlier and bring it to the Kubernetes resource model. If we look at today's application stack and the tools we are using, you've seen this picture before. But if we look at the CNCF landscape and way beyond in the open source ecosystem, there are already so many great tools at our hands um that

help you achieve this with the Kubernetes resource model already today. So there are tools such as crossplane. Frostbin is a really powerful tool where you can like manage databases, DNS at GCP, storage at AWS again from within the control plane using um yeah crossplane providers and you can crossplane is even a framework. So you can build your own crossplane providers around your proprietary services and internal APIs.

So you bring those orchestration capabilities around those resources that you want to orchestrate in the same look and feel into the Kubernetes resource model in the same control plane as well. So that is handled by a crossplane. For example, if you want to sync secrets from A to B from your secret store down to the runtime cluster, we have external secrets operator. Another great tool in the

ecosystem. And uh if you want to build on top of it, you have you can you can define custom policies um using open policy agent or cyano. And if you want to bundle everything together, well then use githops best practices. Just put all your configuration files and yaml in a git repository set up flux or argod and they will take care of syncing the desired state from

the git repository down to your control plane as well. And these are just a few projects that I wanted to name here. I mean they're looking at the CNCF landscape there are so so many projects that you see for different use cases as well and actually three years ago we've started our enterprise journey exactly at this point we saw there are so many tools out there and

um we just motivated different development teams different engineering units within our enterprise to try this to try out crossplane to try out to adopt external secrets operator and ditch other pipeline technologies shell scripts whatever they have written before and the result well we've built a community we actually built a community of people and the development teams actually started to adopt those projects and um they were actually

get back to us and said like hey that's really great that really makes us happy we actually have fun orchestrating all those resources again because we have one API and it actually feels like real automation compared to their endless line of shell scripts that they have might use before but there is still one problem attached to it I mean in all of our organizations our our companies

and enterprises we still have people people from different background from with different skill set and experiences some of them don't have real Kubernetes experience and all of the sudden this group of people need then manually to install Flux via it CLI or crossplane via Helm and then all of the sudden also need to upgrade external secrets operator with Helm upgrade once again I mean that's hell if

you want to to achieve this in all of the different environments and that's why we are building open control plane. Open control plane is an open source project where engineers front end engineers backend engineers um DevOps engineers even managers can order a control plane and all those different capabilities and services such as flux crossplane external secrets operator as a service into your control plane as well. So

what your engineers get back is actually a cube config to a control plane where all those different tools such as crossplane flux and external secrets operator and many many more are pre-installed and preconfigured for you. So you have a self-service cube cube API where you can like um yeah order all of these things and yeah you get this simply this cube config back and it's essentially a

control plane as a service and it is extensible in every aspect. So, open control plane does u support all of the open- source projects that are already out there um to bring this in in a SA service um yeah compatible version and you can even um like hook in your uh internal Kubernetes operators that you might have built inhouse um in the same as a service operator

pattern via open Open control plane right now runs on Gardner and on all major cloud providers through Gardner and we even have support for local scenarios. So you can even build up your whole open control plane environment on a local machine on your Windows PC or MacBook to try it out yourself. We have support for kind as well and many cloud providers and all many other cloud

providers will follow then with the direct integration then soon. And if you want to see it in action, feel free to um check out our booth 993 in hall one. It's actually next to the t-shirt pickup um where you can see a really cool demo where we try this actually. All right, but let's get back to our enterprise journey. We've definitely seen that people have adopted within

our enterprise to use all those different major operators cloudnative technologies really great but they're using it. We still have people in our organization that might have limited to zero Kubernetes experience and of course we haven't had solved this challenge of all those different internal APIs and proprietary services where no Kubernetes operator or crossplane provider exists. So how do you actually enable people within your own company to

contribute to actually such a methodology to such a mindset and that's why we need to talk about people and culture. Yep. Exactly. How did we now that we have this great technology allowing them to quickly get into the control plane methodology, how do we now enable the people to follow us on that path? And that we basically put onto numerous pillars that we invested in a we

learned about it. We invested in exactly this open control plane allowing this service in the organization. But to really grow excitement for that what we did is we met on a monthly informal session actually with the engineers to present or to bring relatable use cases exactly to this round um to again learn and see together why control plane matters and how it solves the pain points they

are facing day in and out. For these sessions, we always made sure that we do not require any knowledge but we rather spread knowledge because this is sessions that our engineering uh friends are attending also outside of their regular work routine. So here we really had to make sure that um we don't ask for more but really give them something to take out of our format. And

last but not least um through this journey we always had to make sure that we involve people and stakeholder from the different parts of the enterprise so that we can really bring them together and always highlight hey many of you inside of this larger organization you are sharing uh you're facing shared pain points and you together can solve them and here's an example of how that has

been accomplished but only exciting them doesn't really solve the pain again you then have to enable them. So soon after these tech talks, people ask, "Okay, so how can I use this now?" And here our team um invested tremendous um time and efforts into writing enablement material really end user beginner friendly. Think of the simplest case, put that in an enablement guide and roll it out, learn

along the feedback how to make it better. Also use that material, run virtual and uh on-site enablement workshops and again learn from how it's perceived by the people. Can they make use out of that or is it only frustrating them? Because what we quickly learned then is okay there is relevance for many many teams. They do get the idea of control plane methodology. They see a need

in that but at the very end you still need to convince them to contribute to enrich the offering because again we heard it numerous times now there is APIs within an organization where there is no operator there is no provider um in place and that needs to be as a team as an organization as a continent as a as humans basically be built together and again we

invested in contribution material um that we can see here on the right hand side exactly catering the needs of the people in our organization wonderfully. Our students actually um some of our working students took some time and also turned it into a video series. Um but again we invested heavily into workshops and hackathons to again get the contribution mindset into more and more teams which we then

of course also equipped from our side with reusable coding samples, pipelines, testing so that not the entire organization is reinventing the wheel here but we together have all the right approaches and tools to contribute together. That is basically the third pillar which allowed us then to really bring this idea to a larger community. Um that is allows now all these teams to invest in the proprietary um

operators um or provide us anything that is needed here that can then be built in an inner/opensource fashion. That is the idea how we um or that is basically how we for the past three years now engaged with the company. And the cool thing is for one and a half years we are now able to also really actively um bring this to the to the to the

teams working on their solutions. And the cool thing is they're already coming back to us sharing how this has increased their cloud landscape roll out time by times 10 or decreased it by times 10 and also significantly increased their roll out and operational confidence. Unfortunately, I'm not allowed to talk about actual numbers, but just to show you the adopting trend from the recent one and a half

years that we see within our organization made possible by this open control plane stack that's free uh to all of us. Um yeah, just something that we're really proud of to see the growth and the trend is pretty clear. This uh finds um great adoption in the application engineering teams and resonates pretty well in that area. Yeah, if you would have missed today's presentation, here are some

few key takeaways that you definitely need to remember if you want to replay this in your organ in your own company as well. Um, people only get started if it's really relevant for them. Try to find the most common pain point, most common pitfall within your team that also other development teams might have. It might be some internal tool. The good news is if this internal tool

has an API, you can definitely build a Kubernetes operator or a crossplane provider or you name it around it. And on this journey and collaborating together and jointly building such an operator, such an K cubernetes operator um especially try to enable people with zero Kubernetes experience. It's definitely a very steep learning curve, but this will eventually grow into a community of practice. And last but not least,

never ever build a platform without its users. And that's why we're here at stage and you guys are here then because we want to reach out to you. Um let's talk, let's get started. Um check out our documentation. Um feel free to check out um yeah, whatever enablement like all the enablement materials that we already have out there. Um feel free to come by our booth, check

out our booth and also our demo. And we really like to want to get in touch with you, learn from our user stories, learn from which requirements your company might have so that we can build this open control plane project and um this universe and this ecosystem together with you. So by scanning this QR code, you can definitely um um yeah subscribe to our mailing list where

you can get an invite to our bi-weekly community calls. Um we have it like every second Wednesday where a group of our engineers um in the open source ecosystem meet where we discuss ideas where we discuss um like questions that also new joiners might might have. We have also people already here um um sitting in the room that are like also demoing some stuff um the week

and the other week. So it's really cool that we want to actually share and start even with the people that have zero experience um so that everyone can actually get started in building and extending our ecosystem. So looking really forward to seeing you there in our community calls or later at our booth and we're even here like later if you want to have a chat. So um

that's actually the last slide as I mentioned before it's a really just wanted to share our story here basically. or a very lightweight talk. Feel free to scan this QR code. We would really appreciate our your feedback basically on our talk. And with that, thank you very much for your attendance and see you