Copilot is now your window into the world of agents, with new capabilities that lay the foundation for this next phase.

The post Microsoft 365 Copilot: Built for the era of human–agent collaboration appeared first on Microsoft 365 Blog.

Nina Polshakova is a software engineer at Solo.io, where she’s worked on Istio and API Gateway projects. She’s been part of the Kubernetes release team since v1.27 and is currently serving as the Release Lead for v1.33.

Do you have something cool to share? Some questions? Let us know:

- web: kubernetespodcast.com

- mail: kubernetespodcast@google.com

- twitter: @kubernetespod

- bluesky: @kubernetespodcast.com

News of the week

• 229 new things Google announced at Next 25

• MCO: Multi-Cluster Orchestrator

• Golden Kubestronaut

• Cloud Native Platform Engineering Associate

• The kube-scheduler-simulator

• K0s and k0smotron are now CNCF Sandbox projects

Links from the interview

• Nina Polshakova

• Kubernetes Deprecation Policy

• Kubernetes Dev Google Group

• solo.io

• Istio

• API Gateway (General concept, linking to K8s Gateway API)

• Kubernetes Release Team

• GitHub

• Istio revisions

• Working in Public by Nadia Eghbal (Link to publisher's site about the book)

• Kubernetes Maintainers Read Mean Comments (KubeCon EU 2024)

• Kubernetes 1.33 release blog (Link to release announcement blog)

• Kubernetes Enhancement Proposals (KEPs)

• Sidecar Containers

• Multiple Service CIDR support (KEP link)

• Dynamic Resource Allocation (DRA)

• DRA support for partitioned devices (KEP link)

• DRA device taints and tolerations (KEP link)

• DRA: Prioritized Alternatives in Device Requests (KEP link)

• Kubernetes 1.33 sneak peak (Link to pre-release highlights)

• EndpointSlices API

• Kubernetes Gateway API

• node.status.nodeInfo.kubeProxyVersion is a lie (issue)

• KEP-4004: Deprecate the kubeProxyVersion field of v1.Node #4005 (KEP link)

• Kubelet

• Removal: Host network support for Windows pods (KEP link)

• Containerd

• SIG Windows

• HostProcess Containers (Windows)

• Removal: KEP-5040: Disable git_repo volume driver (KEP link)

• User Namespaces (Beta, Enabled by Default)

• CRI-O

• Runc

• In-place Resource Resize for Pods (Link to the alpha announcement, but now beta)

• Vertical Pod Autoscaler (VPA)

• KEP-5080: Ordered Namespace Deletion

• PyTorch

• Linkerd

• Terry Pratchett's Discworld series

• Tiffany Aching series

• Guards! Guards!

• Going Postal

• Kubernetes Slack

• New Contributor Orientation

Guests:

• No guests [Tim in Vegas and Anton remote]

Topics:

• So, another Next is done. Beyond the usual Vegas chaos, what was the overarching security theme or vibe you [Tim] felt dominated the conference this year?
• Thinking back to Next '24, what felt genuinely different this year versus just the next iteration of last year's trends?
• Last year, we pondered the 'Cloud Island' vs. 'Cloud Peninsula'. Based on Next 2025, is cloud security becoming more integrated with general cyber security, or is it still its own distinct domain?
• What wider trends did you observe, perhaps from the expo floor buzz or partner announcements, that security folks should be aware of?
• What was the biggest surprise for you at Next 2025? Something you absolutely didn't see coming?
• Putting on your prediction hats (however reluctantly): based on Next 2025, what do you foresee as the major cloud security focus or challenge for the industry in the next 12 months?
• If a busy podcast listener listening could only take one key message or action item away from everything announced and discussed at Next 2025, what should it be?

Resources:

• EP169 Google Cloud Next 2024 Recap: Is Cloud an Island, So Much AI, Bots in SecOps

Our next major update (v25.1) is set for release in early June. In this post, I'll summarize some of the features/capabilities available in our early access (EAP) build. Before I begin — a quick reminder: If you are an active Universal or DXperience subscriber and want to explore upcoming v25.1-related features/capabilities before official release, you can download our EAP build via the DevExpress Download Manager. Should you encounter issues with the EAP build, please submit a support ticket using the DevExpress Support Center.

Legacy Data Grid, ComboBox, Tag Box, and List Box are No Longer Available

To streamline our distribution, we have removed the following legacy components from our v25.1 update:

• DxDataGrid
• DxComboBoxLegacy
• DxTagBoxLegacy
• DxListBoxLegacy

To avoid issues, please check your projects for components from the  DevExpress.Blazor.Legacy namespace and migrate to new DevExpress alternatives.

Helpful resources:

• Migrate from Data Grid to Grid
• Legacy component deprecation details

If you are still using older versions of DevExpress Blazor components, please contact us via the DevExpress Support Center and let us know how we can help you migrate to newer alternatives. 

Blazor Editors

Blazor ComboBox — Set Data Load Mode 

The DevExpress Blazor ComboBox allows you to manage data source interactions using DataLoadMode. Since v24.1, our Blazor ComboBox caches data to reduce frequent database requests. You can now set DataLoadMode to OnDemand (similar to behaviors available prior to v24.1). This option allows the ComboBox to fetch data from the data source each time the dropdown activates. When this option is used, our Blazor ComboBox does not preload data when the page loads (improving initial page load speed. 

Blazor List Box — Select All

The DevExpress Blazor List Box allows you to display a Select All check box above list box items. 

To explore the capabilities of the EAP version of the DevExpress Blazor List Box control, open our locally installed Blazor demo: ListBox   → Multiple Selection .

App Showcase Demo

New CRM, Analytics, and Scheduling/Planning modules (built with our Blazor Grid, TreeList, Scheduler, ListBox, ComboBox, Charts, and other DevExpress Blazor components).

Our showcase demo utilizes InteractiveAuto render mode, introduced in .NET 8 — starting with Blazor Server for fast initial load and seamlessly transitioning to WebAssembly (WASM) for optimal speed and responsiveness. 

The application uses our new Fluent theme with light/dark mode support. Each module is built with reusable code, so you can easily adapt/integrate module components into your next DevExpress-powered Blazor project. 

To explore the capabilities of the demo, open our locally installed showcase demo: DevExpress Demos 25.1\Components\Blazor\BlazorDemo.Showcase or visit https://demos.devexpress.com/blazor-showcase/ 

Blazor Pivot Table

Filter Data

The DevExpress Blazor Pivot Table allows you to apply filters to fields displayed in the Filter Header Area. You can define these filter fields in component markup or drag them from other Pivot Table areas. Use the  FilterHeaderAreaDisplayMode  property to control Filter Header Area visibility.

Filter field headers display filter menu buttons. Users can press these buttons to open Field Filter Menus. You can use the following properties to control filter menu button visibility:

• DxPivotTable.FilterMenuButtonDisplayMode  - Specifies whether a filter menu button is visible for all filter field headers.
• DxPivotTableField.FilterMenuButtonDisplayMode  - Specifies whether a filter menu button is visible for a specific field.

The Field Filter Menu displays a drop-down window with all unique values of the field. Users can select/deselect these values to filter Pivot Table data.

You can use the following APIs to customize the filter menu as requirements dictate:

• The  CustomizeFilterMenu event fires before the drop-down filter is displayed and allows you to customize filter items.
• The  FilterMenuTemplate property specifies the template used for the content displayed within the field's drop-down filter.
• The  FieldFilterMenuTemplate property specifies the template used for all drop-down filter menus in the Pivot Table.

In addition to the UI-based filtering options, the DevExpress Blazor Pivot Table  allows you to filter data in code.  To apply filter criteria, create a  criteria operator  object that specifies a filter expression and send this object to the  SetFilterCriteria  method.

To explore the capabilities of the EAP version of the DevExpress Blazor Pivot Table control, open our locally installed Blazor demo:  Pivot Table  → Filter Data.

Blazor Grid & TreeList

PDF Export

• Column order, captions, and alignment
• Value format and alignment
• Group rows, group summaries, and group totals
• Total summaries

Keyboard Support Enhancements

• Filter Row: Users can now enter a new filter value even if a cell editor is inactive (no need to press Enter first).
• Cell Editing: If the EditOnKeyPress property is enabled, users can begin typing to open an editor for a focused cell.

Blazor Context Menu

Performance Enhancements

We optimized our Blazor Context Menu's rendering logic to reduce the number of messages sent between the server and client. Depending on connection quality and the number of items, DevExpress Context Menus now open 20-50% faster when used in Blazor Server applications.

Blazor Rich Text Editor

Zoom Operations

With v25.1, the DevExpress Blazor Rich Text Editor allows you to zoom in/out of documents with ease (via the UI and in code). Users can modify document zoom level using a drop-down menu within the View Ribbon tab. Available levels range from 50%  to 200% . Disable the AllowZoom property to hide the drop-down zoom level menu.  Irrespective of the  AllowZoom  property value, you can use the ZoomLevel   property to zoom a document at runtime.

To explore the capabilities of the EAP version of the DevExpress Blazor RichEdit control, open the following locally installed Blazor demo: Rich Text Editor → Overview .

Blazor Scheduler

Toolbar Customization

• Today button
• Next and Previous buttons
• Date navigator
• Resource navigator
• Scheduler View selector

• Position and alignment of toolbar items.
• Enabled, Visible, Tooltip, and Render Style properties.

      <DxScheduler ...>
    <ToolbarItems>
        <DxSchedulerPreviousIntervalToolbarItem />
        <DxSchedulerNextIntervalToolbarItem />
        <DxSchedulerTodayToolbarItem />
        <DxSchedulerDateNavigatorToolbarItem />
        <DxToolbarItem GroupName="ScaleDuration"
                       Text="1 day"
                       Click="@((i) => CurrentDuration = TimeSpan.FromHours(24))"
                       Checked="@(CurrentDuration == TimeSpan.FromHours(24))"
                       BeginGroup="true"
                       Alignment="ToolbarItemAlignment.Right"></DxToolbarItem>
        <DxToolbarItem GroupName="ScaleDuration"
                       Text="2 days"
                       Click="@((i) => CurrentDuration = TimeSpan.FromHours(48))"
                       Checked="@(CurrentDuration == TimeSpan.FromHours(48))"></DxToolbarItem>
        <DxToolbarItem GroupName="ScaleDuration"
                       Text="3 days"
                       Click="@((i) => CurrentDuration = TimeSpan.FromHours(72))"
                       Checked="@(CurrentDuration == TimeSpan.FromHours(72))"></DxToolbarItem>
    </ToolbarItems>
</DxScheduler>

To explore the capabilities of the EAP version of the DevExpress Blazor Scheduler control, open the following locally installed Blazor demo: Scheduler  → Customization  → Custom Toolbar Items .

Appointment Form Resize and Drag Operations

You can now drag and resize our Extended Appointment Form (it is now easier to view the entirety of a calendar without discarding changes).

Performance Enhancements

We enhanced performance for the following operations/usage scenarios:

• Time needed to open Date Navigator and Resource Navigator popups
• Appointment dragging
• Time needed to open an appointment’s tooltip and compact/extended form
• Creating, updating, and deleting appointments

UI/UX Enhancements

• Icons used for the Today button and each view selector (Day, Work Week, Month, Timeline).
• A dropdown button for the view selector. In previous versions, we used a button group to select view type. With our new dropdown button, the UI requires less space, improving the user experience and allowing you to add additional custom items to the toolbar.
• A new render style mode for built-in toolbar items. We changed the render style mode to Plain. 
• New appointment label colors in the Fluent theme. We updated default label colors, replacing bright colors with a pastel palette. This modification was designed to improve visual clarity and reduces eye strain. 
• New status styles for the Fluent theme. Appointment statuses now use styles similar to those of Microsoft Outlook.

Blazor Charts

Zoom-related APIs

• ZoomChanged event - triggers whenever a zoom or pan operation is performed.
• ResetVisualRange method - restores the maximum possible visual range.
• SetArgumentAxisVisualRange method - applies a specific visual range to the argument axis.

Series Label API Enhancements 

v25.1 includes an expanded the list of series label options. DxChartSeriesLabel  supports the following pie series label-related properties:

• TextOverflow and  WordWrap - specifies how the Pie Chart displays text for overflowing labels.
• RadialOffset - shifts pie series labels radially away from or towards the center of a chart.

Legend Click Events

v25.1 ships with DxChart.LegendClick, DxPolarChart.LegendClick, and DxPieChart.LegendClick events. Handle these events to execute custom logic when users click legend items.

Your Feedback Counts

If you have a specific question about our Blazor EAP (v25.1), feel free to submit a support ticket via the DevExpress Support Center. We will be happy to follow-up. 

For additional information on what you can expect from our mid-year release, please refer to our June 2025 Roadmap.

Intro

Over the past year or so we’ve built out a decent-sized test lab environment for Akka.NET and I’ve also personally started a small homelab environment for creating some useful services for my family’s use. Both of these networks use the same components:

• Tailscale for secure networking and ssh access;
• docker compose for running infrastructure services such as databases or observability tools; and
• In our corporate environment we use Kubernetes for running our application workloads; typically, we use GitHub Actions and a self-hosted Docker registry inside our VPN for continuously deploying these.

However, I ran into the same issue with my homelab and my corporate network this week: I needed to be able to continuously deploy a docker compose application onto just one of my machines. For our work use-case; it’s because we’re conducting a pretty big beefy load test and I need control over which node is going to be hosting the “victim” process that’s going to get blasted by everyone else¹.

In this article I’m going to show, briefly, how to use GitHub Actions and Tailscale to continuously deploy docker compose applications.

Workflow

Here’s what I want to be able to do with these tools:

sequenceDiagram
    participant Dev as Developer
    participant CI as CI/CD Pipeline
    participant Reg as Private Registry
    participant Host as Docker Compose Host

    Dev->>CI: Modify application / push changes
    CI->>CI: Build new application image
    CI->>Reg: Publish image to private registry
    CI->>Host: Trigger Docker Compose update
    Host->>Reg: Pull latest image
    Host->>Host: Update services to latest version

Pushing new images to a private container registry is relatively easy to do. The real key is automating the docker compose update. With Kubernetes we can easily do this via a kubectl command or by pushing a new Helm chart. How do we get docker compose to behave similarly?

Why Tailscale?

I have a confession to make: I love Tailscale. If you’re not familiar with it: Tailscale a lightweight networking tool built on top of the WireGuard to make it very, very, very easy to create your own virtual private networks for both personal and professional use. We call these a “tailnet” - short for “Tailscale network.”

I use a free Tailscale account for my personal homelab and I purchased a Tailscale Starter plan for our small team at Petabridge. It’s great - we use the Tailscale Kubernetes operator inside our two K8s clusters (ARM and x64) and for my personal use, I’ve even developed a Pulumi application that lets me create Tailscale exit nodes on Digital Ocean micro-VMs when I’m traveling abroad: https://github.com/Aaronontheweb/tailscale-pulumi

So why is Tailscale relevant in the context of deploying applications via docker compose? For the following reasons:

1. We’re going to use Tailscale SSH - this allows me to connect to any of my Tailscale servers via ssh without having to pass authentication keys around. Tailscale’s Access Control List (ACL) does the securing for us.
2. All of our servers run on private DNS / IP addresses with none of their ports exposed publicly - Tailscale’s VPN functions as an overlay network and makes these addresses resolvable via the Tailscale daemon running on each of the target services.
3. We’re going to pass in a Tailscale OAuth client id and secret - this is what will allow Tailscale to spin up an ephemeral device inside GitHub Actions that it can use to connect to my private tailnet.

If you want to do all of this without Tailscale - you can do this with regular, old ssh keys and public ports instead. Please see Sebastian Scheibe’s: “Automated Docker Compose Deployment with GitHub Actions” to see how to do this. His post is where I got the idea to do this with Tailscale.

GitHub Actions

Putting everything together, we need to:

1. Login to our tailnet;
2. Build and push our docker images; and
3. Make sure the latest docker image tag gets pushed into our docker compose application.

Here’s the full GitHub Actions file I used for this:

Let’s break this down into its component parts.

docker-compose.yml and .env Files

Our project is structured accordingly:

.                                                                                                                   
├── Directory.Build.props                                                                                           
├── Directory.Packages.props                                                                                        
├── NuGet.Config                                                                                                    
├── README.md                                                                                                       
├── RELEASE_NOTES.md                                                                                                
├── StannardLabs.slnx                                                                                               
├── build.ps1                                                                                                       
├── coverlet.runsettings                                                                                            
├── docker                                                                                                          
│             └── docker-compose.yaml                    
│             ├── .env                                                                     
├── global.json                                                                                                     
├── scripts                                                                                                         
│             ├── bumpVersion.ps1                                                                                             
│             └── getReleaseNotes.ps1                                                                                         
└── src                                                                                                             
    └── Site                                                                                                        
        ├── ...

For CI/CD purposes, only the ./docker folder is of interest to us - the rest of the projects’ contents are all for publishing the docker images.

Here’s what our docker-compose.yaml looks like:

services:
  stannardlabs-site:
    image: docker.homelab.stannardlabs.com/stannardlabs-site:${DOCKER_TAG}
    restart: unless-stopped
    env_file:
      - .env
    environment:
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://collector:4317
      - OTEL_RESOURCE_ATTRIBUTES=service.namespace=stannardlabs-site,service.instance.id=site-1
      - OTEL_SERVICE_NAME=stannardlabs
    ports:
      - "9982:8080" #default ASP.NET Core port

And here’s our .env file:

DOCKER_TAG=1.0.1

The key details here:

• ${DOCKER_TAG} - this is going to pull the DOCKER_TAG environment variable from one of the env_file sources we specified.
• .env - this is the file that sets the DOCKER_TAG value. This is what we’re going to update during deployments.

Logging into Our Tailnet

The first step is to login to our Tailnet - we’re going to do this using tailscale/github-action@v3 and using Tailscale OAuth credentials saved as GitHub Actions Secrets.

Tailscale Auth and ACL

Now, one very crucial detail: the Tailscale tag we automatically apply to all of the ephemeral devices created using this OAuth client id:

We are tagging all of our GitHub Actions clients with the tag:ci. This is important because the way we’ve defined our Tailscale ACL file, tag:ci devices have the ability to ssh into tag:server resources:

{
// rest of policy file....
"tagOwners": {
		"tag:server": [
			"autogroup:admin",
		],
		"tag:router": [
			"autogroup:admin",
		],
		"tag:ci": [
			"autogroup:admin",
		],
	},
	"ssh": [
		// Allow all users to SSH into their own devices in check mode.
		// Comment this section out if you want to define specific restrictions.
		{
			"action": "check",
			"src":    ["autogroup:member"],
			"dst":    ["autogroup:self"],
			"users":  ["autogroup:nonroot", "root"],
		},
		{
			"action": "accept",
			"src":    ["autogroup:admin", "tag:ci"],
			"dst":    ["tag:server"],
			"users":  ["root"],
		},
	],
}

Otherwise, ssh access will be denied even if we successfully connect to our tailnet.

Worth noting: the default Tailscale permissions are fairly broad, so you probably won’t even run into this issue on a new account. I run my tailnet with more restrictive permissions by default, as do many other production users, so your mileage may vary.

Building and Publishing Docker Images

This part is specific to your application. In our applications we typically use the .NET SDK’s built-in container publishing support and we use the build.ps1 script to parse the container image version, which matches the from a RELEASE_NOTES.md file².

When we invoke the following:

dotnet publish -p:ContainerRegistry={your container registry uri} -c Release -t:PublishContainer

That’s going to build and publish this image using the git tag we’ve pushed as the version number to our registry.

Now it’s worth noting: our Docker registry is part of our tailnet! That’s why we’re not doing a separate docker login step first. We don’t require authentication on our registry because it’s inaccessible outside our network. The Tailscale login takes care of that for us.

Updating docker compose

So after we login to Tailscale and push our Docker image to the registry, it’s time for the final step: getting docker compose to use it.

Thus, we do the following via ssh and scp:

# Copies the docker-compose file first, then updates the .env file that sets the image version
- name: Deploy to server
  run: |
    scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ./docker/docker-compose.yaml ${ vars.SSH_USER_NAME }@${ vars.TARGET_NODE }:${ vars.SSH_TARGET_DIRECTORY }
    ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null $@$ << 'EOF'                         
      cd ${ vars.SSH_TARGET_DIRECTORY }
      sed -i 's/^DOCKER_TAG=.*/DOCKER_TAG=$/' .env
      docker compose up -d
    EOF

We disable StrictHostKeyChecking and the UserKnownHostsFile to avoid any sort of interactive prompts where we might get asked about accepting keys and blah blah. That’s the first step.

Second step: our docker-compose.yaml file has to live in a stable target directory on the target machine. I usually pick something inside the SSH_USER_NAME’s folder but you could use a shared volume if the user has access to that.

This value, SSH_TARGET_DIRECTORY, is defined as a GitHub Actions variable:

Next, we copy the docker-compose.yaml file over. You don’t have to explicitly do this - you could just copy the file over manually beforehand. But the reason why I do this is because if I change the content of the docker-compose.yaml file, why not deploy that too while we’re at it?

And then finally, we use sed to inject our new DOCKER_TAG value into the .env file and then tell docker compose up -d to pull the new image and relaunch it.

Running It

Once you put this all together, you now have a continuous deployment pipeline for docker compose!

Let’s see what it looks like in action:

Boom! It works.

Today’s my Monday after spending the first two days of this week in Texas visiting my son’s future college. Great trip. Now digging out from a couple of days of email and unread blog posts. Expect some big reading lists this week!

[blog] YouTube is turning 20! “Unbox” some of the latest features to celebrate. Happy birthday to this platform that has positively impacted so many people.

[article] The many fallacies of ‘AI won’t take your job, but someone using AI will’. Oof, I’ve used that line. I won’t any more. This article explores why that’s a false framing.

[article] Tutorial: GPU-Accelerated Serverless Inference With Google Cloud Run. Simple, yet powerful example of what you can do with a modern app platform.

[article] Devs and DBAs can’t find peace, but could they call a truce? At my last few companies, we didn’t have dedicated DBAs so I’m farther removed from the current state of this tension.

[blog] How to think about agent frameworks. The gloves are off! LangChain folks took umbrage at OpenAI’s guidance for building agents and published a terrific piece on agentic systems and agent frameworks.

[blog] Firebase Studio + Google Agent Development Kit (ADK) — build multi-agent apps from web IDE. Cloud-based dev environments make it simpler to try out and iterate on fast-moving agentic apps.

[blog] Microservices to Monolith. Monolithic apps are cool again after microservices fatigue, but Derek has a provocative question to consider.

[paper] Creating benchmarkable components to measure the quality of AI-enhanced developer tools. There’s no shortage of benchmarks for AI models. Less so for products built with generative AI. This paper explores an approach to fixing that.

[blog] SaaS delivery made easy: Meet SaaS Runtime. Designing, deploying, and operating multi-tenant solutions is no joke. Make the wrong choice and you’ve got a management nightmare. This new managed offering looks like a nice way to reduce risk.

[blog] Google Cloud Next 2025’s Developer Keynote: Agents Take Center Stage. Devin’s a good analyst, and I’m not just saying that because he wrote about our dev keynote.

[blog] CI/CD Security Best Practices. I’d venture that most aren’t probably GREAT at securing their automated deployment pipelines, so advice like this is still helpful.

[blog] Spring Cloud Data Flow End of Open-Source. It’s interesting to see one project in an OSS ecosystem suddenly go commercial and closed source.

[article] Why CIOs should prioritize IT modernization. I don’t see how you have any chance to succeed with technology over the next decade if you don’t have some modern fundamentals in place.

[blog] Google Cloud Database and LangChain integrations now support Go, Java, and JavaScript. AI apps aren’t just for Python devs. You’re seeing frameworks increase their support for other languages.

Want to get this update sent to you every day? Subscribe to my RSS feed or subscribe via email below: