1. ASP.NET 5 was announced in mid-late 2015

2. ASP.NET Core was RC'ed in January 2016 and released in June 2016.

3. NestJS 1.0's first NPM publish date was May 14, 2017.

Now that we have the chronological order out of the way, you see why I worded the title the way I did. It's not "ASP.NET Core Is Basically NestJS" because that would infer that NestJS came first -- it did not.

Now that we have the controversy handled, let's look at the similarities and some differences. At the end I'll offer my opinion on when to use one or the other.

Similarities

Just looking at the above table, you can see the two frameworks cover all the bases. There are more similarities I have omitted, or this table would get out of control. For example both frameworks support websockets, gRPC, unit testing, graphql, response caching and auth.

Both frameworks use the concept of inversion of control (the D in SOLID) and just generally are very object-oriented. Anyone coming from ASP.NET Core and strongly typed C# would feel right at home in NestJS with TypeScript. It's a natural transition.

Differences

• NestJS supports CRON-based tasks. ASP.NET Core's BackgroundTask does not support cron expressions.

• NestJS's database ORM support is cool. ASP.NET has EntityFramework which is okay. They're not quite the same thing but do share the same goal -- simplify data access.

• NestJS has specific implementations for microservices. ASP.NET supports different transports, but not out of the box.

• NestJS supports delegation of long-running or CPU-intensive tasks to queues (Redis-backed) via Bull. It's cool that this is built-in, I don't believe ASP.NET has anything out of the box.

• ASP.NET Core's benchmark performance still trounces Node.js, even on Fastify.

Note: It's interesting that out of the popular REST API frameworks, ASP.NET Core is by far the fastest (14) with Fiber (Go) coming in in 34th spot and nothing else in the top 100. Also, these benchmarks don't really matter.

• ASP.NET Core's integration testing framework with TestServer is arguably better than anything Jest can offer.

• ASP.NET Core has a giant corporation behind it and millions of dollars in resources. NestJS is run by a single guy (not really, but you get the picture).

These differences are largely irrelevant, except, perhaps, for the CRON task support in NestJS. There are Nuget packages which improve BackgroundTasks in ASP.NET Core, but they're not available out of the box.

I'm Starting a Business, Which Should I Use?

As with everything in life, it depends. Do you have a team? What is your team's competency? Do you want enterprise-level support when the time comes? Where will you host?

You can write anything with JavaScript and almost everything with C#. C# developers are going to be a bit more expensive than JavaScript. Hosting C# code is going to be a bit more labor-intensive than anything running on Node and potentially also more expensive. You can deploy a Node app to the edge on CloudFront or Railway for free in a matter of minutes. When you scale and you're running on Node, you'll be piecing together disparate services like Railway, Upstash, Axiom and Clerk. If you're running ASP.NET in Azure, you'll get everything you need in one convenient place and have just one bill to pay (although a higher bill).

Recommendation

If you're bootstrapping a hipster world-altering startup out of your garage, NestJS is the better choice. Assuming you don't need any kind of audit compliance any time soon and you're okay with refactoring later when you join the big leagues.

If you're building something in a regulated industry (aerospace, health, finance), and you're planning to bring in more seasoned and serious engineers who take security and performance seriously, I recommend ASP.NET. There's a reason these huge industries run on enterprise-supported languages like Java and C# and not Node.

You may also consider Gin or Fiber (Golang) if you're writing microservices. If you're writing anything real-time like a game server, you won't be using Node, ASP.NET or Go anyway.

In the end, this is not a very high-stakes choice. Look at the big picture and make the call. You won't be disappointed with either choice!

If you read my REST API article, you might already know what's coming: it doesn't matter. That, there, is a bit misleading though, and I'll explain why a bit later in this article. First, let's look at the StackOverflow 2023 Survey.

Data, data everywhere!

The most popular front-end framework is React. This should be a non-controversial statement. From the survey:

1. React - 42.87%

2. jQuery - 22.85%

3. Angular - 19.89%

4. Express - 19.51

5. Vue - 17.64%

6. Next.js 17.3%

Svelte is way down the list with 6.01%, Blazor at 5.41% and Nuxt.js at 3.89%. We'll need these numbers a bit later, so they're here for your and my reference.

Scrolling down a bit we find the admired/desired section where we can see that raw React is not especially useful and most people prefer to use its meta cousin, Next.js. Even further down is the "worked with/want to work with" section where we learn that React developers want to work with Next.js, and are curious about Angular, Svelte and Vue.

Q: Why are we reviewing all this?
A: We can see what the current market looks like and trends away or towards some technologies.

Data review & derivatives

• React devs want to check out Vue, Svelte and Angular

• Vue devs don't want to work with anything other than Vue

• Svelte devs don't want to work with anything other than Svelte

• Angular devs want to check out React

When considering all the above SO survey data, we can derive several assumptions:

• React and Next.js make up 60% of the market, but React by itself is not liked much. Devs who use React want to use Next.js. This is because Next.js is a batteries-included framework that makes building full apps significantly easier compared to piecing together various React packages.

• Vue and Svelte devs either started with those frameworks or came from React and don't want to go back. This makes sense, because both Vue and Svelte have a better developer experience than React.

• Angular devs are interested in React. Here, I'm puzzled. If anything, they should be interested in Next.js, since that's closer to Angular than React is. Perhaps professional curiosity?

• Nobody cares about ASP.NET Core, Blazor.

• People learning to code just focus on what all the YouTubers tell them to - Node/Express, React/NextJS. This is why adoption of arguably better frameworks like Svelte and Vue is low. When you already learned React and it's 60% of the market, why learn anything else?

It doesn't matter

Let's answer the question I pose at the start of this article and explain why it doesn't matter which framework you choose.

If I were starting a greenfield project today, which framework would I choose? Svelte.

Why doesn't it matter? Because if you know JavaScript well, you can pick up any of these frameworks with ease. They all have phenomenal documentation (yay react.dev) and going from Vue to React, React to Svelte or Svelte to Vue is maybe a week or two of getting used to new syntax and some framework-specific quirks. Everything else is just JavaScript.

My front-end journey: Backbone (2013) -> Knockout (2015) -> Angular (2016) -> React (2017) -> Vue (2018) -> Svelte (2023). I still have a KnockoutJS project I support, and recently dusted off React. No problem at all.

React has JSX, but you're mostly writing JavaScript. It's verbose, and hooks are not amazing. Vue has a lot of "magic" resulting in fast dev-to-customer cycles, but there's a bit of ramp-up for new developers learning said "magic". Svelte is super lightweight, and there's a fair bit of magic too, but the syntax is a lot simpler. Svelte is also different in that it's a compiler. You never ship the framework to the customer, resulting in a smaller bundle size.

Closing Thoughts

If you're a CTO or an entrepreneur thinking about which framework you should go with, ask yourself these questions:

1. Will you hire junior/mid-level front-end developers?

   1. If yes, they probably learned React on YouTube, so if your workforce is proficient in React but not JavaScript, go with React.

   2. If not, you will hire a senior full-stack or front-end engineer, they should be able to pick up any framework you choose. I recommend Svelte.

2. Are you thinking about building a mobile app to go along with your web app?

   1. If yes, go with React. React Native is a thing and it's pretty good when you're bootstrapping a business. React skills are 60% transferable to React Native.

   2. If not, go with Svelte.

3. Are you going to have an API product along with your web app?

   1. If yes, consider a meta framework like NextJS, NuxtJS or SvelteKit. These come with a backend you can just reuse for your API without needing to build a separate project.

4. Do you want your developers to be super productive?

   1. Svelte

5. Do you already know Angular and plan on building everything yourself?

   1. Svel... just kidding, go with what you know best: Angular

Above are my opinions, based on my own experience with React, Vue and Svelte.

There are many other things to consider. Mobile-first businesses may consider React Native, but also Flutter and .NET MAUI. If you're going with Flutter, you're in Google's ecosystem, so Angular may be a viable choice, especially if you're using Firebase as your backend. Anyone building with .NET MAUI, good luck! You're in the Microsoft ecosystem, so you may want to consider Blazor -- especially since Blazor Hybrid makes component transfer between projects a breeze.

Let me leave you with this:

If you hire strong front-end developers with solid JavaScript basics, they will be able to jump into any framework you throw at them. Ramp-up time is 1-2 weeks, so it honestly doesn't matter which framework you choose.

Happy building!

Most popular programming languages have their REST API frameworks:

• Node has Express, Fastify and Nest

• .NET has Active Server Pages (ASP)

• Python has FastAPI, Flask and Django

• Go has Echo, Fiber and Gin

• Rust has Rocket and Rustless

I didn't list other languages here as I am less familiar with those, but out of the 5 listed above, I've tried most and there is one definite truth about them: They are all essentially the same.

There are differences between how Rust and Go, or Python and .NET handle stuff behind the scenes, but my hot take is not meant to compare lab benchmarks of all these frameworks. Instead, I'm talking about the dev and customer experience. Let's narrow it down a bit.

Dev Experience

Some of the above frameworks are a bit more complicated than others. ASP and Django are "batteries-included" frameworks, NestJS is more serious than Express and Fastify, while Echo and Fiber are overall less capable than Gin, but still have everything you'd ever need to write an API. At the core of these frameworks is their promise to serve REST requests. Here are some examples:

