Links tagged 'platformengineering'

Practical discussion of the social and technical challenges of getting an internal developer platform up and running.

Tyler is arguing for going "k8sless", but by using Knative and/or Cloud Run, it's just someone else's Kubernetes. Still, as an abstraction level, Knative is great.

Many of these businesses, for better or worse, treat software development as an IT cost center to be managed. They don’t need — or for that matter, want — the costs and overheads associated with platform-izing Kubernetes

And really, "just use Cloud Run" is great advice to someone building a suite of services.

"Get something finished" (Kelsey Hightower) is a great takeaway from this.

Also "you have no choice... this is not debatable... that's just what it costs to be in the software business... if you're company writes software, then they are now immediately in the platform engineering business."

"...stop doing meetings and sprint planning and all of this devoppy stuff... what people do is, they try to meet their way out of this... start small, get the prototype out the door..."

Without prototyping, "that's not engineering, that's guessing"

[19:52] how to get responsibility and support for fixing the problem

The wide adoption of cloud-native and microservice-based applications to connect applications, data, and devices across the enterprise has led to an exponential growth in APIs. But as the API ecosystem grows, so does the risk of exposing sensitive data. APIs get directly to critical and sensitive data, making them a valuable target for hackers. How can you ensure your APIs are protected from malicious attacks and unauthorized access?

Join Inon Shkedy, Head of Security Research at Traceable AI and co-author of the OWASP API Top 10 Project, as he takes a closer look at the largest, most common API vulnerabilities. In this session, Inon will cover: 1. The most prevalent code flaws in API security 2. How hackers target these flaws 3. How you can protect your organizations APIs and applications

Pretty negative, overall. If you want to hone your skills at writing attention-getting rants, it's worth a study but there's not much in the way of proposals for what to do next.

However Platform Engineering is not a magical solution to the problem. It is instead another fabrication of an industry desperate to show monthly growth in cloud providers who know teams lack the expertise to create the kinds of tooling described by such practices. In reality organizations need to be more brutally honest about what they actually need vs what bullshit they've been led to believe they need.

This seems a lot like Blaze/Bazel:

Score is an open-source, platform-agnostic, container-based workload specification. With Score, you can define your workload once using the Score Specification and then use a Score Implementation CLI to translate it to multiple platforms such as Helm, Docker Compose, Google Cloud Run. Humanitec is an active contributor to the Score project and the Platform Orchestrator offers native support for Score, allowing for a seamless integration between the two.

Building an Internal Developer Platform (IDP) - where to start?

Especially at the enterprise scale I see a lot of tech leaders trying to get an overview of all the existing services across teams, therefore thinking a service catalog is the best place to start to gain more transparency.

The problem is this usually leads to platform teams building something in isolation (e.g. spend a year or more trying to implement a service catalog) and eventually pushing an extremely UI-heavy platform onto developers. This fails every single time.

While it might be a good idea to provide developers with their own dedicated portal to unify developer experience, a UI by itself doesn’t actually improve your delivery setup and just doesn’t deliver much value to your org, if any at all.

Kubernetes networking can be intimidating for platform engineers, but with the right knowledge, it can become a powerful tool. Understanding the various layers of Kubernetes networking is essential for optimizing platform engineering efforts.

In this webinar, Raphael will guide you through the complexities of Kubernetes networking, turning potential challenges into valuable opportunities. By the end of the session, you'll have a clearer understanding of how these networking layers can significantly enhance your platform engineering skills.

During this talk Raphaël will cover:

What can go wrong if Kubernetes Networking isn’t top of your mind

Different Kubernetes Networking layers (CNI, kube-proxy, and service mesh) and their role in platform engineering

Best practises in Kubernetes networking for in-cluster, integrating the cluster within its environment, external load balancing or on-premise infrastructures

