Cloud Native Computing Foundation Cloud Native DevX Day North America 2021, 30 Oct 2021

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: A Cloud Native Foundation For Developer/Application Platforms - Max Körbächer, Liquid Reply

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

A Cloud Native Foundation For Developer/Application Platforms - Max Körbächer, Liquid Reply

The rise of platform engineering is indisputable, but what does this mean? In this talk, Max will give you insights to some critical lessons learned from various projects building “platforms”. You will get an insight of how to build cloud agnostic cloud native systems that support developers in their needs to build and deliver domain specific solutions. Let's find the right plug`n`play with crossplane, backstage, Argo and buildpacks to craft the foundation for a reliable, adoptable and contribution open platform.

A

Hello, deaf ex days, welcome to my talk today about a cloud native foundation for developers and platforms.

A

My name is max garbacher, I'm from liquid reply, and I spent the past years about designing platforms, crafting platform engineering teams with various customers focusing on the application delivery, how to bring software code from the local machines or remote development environments, two kubernetes clusters, and also advise here, clients and how to utilize and actually drive a little bit through the whole cloud native environment, with its hundreds of open source tools.

A

I'm part of the kubernetes release team, basically in the evenings and nights, at least from from german perspective, and I run with my colleague christoph together a newsletter called native cloud dev, which was published weekly.

A

So you maybe have read one of these articles and they're all about the term platform engineering and what this actually means- and I think, there's at least 20 30 other articles which are going more in the depth about all these topics. So we want to talk about what does actually this platform means? And what is the engineering part in it when we are talking about platforms? And all these articles are talking about platforms?

A

It means kubernetes, most often in my opinion, it can be also other things like nomad or I don't know if mesos is still a thing or a shift or whatsoever, but overall, it is a tool which abstracts away the infrastructure.

A

As already said, application delivery is a huge part for my job, but also what is nowadays very important.

A

How do we get the code to the environments, how we can ensure a good developer feedback cycle, how you can get insights into your tool and your performance of the tool and then for us, it's very important to have an automation.

A

Automation is king, but we need to nowadays develop an automation in various kinds. A developer maybe wants to speed up faster cluster to test something. This should not take long, but it also doesn't needs to last long. On the other hand, side you have clusters, which was the same principles, needs to live very long. They need to live a longer time and then everything should be declaratively.

A

We utilize apis, throw our manifests against it, and tools taken care about to provision. What we have requested the foundation for all of this is that we basically come to a trustful, reliable infrastructure which can be utilized by development teams, but also by operational teams, to run software to run your business logic somewhere in production.

A

Now platform is a very poor terminology. There can be a lot of different kind of platforms, we're also talking about platform as a service, but well it sometimes is a little bit more than that, and at the moment one of the common trends is to actually call it an internal developer platform.

A

It should represent that the internal development team is providing code through all the mechanisms there and deploy the application and that the platform takes away all the complexity, which is behind it. Dns resolution image, registries, infrastructures and whatsoever.

A

I'm sometimes not very happy about the terminology. I think it, for example, is a little bit shortcoming in the operational perspective, but at the moment I do not know a better appropriation for it. So please feel free to give some nice wordings in the chat. If you have some so when does this idps appear?

A

Well, if you work in one of the cool, spotify's, netflix's and lifts on this planet, you most likely have something like this, but you have it because you are ik driven you're born out of ik you're, born out of automation on the software focus and because of this capabilities you build a product.

A

Now the most companies on this planet are not software companies. Surprisingly, they have other background in engineering, chemistry, banking, financial services whatsoever, so they have a really long it history and most of their time, the it is raised way more other than the most of us, but they need nowadays also idps to orchestrate all the chaos to move ahead, because the way how software was developed in the past is not applicable anymore, at least not to keep speed with. Well, all the cool young I.t hipster companies.

A

So when we're talking about an ideal idp, we need to start on like where does the platform engineering team come from and what they want to achieve?

A

I will not go too much in every detail point here. You can read it afterwards, also by yourself, but important is whom you need to support as a platform. Engineering team and on the first place is always the development team.

A

We need to reduce the the the walls, the the herds through for the for the developer, to join these platforms, having a single point of entry and to rely on it that, whatever you need, will be provisioned through the platform and you get immediate feedback to utilize. It.

A

I said also: the operations team is a very, very important piece of it and it's a little bit shortcoming in the terminology in the point of view of idps. Nevertheless, platforms needs to be also operated. This can be done by platform engineering teams, but most of the time there's someone else.

A

In addition, who runs not only the platform but also the application, so we need to bring all the good and relevant tools from the beginning into this discussion and we need to utilize what the platforms allow us to do like self-healing, restarting containers when they are filing replacing whole infrastructure switching to other data centers, if possible, security, at least for me as a from a german point of view, and is another very, very big thing.

A

We need to consider security from day one actually in reality, security is mostly applied in the end, and then it makes it more difficult.

A

I think with idps we have a chance to apply security rules very in front to do all the heavy lifting of encryption of threat detection of integration of siem and take this all the way so that you can pure focus on the main business logic of your application.