app := fiber.New()

app.Get("/", func(c *fiber.Ctx) error {
    return c.SendString("Hello, World 👋!")
})

app.Listen(":3000")

Another:

const express = require('express')
const app = express()

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(3000)

And another:

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

One more:

from flask import Flask
app = Flask(__name__)

@app.route("/")
    def hello():
        return "Hello World!"

if __name__ == "__main__":
    app.run()

And last one...

#![feature(proc_macro_hygiene, decl_macro)]

#[macro_use] extern crate rocket;

#[get("/")]
fn index() -> &'static str {
    "Hello, world!"
}

fn main() {
    rocket::ignite().mount("/", routes![index]).launch();
}

As you can see in the above examples, these are all conceptually the same, simply different syntax since they're all written in different languages.

1. Instantiate a server object

2. Define a route, then add a handler to it.

Note: I'm not familiar with Rust, but wanted to include it since it's been all the rage recently.

ASP.NET is neat because it can get as simple or as complicated as you need it to be without needing additional 3rd party packages. The syntax above is called "minimal", but the framework supports the MVC pattern, dependency injection and more.

Node users will usually start with Express, then be told they're tools for using that and shown the light of Fastify. Once they switch to Fastify, they'll discover nobody actually uses it in serious production apps, because NestJS exists. Coincidentally, NestJS is built on top of Express/Fastify. Ah, the world of Node is a doozy.

Python has several good options too, with Django being the 1000 pound gorilla... but FastAPI and Flask are popular too. If you're a Go dev, you may first find Gin and then learn about Fiber.

If you're an entrepreneurial spirit thinking about starting your own SaaS, you may look at this list and collapse in a heap. But wait! Good news! It doesn't matter which one you choose, because the customer cares about the experience, not how that experience is delivered.

Customer Experience

Whether you go with ASP.NET, NestJS, Gin or Flask to deliver your API, the experience will be the same. The customer will get a Bearer token somewhere, toss it into the header, then send a GET or POST request to your API. They'll get a JSON response and be pleased. Sure, sure... in some cases, they'll send a GraphQL or a gRPC request (in which case you will want to make sure your framework supports these), but 98.4% of the time you'll serve a JSON response either directly to the customer or to your mobile or web app.

As I mentioned earlier, I'm not considering minute differences in performance when serializing huge data sets, or any kind of data transformation that might occur in the controllers/handlers of these frameworks. In most cases, data transformation should not be happening in the API anyway, or ideally, it shouldn't be happening "live" at all and if you're considering JSON serialization speed, you're designing your API incorrectly anyway (or you're Salesforce/Oracle and don't care about customer experience).

Customers make requests and receive responses. Regardless of the framework you use, your kickass new SaaS will be successful.

Parting Thoughts

If you've designed your cloud architecture correctly, the framework does not matter. If you're consciously building a monolith, you may opt for Django. If you're gonna be running several or several hundred microservices, Go, Flask, Fastify and Rustless are awesome choices. If you're writing a robust customer-facing API, NestJS and ASP.NET are great choices. You can even write everything in just one language and framework like ASP.NET, Express or Flask.

• You won't need Rust's garbage collector-less performance advantages if you're just starting out. Don't sweat the details -- pick whatever is the quickest to be productive with.

• Any decent software engineer (especially Sr level) can join your company and be productive with any of the above frameworks even if they have never used them or written any code in the language.

  I've been coding primarily in C# and JavaScript, but I picked up Go/Fiber in one week and then Python/Flask the week after. Once you're an expert in one language, other languages are a cakewalk. Truly.

• I didn't mention meta frameworks like NextJS, NuxtJS and SvelteKit. These come with their own REST APIs that marry the backend and frontend technologies in one tech stack. These are all JavaScript/TypeScript and should strongly be considered especially if you're building a web app.

• Before making a technology decision, take a step back and look at the big picture. Are you going to need to scale quickly? Do you have a mobile app and a web app? Are there microservices? Think about cron jobs or any ETLs you're gonna write. Is your product AI based (where you need to train your own models) or do you just plug into OpenAI or Bard? How about community and support?

At the end of the day, the API framework you choose for your customer facing product is irrelevant. The API framework you choose for backing microservices is mostly irrelevant (there are some less than optimal choices, but nothing that would sink your business). What you build your front-end in -- well, that may be a bit relevant... and about that in the next article!

Packages

Here are some other libraries off NPM we're going to use with Nuxt:

• date-fns - date formatting and manipulation made easy!

• auth0/auth0spa-js - we'll need this to facilitate logging in with Auth0

• hapi/iron - this will be used to seal/unseal a cookie on the server

• jose - used to parse JWKS on the server

• pinia-nuxt - global state management on the front-end (goes with pinia below)

• numeral - number formatting made easy!

• sass - we'll need this to transpile sass into CSS

• bulma - this is our CSS framework

And some Nuxt modules:

• icon

• color-mode

• device

• pinia

You may be wondering why we didn't opt to go with Tailwind, Windicss or Unocss. This is where big-picture planning comes into play. We're building a SaaS application to support our main product, which is IoT hardware. This means that our customer is not expected to be spending a lot of time in the UI, if any at all beyond the initial setup. Thus, in the interest of time and developer productivity, Bulma with its ready-styled components, customizability and extensions is the smart way to go. Would I prefer to use Windi? Yes I would. Is it the smart thing to do in this case? It is not.

Authentication

We chose to go with Auth0, which means we're going to need to use one of their login SDKs. However, rather than communicating with their server every time to validate a token, we're gonna create our encrypted cookie which contains all the information we need to communicate with any APIs we protect with Auth0. Because Nuxt 3 comes with excellent cookie handling infrastructure, this is the easiest, most performant, and very secure way to manage session state for a SaaS application. Libraries used in this process are @hapi/iron, jose and @auth0/auth0-spa-js. We're not going to use Auth0's Vue SDK, because we're not using any functionality contained therein.

Utilities

To make formatting easier, we'll use date-fns and numeral. These are standard libraries used in thousands of projects. I know numeral has been around for an exceptionally long time, so if anyone has suggestions for a more modern alternative, I'm happy to check them out.

We're also going to use Pinia for state management. Pinia is the spiritual successor to Vuex, Vue's own state management library modeled on React's Redux. Pinia is easy to use, conceptually straightforward forward and does all that Vuex used to do.

Development Process

Since Nuxt 3 can be used to build both the front-end and middle-tier, it makes sense to hire full-stack engineers to drive the project. It will be more cost-efficient, and work will get done faster. This is the theme of the project -- developer efficiency resulting in quick product to market.

In my experience, the most efficient way to build in Nuxt is by focusing on features rather than problem spaces. For example, if we're building "the like button", the engineer in charge of that is responsible for designing the button itself, hooking it up to the Pinia store, the server API, and the database. This is as opposed to one engineer working on the button front-end code and another on the middle-tier and database. For small to medium-sized projects, separating by problem spaces introduces unnecessary complexity. This is why full-stack engineers are well-paid and highly sought after!

When building out the initial project, I like to start with this process:

1. Scaffold out start project via CLI

2. Add all necessary packages

3. Update any configuration files (tsconfig, nuxtconfig, etc)

4. Add CSS bindings

5. Build out starter routes / pages, state store, components, composables

6. Add a layout if necessary (probably is!)

7. Add authentication

Once this is all done, feature development can begin. Developers coming in will have a solid foundation to build on, examples of project assets like composables and pages, and most importantly, be able to deploy the code to a publicly available host because it will be secured.

In the next article, we'll tackle backend implementation with microservices and our database of choice - Redis Stack.

The Scenario

Given a GUID Id of an ancestor Account object (think like a Salesforce account or an Organization), find all the Accounts under that ancestor to a maximum depth of 5. Something like this:

Given Account A's Id, get all the Accounts under it. First, here's the function which executes the recursion:

public async Task<IEnumerable<Account>> GetAccountsWithChildren(Guid id)
    {
        // Get all accounts first
        var allAccounts = await GetAccounts();
        // Bail early if no results
        if (allAccounts == null || allAccounts.Count == 0) return new List<Account>();
        // Get the root account
        var rootAccount = allAccounts.FirstOrDefault(x => x.Id == id);
        // Bail if root account not found
        if (rootAccount == null) return new List<Account>();
        // Define the max depth we want to run our recursion
        var maxDepth = 5;
        // Set up the list we're going to populate with results
        List<Account> childAccounts = new List<Account>();
        // Add the root account at the start
        childAccounts.Add(rootAccount);
        // Run the recursion!
        ExtractAccountsRecursively(maxDepth, id, allAccounts, childAccounts, 0);
        // Finally, return the results
        return childAccounts;
    }

Nothing exceptional in the above method. The fun stuff is in this next bit:

