The first few episodes of my .NET 5 REST API tutorial are available now:
- 01 Getting Started
- 02 Entity, Repository, Controller (GET)
- 03 Dependency Injection, DTOs
- 04 POST, PUT, DELETE
- 05 Persisting entities with MongoDB
Just published a video with my take on a few of the .NET 5 features that I find useful for microservices development:
A common problem I have seen across the teams I’ve worked on that use Azure Pipelines for building and releasing code is the lack of enough pipeline agents to handle the increasing number of builds/releases that need to be executed simultaneously. Most teams would start by just using Microsoft-hosted agents, which is super straightforward, no setup required. However they come with a few downsides:
To overcome those issues you would usually come up with your own self-hosted agents where there is no limit on parallel jobs and you can decide what vm size to use and what software to put there. But then this comes with its own downsides:
One way to find a middle ground among all these issues is to turn the agents into docker containers and then have Kubernetes orchestrate the provisioning of those containers. Yes, you still have to stand up and maintain a k8s cluster but then you get a bunch of benefits:
A bunch of people have come to this conclusion already, so when I found this open source project a while ago I gave it a try and worked pretty well. However since then the Azure DevOps team stopped supporting the docker image used in that project and you are now expected to come up with your own docker image. Plus the old VSTS went into a few changes. Therefore I forked the project and updated a few things to match the latest guidelines and added some more guidance on how to create the docker image and the kubernetes cluster.
To get started you can go to my azure-pipelines-kubernetes-agents GitHub repo and follow the steps described there. Here I’ll just summarize what you’ll end up doing to quickly come up with your own k8s hosted Azure Pipelines agents:
So, for instance, once you have the pipelines pool and the k8s cluster created as well as the docker image published, this is all I did to provision my pipelines agents:
helm install --set image.repository=julioc/azpagent --set image.tag=ubuntu-16.04 --set azpToken=[your token here] --set azpUrl=https://dev.azure.com/julioc --set azpPool=MyPool -f helm-chart\azp-agent\values.yaml azp-agent helm-chart\azp-agent
Which in the pool management page looks like this:
And then I was able to start running pipelines in those agents right away:
And if I need to scale up to say 10 pipeline agents I could just do this:
kubectl scale statefulset/azp-agent --replicas 10
Which after a few mins (depending on your node vm size) looks like this in the pool management page:
So check it out and let me know if you have any comments or questions.
From time to time I get approached by an overwhelming amount of recruiters for several software engineering positions for locations across the US and a few of them remote too. This is probably not unusual for folks working in software engineering, especially if you work on cloud tech. Some of these positions are actually really interesting. Looks like HBO keeps growing in the Seattle area with the upcoming HBO Max service starting in spring of 2020, Amazon expanding into Cupertino, CA, Mexico City and Vancouver, B.C, and Volkswagen coming up with it’s own Automotive Cloud in Redmond, WA.
However since I’m not interested in switching jobs these days (having some good fun at the Microsoft Project xCloud team) and I keep just replying with a “not interested” to all these recruiters, I thought I might as well share these opportunities here so others get to know about them.
You can check out the new jobs section here and if you are interested feel free to drop me an email or comment on this post with your updated LinkedIn profile so I can pass it over.
When software developers start collaborating in a project one of the main things to address is how to prevent build and test breaks. Here is where Continuous Integration (CI) shines and one tool that enables it and that has worked for me fairly well in the past is Azure Pipelines.
I just published a tutorial on how to enable CI with Azure Pipelines:
The tutorial will teach you:
To close on the Asp.Net Core 3.0 Web API series I just published a video on how to build a CI/CD pipeline to fully automate the deployment of a Web API docker container to AKS. Here it is:
In this one you will learn:
I hope this series has been useful and, as always, please leave me a comment here or in the video with any feedback, which is highly appreciated.
Last week I published a video on how to deploy an Asp.Net Core 3.0 Web API to a local Kubernetes cluster. This week I thought I would move one step forward and show how to deploy the same Web API container to Azure Kubernetes Service (AKS). So here you go:
In this new video you will learn:
Please leave me a comment here or in the video itself about any feedback you might have on this video.
As a follow up from last week’s video on Containerizing an ASP.NET Core 3.0 Web API here for a step by step on how to deploy an Asp.Net Core 3.0 Web API on a local Kubernetes cluster:
In this new video you will learn:
Again, please let me know your thoughts on this video, either here or in the video comments section. All feedback is very appreciated.
More videos coming soon!
It’s been ages since I wrote anything here, but recently I decided it’s time I start sharing a few of the things I have learned in the past few years. Also, since .NET Core 3.0 just got released today and since I’ve been working with containers for a while I thought it would be appropriate to start with a video on how to containerize an Asp.Net Core 3.0 app, specifically a Web API type of app since that’s what I’ve mostly been using for building microservices. So here it is:
There I talk about:
• How to create an Asp.Net Core 3.0 Web API project
• How to add Docker artifacts with Visual Studio Code, including the generation of the Dockerfile
• How to build and run the Asp.Net Core project as a Docker container
Let me know your thoughts on this video, either here or in the video comments section. Would appreciate all feedback to incorporate it in future upcoming videos.
Just about a week ago it seemed like the most popular of my apps was my Desktop Translator, which was a Silverlight Out Of Browser (OOB) app. However, since Silverlight does not seem to play very well with Edge, the default browser in Windows 10, people was struggling with installing the app. At that point I also had a Translator for Windows 8 and a Translator for Windows Phone 8. So, it seemed like a good opportunity to try out the Windows Universal platform and make my life easier along the way.
And here is the result:
Get it now for Windows 10 here (and probably with the same link for Windows Phone 10 when it becomes available).
I didn’t quite have time to add new features to this universal version of the Translator. However I did add the capability for translating the text as you type it. I thought that could be handy.
Besides the fact that all the app source code now lives in a single place (which is already cool) I like the fact that I can keep offering a Windows 8 only version and a Windows Phone 8.1 only version under the same umbrella in the Store:
Keeping the Windows 8 and Windows Phone 8.1 versions alive is important for people that has not made the move to Windows 10 yet. This because universal apps won’t work on anything before Windows 10. And nicely the Store is very kind of offering me appropriate links for people on each platform:
And interestingly, the Windows 8.1 URL would work even for Windows 10 people, which is great!