Every Internal Developer Platform (IDP) needs a proper backend, and it’s vital to start by designing and building that before you worry about anything else. Join this session and learn more how to design your platform backend right, explore which options you have and how to mitigate the frontend trap aka starting with a portal.

Too many organizations get started on their platform engineering journey the wrong way around. Simply slapping a portal on top of your existing setup does NOT mean you are doing platform engineering (nor frankly solving any real issues for that matter). In this webinar we’ll have a closer look at the backends of your Internal Developer Platform (IDP) and its crucial role to drive automation, standardization and developer self-service. We will dive into:

Why every IDP needs a backend Which options you have: pipeline based backends (CI/CD + IaC) vs. graph based backends (Platform Orchestrators) How enterprises use orchestration to standardize and automate their config setup

As we navigate the evolving landscape of API management, it's crucial to harness tools that not only meet current demands but are also scalable for future needs. During this session we will explore how Kong elevates the robust foundation provided by our Open Source Gateway, and offers enhanced management capabilities, seamless automation, and superior analytics all within a unified platform.

Discover how transitioning to Kong Konnect Platform can simplify your operations, provide advanced security features, and offer insights that drive your digital strategy forward. Join us as we unveil the path to optimised API management, tailored for modern enterprises.

At this webinar you will discover how Kong Konnect can empower your organization to navigate the complexities of modern service connectivity and take a leap forward in operational excellence and innovation.

A platform for cloud-native computing is an integrated collection of capabilities defined and presented according to the needs of the platform’s users.

...platform teams should include product managers from the start to share roadmaps, gather feedback and generally understand and represent the needs of platform users.

Ways to reduce load on the platform team include the following: 1. Seek to build the thinnest viable platform layer over implementations from managed providers 2. Leverage open source frameworks and toolkits for creating docs, templates and compositions for application team use 3. Ensure platform teams are staffed appropriately for their domain and number of customers

From Wix... This is valuable because it describes a concrete effort to build a platform for an organization.

As systems become larger and more complex we need to take the concepts of platform engineering to a higher level – to the code level – by creating platforms and abstractions that will reduce cognitive load, help simplify and accelerate software development, and allow for easy maintenance and upgrades to the platform.

An important lesson we learned is that we needed the platform team to be in the right mindset. We had to have a Value-Driven platform team. While this can be its own topic, I would mention one thing we discovered: the most crucial KPI for the platform team is "developer adoption". If developers aren't using your platform, it might not be delivering real or enough value. This kind of thinking was crucial to the team, collaboration with product developers is very helpful in the adoption of the platform since product developers are always involved in defining the platform features, and capabilities and setting requirements that actually solve their real problems.

For Spotify, speeding up feature development and deployment all comes down to templates and pipelines.

The release cycle is almost completely automated. “The only people left in the process are developers,” said Tim Hansen, senior engineer, working on Backstage, at music-sharing service Spotify, speaking at this week’s PlatformCon 2024 virtual conference. “This allows us to release continuously release thousands of microservices, many times a day.”

The recipe comes from GitOps, an implementation of infrastructure as code (IaC). With GitOps, system configuration information, usually stored in YAML or as flat text files, is kept in a source code repository, most often git or git-base code-hosting service, where it then can be called by a provisioning tool for deployment.

An agent then continually compares the “desired state,” as outlined in the configuration files, with the actual running state, and applies any changes needed to synchronize the two.

“By having everything declarative in code, and having standard technology stacks, [the developer] basically gets infrastructure for free,” he said. “And if you need to make modifications, it’s easy.”

Covering the launch of the Platform Engineering Maturity model.

Platform Engineering Maturity Model. The maturity model is a tool to help organizations reflect on their current state of platform engineering adoption and quickly determine good opportunities to mature their practices and further impact their business. The model reduces the cognitive load involved in determining how to build successful platforms and platform teams.

The model proposes four levels of platform maturity:

• L1. Provisional
• L2. Operational
• L3. Scalable
• L4. Optimizing