private void ExtractAccountsRecursively(
    int maxDepth, 
    Guid? parentId, 
    IEnumerable<Account> allAccounts, 
    List<Account> childAccounts, 
    int currDepth = 0)
    {
        // Bail if depth reached
        if (currDepth >= maxDepth) return;
        // Bail if parentId is null
        if (!parentId.HasValue) return;
        // Bail if there are no more children
        var currentChildren = allAccounts.Where(a => a.Parent != null && a.Parent.Id == parentId);
        // Increase the current depth to pass down to the recursive function
        currDepth++;
        // Iterate over the children found with the parentId above
        foreach (var account in currentChildren)
        {
            // Prevent duplicates
            if (childAccounts.Contains(account)) continue;
            // Add the account to the child accounts list
            childAccounts.Add(account);
            // Run this function again for the account we're iterating through
            ExtractAccountsRecursively(maxDepth, account.Id, allAccounts, childOnlyAccounts, currDepth);
        }
    }

I commented the code above so it should be easy to follow. The incoming list, allAccounts , is a flat list of Account objects with ParentId property referring to the Id of another Account object.

I suspect there's a better way to write this using yield but that syntax confuses me. If anyone has a good example for the above scenario using yield I'd be interested to check it out.

Cheers!

• Frontend: Nuxt 3, Bulma CSS, no component library

• Middle Tier: Nuxt 3 (Nitro/h3)

• Database: Redis Cloud

• Microservice infrastructure, services written in .NET 6.0 running in Kubernetes

• Authentication: Auth0

• Logging: Custom (Winston in nuxt3, ILogger in .NET)

With these example technologies, let's look at the tooling I'm going to need to install to get up and running.