A

And we need to also support somehow the business, because somewhere we get also the money from and on the other hand, side, we need to also make transparent where the money goes to.

A

With the platform. With the integration of platforms, we can create a kind of transparency show which development, which solution maybe costs you more or less, where you have higher reliability in the software and which services are maybe more frequently requested than you actually expected.

A

So what you actually want to achieve is that from development or application point of view or something wants to call a product, your cloud platform and all your infrastructure is abstracted away. You maybe see the database entry points, something for message streaming, something for logging.

A

You need to store some of your secrets, use the difference and most of the time, you're, very well sure, on which platform you're running. You know that it's a container, maybe in kubernetes.

A

You know that you install on virtual machine and so on, but what would be even better is that you get rid of these things, which are too specific.

A

When you build your platforms right and your entry points are correct, then you can go one more step away from it and no one needs to know anymore where it is running on which platform which environment is running. Is it a oci compliant container or something else now? This is a little bit future topic in my opinion, but it's something where we are going to.

A

The only reason why we are not there is that you need to define nowadays still how the software should be deployed, and this is actually something which the people who write the software know best.

A

So about some lessons learned the little things I would call them and you maybe will be surprised, but whatever you do, it's absolutely wrong. We will focus on the past that if you go the way left- and we just said okay, everyone can build containers, it's not a problem. You can just throw to container registry.

A

Suddenly, a huge group of people appears, on the other hand, side and they're like hey. No, that doesn't work anymore for me or vice versa, and then there's the market. It is. The market is quite fast actually and well appears that you sometimes have some issues here, because actually you're developing the market develops the tools faster than you can replace them, and it's not about tools only, but also about all the ideas. All about the methodologies.

A

We need to simplify the infrastructure, but we should not have the target to explain everyone how it ex actually looks like you cannot train thousands of developers within as an organization to understand every single part of the infrastructure- and this is not interesting for everyone, for everyone who is interested is great. You can do so, but it's not necessary to understand every little piece into into the topic.

A

I said before you need to start early with security, every project where we start really late with the security um getting more and more harder. The closer you come to production, it's impossible to do so, but it's suddenly this. This well pain in the room which you have when you enter the security part.

A

When you do the other way around apply security from the beginning. It's way more easier to do so now, from a platform engineering perspective, there's a lot of complex things. You have to keep in mind.

A

This picture is actually a little bit older, but I still like to utilize it to explain to people what we all have to keep in mind.

A

But yeah well take a look on it by your own. I mean there's it's mixing topics, it's mixing responsibilities, it's all somehow connected with each other and somehow it's not connected with each other and therefore it makes it complex to develop platforms.

A

Let's look on three more interesting lesson learns, um which I took with me and which we try to explain to everyone whom we approach.

A

Kubernetes is not a hypervisor. Well, that's not something which I have learned, but it's something what I have learned that most people understand who start utilizing kubernetes they treat it as a random virtual machine as a hypervisor.

A

I try to always explain it this way. When you go and bet on kubernetes, you have actually two choices, number one. You keep developing your applications like you have done at the past years and maybe call them microservices or you go all in kubernetes.

A

You rely on the product, you rely on the platform, but it takes over for you encryption dns resolution, observability tracing traffic management security. Whatever else you want to have user management authentication authorization, all those things can be taken away, but you have to bet on the platform, and this is what the people not understand they think like. I will build my software like I have done it in the past, but I'm bringing to kubernetes, but I will not 100 utilize it because I do not want to have too much dependencies to the platform.

A

And yes, it's a point to have too much dependencies is not good, but in this case you need to see it as a whole ecosystem which comes together, and if it's done well, it's a very, very beneficial approach for yourself.

A

Also, it makes it more harder if you try to keep doing the software, like you have done in the past, without very integrating with the computers itself, because you need to invent all the time. Workarounds.

A

Cloud providers matters on a paper: all cloud providers are the same, they have more or less the same. Prices have more or less the same features and capabilities and whatsoever.

A

We implement products and projects on various cloud providers and more than just written here on hypervisors, it doesn't matter, and I can tell you one thing: every hypervisor or every every cloud provider has its own problems and you need to understand them and you need to push for that.

A

You really choose the best for your development perspective, for you for your infrastructure perspective, for your engineering point of view, rather than maybe for the best deal just because you can save a million euro on the environment, it doesn't mean that the platform is the same good as when you have something which is a bit more expensive from my experience, quality sometimes costs more, and you can see this also in some very specific places. Infrastructure as a code is crucial for platform engineering. It is most important single one of the most important things now.

A

I love crossplane, it's an awesome tool because it really fulfills all the modern needs of building platforms, but crossplane, for example, has a very poor support for azure, because the azure community also here, is not very much contributing back rather than taking a look on aws and gcp, where you have a great amount of people behind supporting it now.

A

I know that the guys are developing here and keep up with azure, but azure at the moment have a really big drive on the market, but we cannot adopt crossplane or the whole cloud native approach to provisional infrastructure, because the adoption is not so good and there are a few other issues with the technology itself of azure.