My (and I would imagine most people's) choice for coding front-end is Visual Studio Code. Since Nuxt is both the front-end middle tier, VS Code will cover both!

For the database, I chose Redis Cloud. I don't want to host my own Redis server and the Cloud option is free to start and cheap regardless. I will use RedisInsight to work with Redis since it's honestly the best tool out there.

I'll build out a set of microservices to support the application. Hosting microservices is best done in Kubernetes (even though there are some cool Level 2 options out there), so I'll install the necessary tooling:

• Kubectl

• Kubectx

• K9s CLI

If you know anything about Kubernetes, you may be wondering where HELM tools are at. In this case, my project is not big enough to necessitate using HELM. One of the big lessons I took away from the past 3 years of working with Kubernetes is that it's extremely easy to over-engineer infrastructure -- especially Kubernetes. In my experience, building up to 20-25 microservices does not warrant anything more than basic levels of orchestration via YAML.

For writing .NET I'll use Visual Studio. Yes, theoretically I could just use VS Code, but the proper VS experience is better than VS Code. The community edition is free.

Working with REST and GraphQL services is best done with a tool like Postman, but my personal preference is Insomnia.REST ... their free version is good enough for what I need. If you can recommend something else, I'm open to suggestions in the comments!

Some other not completely related tools I like to use are Windows Terminal, Notepad++, and Whimsical. I have several CLIs open in the Terminal, keep quick notes or open random files in Notepad++, and create designs and share with my team in Whimsical.

Side note: On personal projects I like to use Notion and Penpot. Though I don't use them daily at work, they're very cool and I recommend checking them out if you're a one-stop-shop full-stack engineer.

These are all the tools I can recommend at this time. I'm always looking for cool new tools, so if you have any suggestions, please leave them in the comments!

In the real world, Gin is not a framework you're gonna be able to hire easily for. Nobody builds enterprise-grade apps with Laravel. Good luck getting audited for an IPO running on Node. And yet, Gin, Laravel and Node are excellent platforms to build on. I have written public-facing applications using two of those! Would I choose them for my SaaS though?

Maybe. Depends. Some questions first:

1. Will this tech be supported 10 years from now?

2. Will I be able to hire people who can work with this tech?

   1. Is the tech appealing and easy to get started with?

   2. Does it have a large community?

3. Are there any potential security or performance issues with the tech?

   1. These could be non-existent at low user volumes but start showing up as the user base grows.

4. Will I enjoy working with this tech?

Answer the above questions for the tech stack of your choice. If you answer "yes" to all four, you may have a winner!

Let's explore the various parts of a SaaS and answer some questions.

Middle Tier

I'm familiar with .NET, so I'll use that as an example.

1. .NET has been around since the mid-2000s, and Microsoft is not about to let go. I'm confident .NET will be around for many years to come.

2. There are many .NET developers. Hiring should be no problem. Since .NET Core and more recently .NET 6.0, the stack is quite easy to get started with and the documentation is phenomenal. Since the framework has been around for 20 years, the community is huge too.

3. There are always gonna be potential security and performance issues with any framework, and .NET is no exception (look at EF Core early on, what a mess). However, Microsoft is particularly good at patching those up and their release cadence is clear and solid.

4. I enjoy working with .NET 6.0. C# specifically is an awesome language. C# 7 and recently C# 10 introduced a lot of modern features and made coding less verbose and just generally a better user experience.

Backend

Though I've done a bit of React and Angular, my framework of choice is Vue.

1. Vue has been around a while, it has a large community and lots of support. The OSS community backs it, so I don't have to depend on a corporation to keep it current (see Angular...). Vue checks out.

2. Vue may be difficult to find developers for, but it's extremely easy to pick up, so anyone with generic JavaScript knowledge should be able to fit right in. As mentioned above, the community is huge so getting help should be easy.

3. JavaScript has had a tough time with performance and security. Today, it's in the best place it has ever been, but still has ways to go. Vue 3 is a significant performance improvement over Vue 2, so chances are Vue 4 will be too. I trust it.

4. I love working with Vue (Svelte close second!), so no problems there!

Data

Data storage is a different story. Though some of the questions still do apply, database choice is a matter of need rather than want. Some key points:

• If your data is relational, you'll want to use a SQL database. SQL is also the most common way to store business data and is easy to hire for. There are a lot of choices here, though I would highly recommend a cloud-hosted managed solution. Cockroach DB, Azure SQL, or any cloud-hosted SQL database honestly.

  • Self-hosting a database is a lot of work. Automated backups, geo-replication, etc... It's a lot of overhead. Better just to pay!

• If you're building out a microservice infrastructure, you're going to silo each business entity behind an API. This means you can use document storage like MongoDB, Azure Cosmos, Google Firestore, or even Redis.

  • Joining between entities will happen in the API Gateway layer.

• Binary file storage is straightforward. Amazon S3, Azure/Google Storage. There are several options here so depending on which cloud hosting provider you go with; you'll want to go with that solution.

There are some other data storage solutions such as a graph database, which have niche applications. It's worth it to spend the time to proof-of-concept different solutions and use different data stores in the process.

Last, but not least

Some questions which I didn't ask above but should be considered:

• If my business is successful and I'm getting bought out (or going public), will I pass a security audit?

• Does the front-end/middle-tier framework have SDK support for the data backend I want to use?

• Do my financial backers have a say in the tech stack? Some VCs may have enough technical chops to butt into your technology choices.

Also, depending on the size of your application, you may want to mix-and-match services from different hosting providers. For example, I have an application running on Render, static assets hosted in Google Storage and data sitting in Redis Cloud. When creating these, I made sure to put them all in the same geographic area (US West in my case) to reduce performance implications when my middle tier must talk to my database.

Choosing a tech stack is a monumental decision which will stay with you for many years, if not forever. Moving infrastructure, migrating data or switching frameworks are time-intensive and thus expensive endeavors. Sometimes switching is unavoidable due to product End-of-Life or hosted service deprecation. A cloud developer's job is to anticipate all the plays and lead their team to victory by making the right decisions at every opportunity! Don't be afraid to pivot should a choice you made turn sour either. Lastly, don't over-complicate your architecture. Your microservices may not need an event hub or a pubsub to communicate. You may not even need microservices. Hell, your app may not even need a middle tier -- perhaps Firebase, Supabase or Pocketbase is all you need...

Throughout the series, I will assume my business is hardware-centric with a SaaS application supporting customers. A good example of this is any IoT business such as DIY alarm systems (SimpliSafe, Abode), any smart home company such as Samsung, Wyze or Philips Hue, or automotive smart integrations such as the Hyundai Bluelink, BMW's My BMW or Ford's FordPass. I chose this scenario because it's a bit more complicated than a regular run-of-the-mill web app and my goal is to cover more advanced scenarios. That said, a lot of the thought process will apply to regular web apps too.

Before getting into the meat of said thought process, let's look at some decisions we're gonna have to make before writing that first line of code.

Initial Considerations

Most early-stage SaaS green field projects will need to make key decisions that will stay with them for the lifetime of the product. Build vs buy is going to be one such decision. Depending on your business's core competency, you will want to outsource difficult or time-consuming pieces of your SaaS. For example:

• Authentication. Do you build your own or let an Identity Provider handle it?
• Server-side caching. Do you host your own Redis or use a managed service?
• Logging. Do you store and parse your own logs, or send them to a hosted log processor?
• Front-end components. Do you use an existing library, or build your own?

Deciding what to buy will of course depend on multiple factors such as your budget, team expertise and time horizon. For fledgling startups, buying early on makes a lot of sense. Many SaaS products in the above categories have generous free or low-cost tiers. Here are just some:

• Authentication: Google Identity, AWS Cognito, Auth0
• Caching: Redis Cloud
• Logging: Datadog, AWS CloudWatch, Azure Application Insights
• Hosting: Google Firebase, Render.com, DigitalOcean, Heroku

Let's look at some costs.

Cost of Doing Business

As your application grows, some of these "buy" services will start to become very costly and potentially hinder your growth (especially in the hosting space). Here is one such scenario:

You start out on render.com with five microservices paying $25/mo for a 2GB/1vCPU single instance per service. You have one environment, because you've just started to build. A few months later you're ready to go to production so you create another mirrored environment of five services, but this time, since it's production, you want to give the services a bit more oomph, so you opt for the $50/mo instances. A couple sprints later you're ready to push recent changes to production, but first you want to ensure they work well with production data... so, you need a staging environment. This environment should, optimally, mirror production, so another 5 * $50/mo.

Next, each microservice is going to store data in a silo, so each one needs a database. You choose to use Postgres: (5 $20/mo)... 3, because each environment needs its own data.

Last, we can add some static costs:

• Auth0: $23
• Redis Cloud: $35
• Datadog: $5 (you're not logging much...)

To sum up:

Hosting:

• $25 x 5
• $50 x 5
• $50 x 5

Data:

• $20 x 5 x 3

Other:

• $63

Total: $988/mo

These are very conservative numbers, too. In most cases you will run at least two instances of your production code so that if one goes down for some reason your entire application doesn't fold with it. As more traffic comes to your product, you will want to increase memory and CPU of your hosting machines and potentially add more instances (or let it auto-scale if such feature is available).

Note: We evaluated Render as a hosting platform to reduce Azure spend but decided to pass. Instead, we built out a Kubernetes cluster. Had to learn a lot of DevOps in the process, but now we are saving thousands per month.

Recommendations

It's difficult to give raw recommendations because everyone's situation is going to be different. I can, however, tell you what I would do today if I was starting from nothing given the hardware SaaS company scenario I mentioned earlier.

Authentication Build it. Identity Providers start cheap, but they can get out of control quickly, especially if you're successful and scale up. They do provide easy-to-use SDKs and have nice UIs for user management (except Azure B2C, that thing is gross), but if you're just starting out, you do not need 98% of what they offer you. Instead, use whatever AuthN libraries come with the web framework of your choice. In our case, we used Identity Server 4. In other projects, I used Passport.js. These are battle-tested solutions that give you everything you need out of the box for free.

Hosting Buy it but be strategic about it. In a microservice scenario, it will most definitely be cheaper to run your own Kubernetes cluster (especially if you pre-pay for years of VMs). If you are just building a monolith, hosting it on a beefy PaaS (Platform-as-a-Service) like Heroku or Render is great. The ease of use of these services is a tremendous boon to your productivity and quick delivery to market. I wouldn't try to nickel and dime around hosting by going with a VM like DigitalOcean or Linode, or worse -- self-hosting on your Raspberry Pi.

Caching Buy it. Redis Cloud. No, they didn't sponsor me. It's just the smartest way to go if you need caching (or if you're cool and want to use their permanent storage solution instead of a database).

Database Buy it. Managed databases excellent value. They save you from stress. You don't have to worry about backups and when you scale, your databases scale with you, including to other continents! Schema migration went awry? No problem, do a restore. All you need is a connection string and you're off to the races.

Logging Buy it first but build it later. When your product becomes complex and has hundreds or thousands of try/catch blocks, and each service has several instances, it's easy to flood logging services with records resulting in excessive costs. The thing about logging is that it's conceptually quite simple. Many logging libraries support bringing your own "sink", which you can then use to deposit logs to a datastore of your choice, aggregate it, write your own retention policies and so on. This is of course way later, but in my experience, logging costs at larger scale can get ridiculous, so it's worth exploring an in-house solution once you have the engineers and capacity to build it.

Front end components Get it for free or build it. You may be tempted by pretty, premium component libraries, but the truth is that customers aren't gonna keel over from overwhelming wonder when they see a premium pie chart versus a c3.js one. Tables, dropdowns, multi-selects, they can all be either found for free in the OSS community or straight up written yourself. We used Buefy (a VueJS lib), and we'll stick with Bulma CSS going forward, but personally I've also experimented with Tailwind and Uno when writing my own custom components. There are many awesome, free component libraries out there, so... don't buy.

In Conclusion

There are many items on the check list when spinning up a new SaaS. The goal of the next few articles in this series will be to do a bit more of a deep dive into specific topics mentioned at the beginning of this article, beginning with choosing your tech stack!

The problem with file system article indexing is that you must check in an updated version of your blog every time you author a new article. The blog was hosted on render.com and their build pipeline is very neat so overall not a big deal, but there's still a fair amount of friction there.

Before the above, I was writing on Medium, and before that I was hosting my own ASP.NET Razor Pages blog on Azure. Medium was good, but their monetization strategy is not to my liking. I also wanted to host using my own domain rather than writing "for" Medium.

After a bit of research, I decided on Hashnode. Their comparison to other platforms linked in the hashnode.com footer (when you're not logged in) is pretty spot on. It was between dev.to and hashnode and dev.to does not have custom domains... let alone with automated Let's Encrypt SSL certificates. Pretty sweet!

Thus, for now, I am here, on Hashnode! Hopefully, they work out the editor bugs soon. I know text editing in web browsers is as bad as working with dates, so I for now I can live with it.

Please look forward to a slew of new articles soon!

Quick primer on how to clean up old images in Docker. One of the first things you're gonna find when you search for this question is docker images prune. This works, but only on dangling images. Dangling images are essentially orphaned images created as a process in making another image. They're usually generated when a Dockerfile creates a few layers during final image creation.

Thing is, when you're building images and tagging them with, for example, the build number, those images are not dangling and they will be omitted during the image prune command. Example:

REPOSITORY                        TAG            IMAGE ID        CREATED          SIZE
fancy.service                     latest         813d1928f6b8    3 days ago       156MB
fancy.service                     v10            813d1928f6b8    3 days ago       156MB
contoso.azurecr.io/fancy.service  latest         813d1928f6b8    3 days ago       156MB
contoso.azurecr.io/fancy.service  v10            813d1928f6b8    3 days ago       156MB

We have 4 images that are essentially the same. Perhaps today you built v11 and want to get rid of v10, or just get rid of anything older than today's. Here's how:

docker images | grep 'days ago\|weeks ago\|months ago\|years ago' | awk '{print $3}' | xargs docker rmi --force

There are 4 parts to this command.

1. docker images pulls the list of all images in the system and pipes it to
2. grep 'days ago\|months ago\|years ago' which selects every row that has those words in it and then pipes it to
3. awk '{print $3}' which returns the item in the 3rd column from each row - in this case the IMAGE ID - and then pipes it to
4. xargs docker rmi --force which is the crown jewel of this entire command. Xargs takes each line from the previous output and passes it as a parameter to the command docker rmi --force.

This should clean up all images older than today. You can remove days ago\| if you want to keep recent images for example.

Keep in mind this command will not remove images which are in use. That is anything that's mounted as a container -- even a stopped container.

Secrets in Kubernetes are essentially key-value pairs stored in K8s' API server's database. They are by default not encrypted so anyone with access to the API can retrieve, change or delete a secret. Thus, when storing sensitive information in K8s' secrets store, you must enable encryption-at-rest.

Good uses for secrets:

• Storing SSL certificates
• Storing container registry authentication information
• Storing sensitive access keys to 3rd party distributed configuration tools

Kubernetes documentation is fairly good, so I am not going to rehash it here, but I did want to focus on a common scenario:

You have a microservice which needs to read a configuration from a 3rd-party Distributed Configuration Service (DCS). To access this DCS, the microservice needs a key.

Creating

Let's see how this can be done using the generic secret type. The following kubectl command will create the secret.

kubectl create secret generic dcscreds --from-literal=clientid=abc --from-literal=secret=123

The first 4 words in the statement are specific to kubectl. The last word, generic, states we want to create a generic type of secret. Other types include TLS and container registry secrets. The dcscreds in the above statement is the name of the secret which you'll reference in your pods later to pull the secrets. Lastly, there are two values we're storing in the secret. Secrets can be created from different sources:

• env file (such as Docker's .env)
• actual files with the values
• literal strings

In the above example we're using literal strings. I feel like that actually makes the most sense since the other two options mean you're reading from files which could potentially be checked into source control... and we shouldn't be checking credentials into source control to begin with. The --from-literal= parameter picks the third option from the list above, and is then followed by the key=value pair clientid=abc.

Let's check the secret with

kubectl get secrets

One of the secrets should be

NAME                    TYPE                  DATA    AGE
dcscreds                Opaque                2       1m

Using

How do we reference this secret in our deployment YML files now? Let's say we want to inject a secret as an environment variable into our microservice so that it can access the DCS. Here's an example deployment YML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cache-deployment
  namespace: integration
  labels:
    app: cache
spec:
  template:
    metadata:
      name: cache
      labels:
        app: cache
    spec:
      containers:
        - name: cache
          image: redis
          env:
            - name: CLIENTID
              valueFrom:
                secretKeyRef:
                  name: dcscreds
                  key: clientid
                  optional: false
            - name: PASSWORD
              valueFrom:
                secretKeyRef:
                  name: dcscreds
                  key: secret
                  optional: false
  selector:
    matchLabels:
      app: cache

In the above deployment you can see the env has two values. The env.name of the value is what you'd refer to inside your application, while the env.valueFrom.secretKeyRef.name is the name of secret we created above, followed by the env.valueFrom.secretKeyRef.key which refers to the key of the key=value pair. The optional flag will fail to create the deployment if the secret/key does not exist.

Great, but, what if the secret changes?

Editing

To edit a secret, we can use the following command:

kubectl edit secrets dcscreds

This will open the secrets YML in the operating system's default text editor. It will look something like this:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
  clientid: YWJj
  secret: MTIz
kind: Secret
metadata:
  creationTimestamp: "2022-05-14T20:49:15Z"
  name: dcscreds
  namespace: default
  resourceVersion: "34419738"
  uid: 5d489368-27d6-4e57-b16b-b936109b027f
type: Opaque

Values in data are base64 encoded. You can use a base64 decoder to see what they are. If you need to encode new values, you'll have to encode them. As an example, let's say the secret changes from 123 to 456. Here's a helpful command to encode that:

echo -n '456' | base64

The ouput would look like

NDU2

Once you have that base64 encoded value, simply replace it in the secrets YAML file:

...
data:
  clientId: YWJj
  secret: NDU2
...

Save the file, close it, and kubectl will update the secret in Kubernetes. Done and done!

Deleting a secret is done the same way as deleting other entities:

kubectl delete secret dcscreds

Resources

• Secrets
• Encryption at Rest

A little while ago Microsoft finally added support for dependency injection in their Azure Function product. Now, there are some subtle but important differences, but for the most part the experience is similar to what you're used to in ASPNET Core.

Microsoft's official documentation, found here, is as usual lacking in real-world examples. Thus, the purpose of this article is to expose some real world use cases to the wider public. We're going to build an Azure Function which listens to a Service Bus and writes to an Azure Search index.

Before we started, a brief introduction.

Azure Function Primer

Azure Functions are supposed to be single-purpose pieces of code which are trigger when an action happens. These actions are in fact called triggers. Once your code is trigger, it can do anything you want it to, but most often you'll want to do some kind of processing on the input from the trigger and spit out the result into a 'binding'. Bindings are essentially output buckets you can deposit the result of your function into. The key is to understand that triggers are mandatory but bindings are optional.

Microsoft's own documentation on triggers and bindings is pretty good, so if you're new to Azure Functions, I recommend giving that a read.

In our case, we'll be using a Service Bus trigger, but since there is no Azure Search index binding, we'll have to write to the index manually.

Not having a binding you need is a pretty common scenario, because Microsoft doesn't really support anything outside of their own ecosystem and even within the ecosystem getting them to build bindings you need is a tall order. How many years have we been waiting for Azure File Storage bindings?

Right, so now that we know what we're building, let's dive into the code.

Creating the Function

Go ahead and spin up a new Azure Function in Visual Studio. If you want, you can choose the Service Bus trigger while scaffolding -- that will make the process a tad bit faster. Choose whatever default storage account you use to store your functions (or Storage Emulator), make sure you've selected at least version 2 of Azure Functions (though as of this writing, 3 is the latest one so I'll be using that).

You already have a Function1.cs file which contains the default function code. There are also host.json, local.settings.json and possibly a .gitignore. Let's add a couple more files:

• Startup.cs
• ConfigBuilder.cs

Startup is going to contain our dependency injection code and ConfigBuilder will pull config files from the filesystem.

We're also going to need to add a Nuget package Microsoft.Azure.Functions.Extensions.

Inside Startup.cs class, add the following code:

[assembly: FunctionsStartup(typeof(FancyFunction.Startup))]
namespace FancyFunction
{
    public class Startup : FunctionsStartup
    {
        public Startup() { }

        public override void Configure(IFunctionsHostBuilder builder)
        {
            // 1. Build Config

            // 2. Add Config as a Singleton

            // 3. Add logging

            // 4. Add the search service
        }
    }
}

First, we have to add an assembly reference attribute at the top of the namespace and specify the Startup class as the entrypoint. Then, we need to inherit from the FunctionsStartup base class and add an empty constructor. Lastly, implement the required Configure override.

We have our steps defined in the comments there, so let's start with building the config. We can add appsettings.json via Microsoft's IConfiguration interface. Inside ConfigBuilder.cs add the following code:

namespace FancyFunction
{
    public static class ConfigBuilder
    {
        public static IConfiguration BuildConfiguration(string rootDir = null)
        {
            // We're allowing specifying a custom root directory
            if (string.IsNullOrEmpty(rootDir))
            {
                // Theoretically this should exist in Azure Function apps
                var localRoot = Environment.GetEnvironmentVariable("AzureWebJobsScriptRoot");
                // But if it doesnt, then this will
                var azureRoot = $"{Environment.GetEnvironmentVariable("HOME")}/site/wwwroot";

                rootDir = localRoot ?? azureRoot;
            }

            // Grab the environment setting to use below
            var environment = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT") ?? "Development";

            // Create and retun the config
            return new ConfigurationBuilder()
                .SetBasePath(rootDir)
                .AddJsonFile("appsettings.json", optional: true)
                .AddJsonFile($"appsettings.{environment}.json", optional: true)
                // Add any more sources you need here
                .Build();
        }
    }
}

Resolve any usings missing. The code is explained in the comments.

Inside Startup.cs, let's do steps 1 and 2:

// 1. Build Config
var config = ConfigBuilder.BuildConfiguration();

// 2. Add Config as a Singleton
builder.Services.AddSingleton(config);

Next, logging. Simple:

// 3. Add logging
builder.Services.AddLogging();

This will add the default loggers, one of which is Console. This step is not strictly necessary if you intend on using just the Console, since functions are injected ILogger out of the box, but if you plan on using any 3rd party or maybe your own logger, you can do so here by passing in a parameter:

builder.Services.AddLogging(cfg => {
    // your code here
})

We will inject this and other services via Dependency Injection into the function soon.

Lastly, let's add the Azure Search Service. We need to create the search service first, then add it as a Singleton. Go ahead and create a new class: AzureSearchService.cs. Inside, create an interface and the class which inherits from it:

public interface IAzureSearchService {
    Task<bool> MergeDocument<T>(T entity, string index);
}

public class AzureSearchService : IAzureSearchService {
    public SearchServiceClient Client;
    public AzureSearchService(SearchServiceClient adminClient) {
        Client = adminClient;
    }
    public Task<bool> MergeDocument<T>(T entity, string index) {
        // ... code to merge a message from SB into Search Index
    }
}

We're not going to build out the search client in this post, since the focus here is on Azure Functions. You can think of this service as a standard DI service you'd write in a typical .NET Core application. The interface is there to make it testable.

You may have to install Microsoft's latest Azure Search Nuget package. As of this writing, it's Microsoft.Azure.Search version 10.1.0, but knowing Microsoft, by the time you read this, it'll be deprecated...

Now that you have the Azure Search Service class, you can add it to Startup.cs:

// 4. Add the search service
builder.Services.AddSingleton<IAzureSearchService>((provider) =>
{
    // Create the client first using config values from appsettings.json (or alternative source)
    var adminClient = new SearchServiceClient(config["SearchServiceName"], new SearchCredentials(config["SearchServiceAdminKey"]));
    // Return the implementation of the class with this adminClient.
    return new AzureSearchService(adminClient);
});

We're creating a singleton here, because the Search Client is reusable and does not need to instantiate every time a request is made.

Using DI in the Function

Finally, we can get to writing our function! Inside Function1.cs (or, if you renamed it, whatever the new file name is) make the following changes:

1. Remove static from the class definition.

   public class Function1
   

2. Add a constructor

   public class Function1
   {
    private IAzureSearchService _searchService;
    private IConfiguration _config;
    private ILogger<Function1> _logger;
   
    public Function1(IAzureSearchService azureSearchService, IConfiguration configuration, ILogger<Function1> logger)
    {
        _searchService = azureSearchService;
        _config = configuration;
        _logger = logger;
    }
   
    // ... Your function code here
   }
   

3. Write out the function just as you would a typical controller endpoint. You'll have access to anything you injected in the constructor and reassigned out of its scope. Here's an example:

   [FunctionName("Function1")]
   public async Task Run([ServiceBusTrigger("fancy-topic", "fancy-subscription", Connection = "ConnectionStringDefinedInEnvironment")]Message message)
   {
    // Get the body of the message
    var body = Encoding.UTF8.GetString(message.Body);
   
    // Get user defined properties (UserProperties) is just a dictionary
    message.UserProperties.TryGetValue("customProperty", out object customProperty);
   
    // Deserialize the body
    var msgObject = JsonSerializer.Deserialize<FancyMessage>(body);
   
    // Use the search service
    await _searchService.MergeDocument<FancySearchIndexModel>(new FancySearchIndexModel
    { 
        /* Reassign properties from message to search model here */
    }, "FancyIndex");
   }
   

   This is it!

The entire process basically goes as follows:

1. Create Startup.cs
2. Add some attributes to specify that we're using a Functions-specific Startup class
3. Add services to the DI container
4. Inject services into the constructor of the function

Thanks for reading!

The case I want to present today is somewhere between the Dashboard and the Data Pipeline. In these next few articles, we'll use a .NET Core library called KubeClient to retrieve metrics from the cluster's API and print them to console. In the example code, we'll write a simple .NET Core console application in preparation for turning into a cron job in a future article. Let's get started.

You can create a new project via dotnet new console and add the KubeClient package I linked above. I created a new directory called KubeMetricScraper to house this project.

mkdir KubeMetricScraper
cd KubeMetricScraper
dotnet new console
dotnet add package KubeClient

You should see in your KubeMetricScraper.csproj file the following:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="KubeClient" Version="2.3.11" />
  </ItemGroup>

</Project>

Obviously if you're doing this months from now when .NET Core is version 17.8 or whatever, you'll see a different target framework. You'll have to make sure that KubeClient can run in the version of netcore you're targeting.

Let's add a couple more packages:

dotnet add package microsoft.extensions.logging
dotnet add package microsoft.extensions.logging.console
dotnet add package newtonsoft.json

Open up the project using whatever editor you like and let's take a look at what KubeClient can do. First, let's add the logger:

class Program 
{
  static async Task Main(string[] args) 
  {
    ILoggerFactory loggers = new LoggerFactory();
    loggers.AddConsole();
  }
}

You'll notice I swapped the default void for async Task. This is a feature of C# 7.1 so if you're running something older than that, you'll need to stick to void and use GetAwaiter() in the code whenever asynchronous code shows up. Hopefully you're on 7.1 though, because that's ugly.

Below the loggers let's instantiate the KubeCpiClient:

var client = KubeApiClient.Create("http://localhost:8001", loggers);

Above code requires that you're running kube proxy and have proxy access to the cluster. To set that up, you need kubectl installed and an SSH key registered with the cluster. For more information, the official docs are actually not bad. Assuming you have all that set up, let's continue on with C#.

var nodes = await client.NodesV1().List();
var serializedNodes = JsonConvert.SerializeObject(nodes);
Console.WriteLine(serializedNodes, Formatting.Indented);

This should print out a list of nodes in your cluster. Great! Try this:

var pods = await client.PodsV1().List(null, "default");

When querying pods, you can provide the label and the namespace. If you don't provide the namespace, the default namespace is used. If you've been following my past articles, you can replace "default" with "integration" to get a list of pods in there.

You can also retrieve namespaces, services, jobs and more using the same syntax. Unfortunately, with the basic KubeClient, you cannot retrieve metrics. But wait... how then? The title of this article promised me...

One of KubeClient's chief perks is its extensibility. The library exposes the underlying ResourceClient and lets you build your own API queries on top of it. Anything the base KubeClient doesn't cover, you can build yourself. That's exactly what we're going to do in the next article.

Your code by the end of this article should look like this:

class Program 
{
  static async Task Main(string[] args) 
  {
    ILoggerFactory loggers = new LoggerFactory();
    loggers.AddConsole();

    var nodes = await client.NodesV1().List();
    var serializedNodes = JsonConvert.SerializeObject(nodes);
    Console.WriteLine(serializedNodes, Formatting.Indented);

    var pods = await client.PodsV1().List(null, "default");
    var serializedPods = JsonConvert.SerializeObject(pods);
    Console.WriteLine(serializedPods, Formatting.Indented);

    Console.ReadLine();
  }
}

I encourage you to see what else KubeClient has to offer. In the next article we'll build a KubeClient extension and get us some metrics.

As I mentioned in my previous articles on Kubernetes, intracluster communication is facilitated by something called Kubenet. Kubenet is a basic network plugin that does its job well but doesn't come with any bells and whistles like cross-node networking or policy management. If you're hosting your K8s cluster on Azure (or any other serious cloud provider), they will set up all the routing rules for your nodes and in some cases give you control over network policy configuration. In fact, Azure has an Advanced networking mode which gives you more control over the networking aspect of your cluster. You can read about Kubenet and Azure CNI here.

In essence, kubenet's job is to assign IP addresses to pods and resolve service hostnames to these IP addresses. When you add a new deployment with a pod and service, it's automatically assigned an IP address and immediately discoverable on your cluster. Let's say you've added a service like this:

apiVersion: v1
kind: Service
metadata:
  name: fancyapi-service
  namespace: integration
spec:
  selector:
    app: fancyapi
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 5000
  type: ClusterIP

Kubenet will assign this service an IP address (which you can view via kubectl get svc). To access this service from another service, you don't need to worry about using that IP address -- you can just use the name of this service; fancyapi-service.

An example in C# would look like this:

using (var client = new HttpClient()) {
  var result = await client.GetAsync($"http://fancyapi-service/v1/fancyproducts");
  if (result.IsSuccessStatusCode) {
    return JsonConvert.DeserializeObject<List<Product>>(await result.Content.ReadAsStringAsync());
  }
  return null;
}

We instantiate a new HTTP client (inside an async Task method) and call the fancyapi-service to get a list of products from the v1 controller. Kubenet will resolve fancyapi-service to the correct IP address and route the traffic appropriately. Easy as pie!

Ingress means "going in". In the K8s scenario, this means traffic going into the cluster. Egress, the anytonym of ingress, means going out. That would be the traffic leaving the cluster such the service sending data out from inside the cluster. An ingress controller (IC) is essentially a gateway into the cluster.

There are many different ICs to choose from, but we're going to focus on the K8s supported ingress-nginx project (not to be confused with nginx-ingress which is supported by the folks behind nginx). Both nginx ICs are good choices, and the nginx-supported one even has a 'plus' version you must pay for with some extra features. However, for our purposes, and quite honestly purposes of many production-bound projects, we're good with ingress-nginx.

You can visit the project website here.

On the site, you can visit the Deployment section -> Installation guide and click on Azure. You must run one command to install everything... but before you do that, we need to modify the installation file, because it doesn't include our SSL certificate. Go ahead and download the YAML file. You can either grab the linke from the official website, or just right-click here and Save As deploy.yaml.

The above YAML file is a master installer which will create a lot of artifacts in your cluster. It creates a namespace (we already did this step in the previous article, so nothing new will happen here), some ConfigMaps, a ServiceAccount, a ClusterRole and ClusterRoleBinding, some Roles and Services and of course a Deployment of a special version of nginx. There's a lot of stuff that's created but worry not! Our focus here is pretty narrow.

We must modify the nginx configuration to read our SSL certificate. The default nginx configuration which we get from the above installation does not include this important flag, so we must do it ourselves. Inside the downloaded YAML file, look for lines:

# Source: ingress-nginx/templates/controller-deployment.yaml
apiVersion: apps/v1
kind: Deployment

This is the deployment for the nginx ingress controller. If you scroll down a bit, you'll see where the container spec is defined and these lines:

args:
  - /nginx-ingress-controller
  ...

Go ahead and add this right after /nginx-ingress-controller

- --default-ssl-certificate=ingress-nginx/aks-ingress-tls

You should have this complete args:

args:
  - /nginx-ingress-controller
  - --default-ssl-certificate=ingress-nginx/aks-ingress-tls
  - --publish-service=ingress-nginx/ingress-nginx-controller
  - --election-id=ingress-controller-leader
  - --ingress-class=nginx
  - --configmap=ingress-nginx/ingress-nginx-controller
  - --validating-webhook=:8443
  - --validating-webhook-certificate=/usr/local/certificates/cert
  - --validating-webhook-key=/usr/local/certificates/key

Save the modified installation YAML and apply it

kubectl apply -f deploy.yaml

Halfway there! The ingress controller is created. One last step we need to take is to tell the ingress controller where to route the incoming traffic.

Inside your integration folder, create a new file; ingress.yml and put this inside:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: ingress-fancyapi
  namespace: integration
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - yourcooldomain.io
    secretName: aks-ingress-tls
  rules:
  - host: integration.yourcooldomain.io
    http:
      paths:
      - backend:
          serviceName: fancyapi-service
          servicePort: 80

There are a few new things here. First, we're adding an annotation. Annotations are metadata. In this case, we're attaching metadata required by the nginx ingress controller.

Next, in the spec map, we have tls and a list of hosts. I defined a made-up host and attached the secret we created in the previous article to it. For this to work however, you'll need to edit the A record of the domain first to point yourcooldomain.io to the IP address of the ingress controller, and second add a wildcard CNAME of *.yourcooldomain.io. (you are likely to need the . at the end there, as it's a standard) as well. Also, it's important that the host yourcooldomain.io is the same host you defined when creating your SSL certificate!

Both the A record and the wildcard CNAME need to point to the IP address of the ingress service. You can find this IP address via the following command:

kubectl get svc -n=ingress-nginx

External IP is what you're looking for. Assuming your IP is 1.2.3.4, here's an example of what your DNS records should look like:

Your domain address provider is likely to have instructions on how to set this up.

In the rules map, we have a list again, but only one item. Here, we're saying "hey when someone hits integration.yourcooldomain.io, I want them to go to the backend service fancyapi-service on port 80". When you create your production ingress file inside the production namespace, you will possible just have yourcooldomain.io without a subdomain, or maybe www.yourcooldomain.io or something.

Almost there! Go ahead and apply this config to the K8s cluster:

kubectl apply -f ingress.yml

If your domain provider has updated their DNS entries, you can visit https://integration.yourcooldomain.io and you should be warned by your browser that the SSL certificate cannot be trusted. Thankfully, you know you can trust it, because you created it! If you skip the warning in the browser, you should arrive at your service!

Congratulations! You now have a namespaced cluster with a running service, an ingress controller and integrated SSL certificate. This is the end of the series, but there are at least 3 more Kubernetes articles to come. They will build on the knowledge we've gained in this series.

Happy Kubernetesing!

Resources

• Annotations

In a production scenario, you'll want to get a real certificate from a trusted entity like Verisign or use Let's Encrypt. That's not related to Kubernetes though, so it's out of scope of this series.

Let's get started!

You're gonna need bash shell installed on your PC, or some way to run openssl. If you're on Linux or Mac, you're golden, but if you're on Windows like me, you may already have Git for Windows installed which comes with bash and thus openssl. Open bash and type in:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -out aks-ingress-tls.crt -keyout aks-ingress-tls.key

We're creating a new x509 certificate with RSA-2048 encryption valid for 365 days. We're also asking for crt and key files to be created. When you run this command, you'll be asked a few questions. The only thing that really matters is the company name. Everything else you can leave blank.

The crt and key files are created in the directory where you ran the command. I recommend you store them somewhere safe, perhaps in the same folder as your cluster definition YAML files.

In preparation for the next article, we're going to create a new namespace. This namespace was also created by the ingress controller installation YAML, but we need it now... not in the next article. Go ahead and create a YAML file named nginx-ingress.yml and add this to it:

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/instance: ingress-nginx

Apply it:

kubectl apply -f nginx-ingress.yml

This will create a new namespace where we'll store the ingress controller. We'll discuss why we want a new namespace in the next article, but for now, just trust me!

In the same directory as the crt and key files, you can now run the following command:

kubectl create secret tls aks-ingress-tls --namespace ingress-nginx --key aks-ingress-tls.key --cert aks-ingress-tls.crt

We're creating a secret in our cluster which we can then refer to later when creating the ingress controller and setting up TLS termination. This secret contains the certificate and the key we created earlier.

Great! We're now ready for the moment you've all been waiting for -- making our API service hosted inside our K8s cluster accessible to the public, complete with SSL support! That's coming up in the next article.

Resources:

• Secrets
• OpenSSL Commands

If you have pods which do not require communication with any other pods, then you don't need a service. This could be a cron job, or an app which listens to a queue and sends an e-mail. Services have several properties, but to get up and running you need just a few pieces in place. Let's create a fancyapi-service.yml file and toss this inside:

apiVersion: v1
kind: Service
metadata:
  name: fancyapi-service
  namespace: integration
spec:
  selector:
    app: fancyapi
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 5000
  type: ClusterIP

The interesting parts of this definition are in the spec map. First, we have the selector. You may recall from the last article about deployments that selectors let you grab objects which have tags assigned. In this definition, we're grabbing things tagged with app: fancyapi. Just so happens that our deployment has that tag!

The ports map is where you define how you want your pods to be accessible. In the above example, we're defining just one port named http using the TCP protocol. The next two values are important to get right:

• port is what other services will call this service on
• targetPort is the port that the container is exposing

In this example we're assuming the exposed port in the container is 5000 (default ASP.NET Core application port), but obviously yours may be different. This port is the same one you may have defined in your Dockerfile under EXPOSE property, or when you were building your container image with the -p flag.

The last thing we need to talk about is the type: ClusterIP. ClusterIP means the service will have an internal IP address assigned by K8s (kubenet specifically). Your service will not have an outside IP address. If you wanted to expose your service outside the cluster, you could do so by setting the type to NodePort. When you do this, K8s requests an IP address from the hosting service (in our case Azure) and then assigns a port to it. The port is usually in the 30000s range by default.

You could also expose it via type: LoadBalancer. We're going to use LoadBalancer a bit later in this article series when we set up an Ingress Controller. For now, let's stick to ClusterIP. Go ahead and apply this YML:

kubectl apply -f fancyapi-service.yml

Then check your services:

kubectl get services

You'll see a table with one item in it. It will have a CLUSTER-IP that starts with 10 and not have an EXTERNAL-IP. That's okay, we'll get there.

Most tutorials I found end here at this step. They'll tell you to use NodePort or LoadBalancer and call it good. Setting up an Ingress Controller is honestly not that difficult though, so I don't know why nobody goes further. We'll get started with the Ingress Controller in the next article by creating a local SSL certificate.

The way a service gets up into the cluster is via two main paths: Pod and Deployment. In YAML, you can define a pod, tell it what image to run and go! This will spin up a single pod in the cluster. As I mentioned in a previous article, pods can contain more than one container, but generally they don't. Pods have an finite lifetime and when they restart everything inside the pod gets lost. Any sort of data persistence inside a pod is thus moot.

There's a lot more to learn about pods, but for the sake of not getting bogged down in details, let's just understand pods as container instances. Great, let's move onto Deployments.

What is a Deployment?

An easy way to understand a deployment is as a definition of a microservice. A deployment is a wrapper around a pod or pods with additional functionality. You can define how many replicas of a pod you always want up. You can control a set of pods via the deployment instead of each individual pod. For example, if you have a deployment which defines 6 replicas of a pod, if you wanted to stop the pods, you'd have to individually shut down each one. Or... you just stop the deployment, and it stops all those replicas for you. You can scale the replicas up or down, and more! Check the link in resources below for a LOT more information about deployments.

Let's create a deployment! Call it 'fancyapi-deployment.yaml':

apiVersion: apps/v1
kind: Deployment
metadata:
  name: fancyapi-deployment
  namespace: integration
  labels:
    app: fancyapi
spec:
  replicas: 2
  template:
    metadata:
      name: fancyapi
      labels:
        app: fancyapi
    spec:
      containers:
        - name: fancyapi
          image: ...
          imagePullPolicy: Always
          env:
            - name: ASPNETCORE_ENVIRONMENT
              value: Integration
          resources:
            requests:
              cpu: 250m
              memory: 128Mi
            limits:
              cpu: 1000m
              memory: 512mi
        restartPolicy: Always
  selector:
    matchLabels:
      app: fancyapi

There's a lot going on here. Let's take a look piece by piece.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: fancyapi-deployment
  labels:
    app: fancyapi

This should be pretty standard by now. Creating a Deployment named fancyapi-deployment. Theoretically the -deployment is redundant, but when I kubectl get deployments and see the list, I like to be reassured I'm looking at deployments and not something else. Personal preference really. We add a label to the deployment named app with the value fancyapi.

Next, replicas.

spec:
  replicas: 2

This tells K8s that we always want at least 2 instances of the pod running. When adding this KVP, K8s creates a ReplicaSet in the background. We'll come back to it later.

Under the template map is where we define what every pod replica should look like. You're already familiar with the metadata, so let's skip right down to the spec.

spec:
  containers:
    - name: fancyapi
      image: ...
      imagePullPolicy: Always
      env:
        - name: ASPNETCORE_ENVIRONMENT
          value: Integration
      resources:
        requests:
          cpu: 250m
          memory: 128Mi
        limits:
          cpu: 1000m
          memory: 512mi
    restartPolicy: Always

The containers property is in plural, because as I mentioned in a previous article, you can host multiple containers in one pod. In our case we are gonna have a list with one item in it.

Much like everything else in the K8s world, a container needs a name. The image needs to be a URI pointing at the ACR. Let's say, for example, that your registry is called CoolContainerRegistry and that your image is called fancyapi and has a tag v1. You'll point it at ACR like this:

image: coolcontainerregistry.azurecr.io/fancyapi:v1

You'll need to find the URI of your registry in Azure Portal (or you can also find it using Azure CLI:)

az acr list | sls "loginServer"

The imagePullPolicy tells the container to always pull the image when it starts up. This ensures that when you restart your pods after a new release, the new image will be acquired.

There are multiple different strategies for deploying containers to pods. The strategy in this deployment is just one, where you use the same tag (v1) for every release. However, you may want to tag every release with a new version (like v1.16.3.879). This will make your image look like fancyapi:v1.16.3.879 and to ensure your pod's running the latest version, you'd have to use the kubectl set image command. Or more likely you have releases tagged with :int and :prod like in the scenario we've been building. In any case, you have options.

Next, we have the env list. This is a list of maps that contains the name of the environment variable and its value. You can add any environment variables you want your container to have right here. In the case of ASP.NET Core, you may want to inject the environment name. We're hardcoding it here, but there's a neat trick you can use, where you can use the Pod's metadata properties as environment variable values.

For example, if your pod is hosted in the namespace Production, you could inject the variable like this:

env:
  - name: ASPNETCORE_ENVIRONMENT
    valueFrom:
      fieldRef:
        fieldPath: metadata.namespace

This would make ASPNETCORE_ENVIRONMENT=Production and thus enable you to use production-specific appsettings.Production.json.

Right then. Next, we have the resources map with requests and limits child maps. If you recall the Resources discussion from an earlier article, these are pod-specific values.

Requests are what the pod is guaranteed to have (provided it's not over the namespace's request limit) and limits are what the pod is allowed to have at maximum. These values are extremely important to set! It will take some time to determine how much CPU and memory your service takes up, but once you have the rough numbers and set them, the cluster will manage everything for you. If your traffic somehow explodes, your entire cluster won't get hosed -- only the pod under load will get throttled (thus possibly resulting in 502s to calling users, but better than a total outage).

As an aside, when you have your microservices all nice and cozy in the cluster and you're ready to load test, check out artillery.io. I use this nodejs lib to hammer my APIs and collect results. Very handy tool.

Okay, lastly, we have the restartPolicy: Always. This tells the pod that we want it to restart whenever anything makes the container exit. This includes things like if the pod runs out of resources or there's a critical boot failure inside the container, or one of the containers inside the pod dies. It also includes positive events like the container gracefully exiting. In this case, the pod will restart itself and stay in 'Running' state. There are other policies like OnFailure and Never. These are handy for Cron/Jobs -- specifically Never, since you don't want a job to keep rerunning itself after it's finished... unless you do.

Great, almost done!

Last section is the selector:

selector:
  matchLabels:
    app: fancyapi

Here we have defined a label selector. You can see that this selector is on the same level as the template map. The selector applies to the deployment and is not part of the pod template. fancyapi is a label we added to pod template. If you look at the other two keys on this level, replicas and template, you can deduce that the deployment basically says _I want two replicas to run the container template with the label app: fancyapi. It's a bit confusing, isn't it? Leave it to Google to overcomplicate a concept and then not document it well.

Anyway, you now have your deployment YAML. Go ahead and apply it:

kubectl apply -f fancyapi-deployment.yaml

Let's see it in our cluster:

kubectl get deployments

We can also see that K8s spun up two pods for us, because we requested 2 replicas:

kubectl get pods

Hurrah! But wait... you have an API running now, but how do you access it from the outside? That's coming up in the next article!

Resources:

• Deployments
• Environment Variables
• Pod Restart Policy

Pods are individual instances of our microservice. They are wrappers around your Docker containers -- but they can contain more than just one container. You're unlikely to have more than one container running inside a pod, unless you need something like a timed cron-job or a queue listener which the main service running inside the pod depends on. That additional container is called a sidecar. To summarize, for simplicity's sake, a pod is an instance of a container with some K8s specific metadata.

Resource Quotas

We'll use resource quotas for individual pods in a future article. For now, let's focus on namespace-level resource quotas and limits. In our scenario we have two namespaces - Production and Integration. We're running these two environments on the same cluster, so we want to make sure that our Integration environment doesn't blow up Production when we run some tests. We can thus limit Integration to have a finite amount of resources available to it, while letting Production consume the rest.

To do this, we'll be writing a new YAML file. Inside the Cluster folder you created in the previous article add a new file resources.yml. Here's what it looks like to start:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resourcequotas
  namespace: integration
spec:
  hard:
    requests.cpu: 1500m
    requests.memory: 2Gi
    limits.cpu: 3000m
    limits.memory: 4Gi

Then, apply it:

kubectl apply -f resources.yml

Great, so, what did we do there? Let's talk about it.

The first few lines are the same as every other YAML file you're gonna write. The apiVersion, kind and metadata are all the same keys. The kind is of type ResourceQuota, because that's what we're adding! There's a new addition to the metadata map called namespace. This tells K8s to apply these settings to a specific namespace.

Next, we have the spec - short for specification. This map is where you define what you want the ResourceQuota to look like. The hard keyword tells Kubernetes that these are hard limits... that is, they cannot be skirted. If you define a pod which has a request.cpu higher than limit.cpu, it will fail to start.

Inside the hard map we have 4 KVPs. The values defined here are valid across all running pods and are a sum of all request and limit resources. Let's look at a scenario to illustrate:

PodA requests 100m. PodB requests 300m. PodC requests 1000m. Total, the requests are 1400m. That's within the hard limit of 1500m, so we're okay. If the sum of all requests from our pods exceeds that of the request quotas, some of the pods will fail to start. Same goes for limits.

You might be wondering ... what is 1500m? 'm' stands for millicpu, or 1/1000th of a CPU. When you provision your cluster, you pick the size of your nodes. For example, you might have 2 vCPUs per node and 8GB of memory. 2 vCPUs is 2000m. 4 vCPUs is 4000m. You can also use decimals for CPU: 0.1, 0.3, 1. That's, 100m, 300m and 1000m respectively. Usually, you'll want to stick to the M notation, but just know that decimals are possible.

For memory, you can use GB, MB, Kb for 1000 or Gi, Mi, Ki for 1024... etc. Nothing new here.

Okay great, we have our quotas for the integration environment! Let's take at one more thing - Limit Ranges.

Limit Ranges

Resource quotas set limits on namespaces. However, they do not set limits on individual pods. This means that even though a rogue, untested microservice in integration won't bring down our cluster, it may bring down our integration environment! That's because within a namespace, a pod may consume as much memory as it wants. That's where limit ranges come in.

Let's define one, then talk about it. Inside the same resource.yml file, after the last written line, add the following:

---

apiVersion: v1
kind: LimitRange
metadata:
  name: limitranges
  namespace: integration
spec:
  limits:
    - default:
        cpu: 300m
        memory: 256Mi
      defaultRequest:
        cpu: 10m
        memory: 128Mi
      max:
        cpu: 600m
        memory: 1024Mi
      min:
        cpu: 10m
        memory: 32Mi
      type: Container

Let's say you have a pod in which you don't specify request or limit values (remember, you can specify these on pod level -- we'll get to it in a later article). With the LimitRange set for the namespace, said pod would automatically get the default limit/request values under default/defaultRequest.

The max and min maps specify limits that an individual pod can define inside its YAML file. If you have a pod where you DO define these limits, they cannot exceed the limits defined in the namespace. These limits are meant to ensure the stability of the cluster.

Lastly, we assign these limits to a container via the type KVP. As I mentioned above, a pod is a wrapper around a container or multiple containers. If you have two containers inside a pod, each one would get the defaults and max/min values defined above.

Go ahead and apply the limit ranges:

kubectl apply -f resources.yml

Summary

Defining request quotas and limit ranges at namespace level ensures that the cluster won't get hosed. In addition to CPU and Memory resource limits, there are also object limits. You can limit how many pods can run inside a namespace for example. We didn't touch on those here, but it's possible. Check the resources at the bottom of this article for more information.

You can view more information about the integration namespace and see the resource quotas and limits with this command:

kubectl describe namespace integration

In the next article we'll introduce Deployments.

Resources

• Resource Quotas
• Limit Range

We're going to be using the YAML declarative language to create all our objects in our K8s cluter. It's also possible to do all this via the kubectl command, but quite frankly, that's silly. Just FYI though, you can create namespaces, deployments, pods, and other things via kubectl, you just shouldn't.

When we write a YAML file, we'll then apply it with this command:

kubectl apply -f .\namespaces.yml

You'll be using the apply command a lot. Applying a YAML file tells the K8s cluster what you want some piece of it to look like. If you're confused, worry not, it will all become clear as we go along!

Go ahead and create a new folder where you'll be storing your YAML files. Inside that folder, create two new folders: Cluster, Services. We want to keep the cluster setup separate from the rest of your YAML files.

Inside the Cluster folder, create a file namespaces.yml. We're going to create two namespaces: Integration and Production. In a real-world scenario, you'd also want at least a Staging namespace in addition to the two aforementioned ones, but here we'll be fine with just two.

Inside the new namespaces.yml file, add the following code:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    name: prod

---

apiVersion: v1
kind: Namespace
metadata:
  name: integration
  labels:
    name: int

One thing to note, when writing YAML, you do NOT want to use tabs. Always use spaces. The number of spaces is up to you, but no tabs! It will fail to parse when applying if you use tabs.

Let's check to make sure kubectl works and you see the nodes you created in the previous step.

kubectl get nodes

You should see two nodes. If you don't, ensure you're targeting the right context (cluster). You can use the az aks commands to do this.

If you see two nodes, you're good to go. Let's apply this YAML file to the cluster, then discuss its contents.

kubectl apply -f .\namespaces.yml

You'll see something like this:

namespace/production created
namespace/integration created

Okay, let's look at the YAML real quick. The first key-value pair (KVP) is apiVersion: v1. Kubernetes is an evolving project and there have been lots of different versions of definition syntax. It's pretty confusing which version should be used and when even to a seasoned K8s navigator. In this case, we're using v1.

Next, the KVP kind: Namespace tells K8s that this definition is for a Namespace object. Pretty self-explanatory.

Then we have a metadata map. The first KVP is name: production. As you guessed, this sets the namespace's name.

Last, we have the labels map with a label KVP name: prod. Labels are used to organize and group things... as in any other service. For example, in Azure, you can add tags to any entities you create. Same concept. If you create additional objects, you can add the same label name: prod. Labels are not unique.

Okay! Now that you know what's what, let's see your namespaces.

kubectl get namespaces

You'll get a list of namespaces, along with Status and Age properties. There's a default namespace, that's where all objects go if you don't specify a namespace for them. There are some kube-* namespaces which are system namespaces. Lastly, your two namespaces should be there as well.

By default, all your kubectl commands go against the default namespace. To make things more convenient when applying all YAML configuration files later, we're going to set the integration namespace as our default instead. You can use the kubectl config set-context --current --namespace=integration command to do that. Alternatively, if you don't want to set your current context, you can add -n integration after every command you type. I think setting the context is more convenient, but it's your call.

Let's leave it here. In the next article, we'll talk about Resource Quotas and Limit Ranges. We don't want our microservices to go rogue and bring down our entire cluster...