A

Lastly, there are meters about the icd back. I don't know five six seven years ago, the icd was this thing. Every company starts to implementing it and it was really helpful. The automation was great to take away jobs from from ops teams, free them up to focus on the really important things to keep the infrastructure developing and so on, but it has also some well nowadays issues. We really need to break up ci cd, it's not one single word, it's two parts: it's the integration and the delivery.

A

Modern dev tools like tilt, which you can use for cloud native development reaching from your local machine or your remote machine, where you develop up to the infrastructure where you're going to deploy and give you a fast feedback cycle about, what's going on what's going on, and that is so important for the development and you have to allow it.

A

On the other hand, side, as I said, I'm coming from a market where security is a very, very important point. So for going for a productive life cycle, we need to make their cut and setting a checkpoint, or sometimes even the breakpoint.

A

Now, in all the projects which we have done, one of the best breakpoints is the container registry, the container registry and the git repository or the chart library, wherever you want to define how to deploy your container. Why it's like that? Well, we can apply there all the security features which we need to have scan for problematic things, make a bomb like a builds of material list and check containers for bad configuration check for bad dependencies in the software and to have then still the autonomy and the flexible flexibility and reliability to deploy.

A

You need to go away from the classic cicd pipeline slots and move on to githubs, because then githubs take the certified the the ensured container, which is has a high quality and the configuration and throw it to the clusters where you need to be.

A

But not only this, so githubs is needed not only because of this breaking point which is required, but there will be also changes in the future and the way how we can deploy containers or that you will deploy containers at all, just think about the web assembly. It's something which is approaching as fast where the community is driving hard into it to make it possible to utilize representative more more often because it solves other questions around security and isolation, for example.

A

So if you set up now already a pipeline which is based on githubs, you in the future can replace very easily the part of deploying it oci compliant docker and replace it with any other kind of container format, and that's very helpful in this point of view to practice cicd up for sure. You need a unified observability to implement it on every kind of infrastructure.

A

The thing is that for every club provider you need to adjust it a little bit. You need to fine tune a little bit, because everyone does a little bit differently and you have to do it in average. I think from the cloud native report from last year, enterprise has at least 2.4 cloud provider, public cloud provider.

A

In other words, the one company has two. The other company has three cloud providers, and this is a huge amount, so you need to find an observability way which is unified for any kind of platform.

A

And this is needed to support the development teams and the diva the developer, the full insight about the traceability, the logs, the events. How does the application performs think about progressive delivery metric based shifting from workload from a to b? You need to give the insights back.

A

I think I talk enough about security. Sorry for annoying that maybe I should change the name of the talk a little bit differently, but it is the thing and start early with it.

A

So a few things which also do not work so well when we are building platforms, number one is the observability is not designed for platforms nowadays.

A

If I want to operate and manage and observe the infrastructure, I basically always observe also the containers on top of it.

A

But what I actually want to do is that the software which runs on top of it in its isolated environment, has its own stack of observing of metrics of logs, and this should be shipped somewhere else, not into new to the infrastructure itself, and it's very cost intensive and it doesn't matter in which cloud provider you want to use native tools or an additional tool, they're all very, very costly, mighty tendency.

A

Actually it's a topic which well it's getting somehow sorted out slowly, step by step, but remember containers are not secure, so the isolation isn't also, on the other hand, side. Yes, the user management is somehow sorted out, but it's complex and hard in projects.

A

I've seen user management is one of the most complex part in all of these things and there's still no very good solution which can easily sort this out and the metadata we had built a let's say: kubernetes distribution thing from telco provider, where we have so much metadata, which needs to be stored somewhere, and there were so many ideas about starting kubernetes. But like hey company, is not a database itself, it should do other things.

A

You can store it in git, but sometimes git is getting too slow. If you have too many requests doesn't matter which gitlab github and then you came up with an own solution, but this is also not perfect.

A

So these three things are not that very well done in my opinion yet, but I think also, on the other hand, side, this platform topic is still quite new and young on the market.

A

So to finish this talk, there are a few key metrics which we keep in mind when we build platforms, and the first one is that the number of scripts you need to provision and maintain your infrastructure is the same or shows how inflexible you are the more scripts. You have the more dependencies you create between tools and that's, not good, and this leads directly to point two, the more components with interdependencies you have, the less. You can use your platform in the future.

A

I said the market has developed too fast. You need to. You will have to replace tools in the future.

A

If you do not build your platform for changing the some of the parts, then you have to rebuild the platform again, and this is the major issue the most of the enterprises needs to do over and over and over again rebuilding platforms, and, last but not least, my favorite one, and also actually from one of my product owners, which had gotten a product in a project back as a feedback.

A

If the handbook for the developers is too complex, it means that the platform is worse and that actually it's less likely to be used. Developer focus ends where your documentation starts and if the documentation is too complex. Well, you have a problem.

A

Thank you very much. I hope you could enjoy it and have a great day.