About me
Oleg Karasik
Technology Lead in ISsoft, Minsk, Belarus
• More than 10 years of software development experience.
• Occasionally contribute to open source.
• I blog at https://olegkarasik.wordpress.com/ and curate a
monthly ‘.NET R&D Digest’ newsletter about .NET.
• Besides blog, you can find me on Twitter: @OlegKarasik1.

What is modern .NET application?
Modern .NET application - is an application with all latest and greatest.

What does «latest and greatest» mean in .NET?
A group of .NET
developers from
development club

What does «latest and greatest» mean in .NET?

What does «latest and greatest» mean in .NET?

What does «latest and greatest» mean in .NET?
.NET 6!
Because .NET Framework is in maintenance
and all new features are made for .NET 6.

What does «latest and greatest» mean in .NET?
MICROSERVICES!
Because I don’t want to work on huge monolith
monolith full of spaghetti code, cargo cults and
cults and all mighty singletons.

What does «latest and greatest» mean in .NET?
CLOUD!
Because Clouds simplify things and allow to
allow to focus on actual development and not
and not reinventing a wheel.

What does «latest and greatest» mean in .NET?
KUBERNETES!
Because Kubernetes provides load balancing, effective
effective hardware utilization, self-healing, secret
management and much more.

What is modern .NET application? (cont.)
Modern .NET application - is an application with all latest and greatest,
which are:
• .NET 5
• Microservices
• Cloud
• Kubernetes

Modern .NET application in imagination
> High load detected. Scaling out...
> No load detect. Scaling in.
> Routing requests
> Outage. Restoring...
> Operational.
> Incoming requests

Cons of modern .NET apps in development (#1)
Complex implementation of service discovery to configure and find
addresses of application services, databases or external services.

Cons of modern .NET apps in development (#2)
High overhead when multiple services are involved in both development
and debugging scenarios.

Cons of modern .NET apps in development (#2.1)
When all services are in separate repositories this leads to …
• … a need to clone, build and start multiple services manually or using
separate scripts;
• … a need to have multiple IDE windows open or need to manually
attach to every required service.

Cons of modern .NET apps in development (#2.2)
When all services are in the same repository this leads to …
• … a need to build all services to debug one service or to have a
separate solutions for each service.

Cons of modern .NET apps in development (#2.3)
When some services can be run only as containers this leads to …
• … a need to manually build / pull and run required images in local
host;
• … a need to keep local configuration in sync with source service
configuration.

Cons of modern .NET apps in development (#3)
An obligation to have and support infrastructure elements such as:
• Dockerfile
• Kubernetes manifest or Helm charts
Come here my
young colleague.
Take this.
Project veteran
Project newbie
What is this?
It is something our ancestors
have created a long before our
time. It is called the Helm
chart. Put it into your project
and it will make himself in a
cloud.

Cons of modern .NET apps in development
(summary)
It is possible to continue the list of concerns.
However, it is obvious – these concerts aren’t critical. They just make
development slower and less fun.
But there is a way around them.

Tye
Project

What is “tye”? (#1)
Tye is a project that is intended to make development, testing, and
deployment of microservices easier.
In development, “tye” helps to build, start and orchestrate execution of
your microservices.
In deployment, “tye” auto-generates container images, pushes them to
container registry and deploys them to Kubernetes cluster using auto-
generated Kubernetes manifest.

What is “tye”? (#1.1)
Tye – is a dotnet tool.
So, all you need to do to get tye is to execute this simple command:
… and in case of deployment, install Docker, Kubernetes command-line
(kubectl), have container registry and have access to Kubernetes
cluster.
dotnet tool install -g Microsoft.Tye --version "…"

Tye commands
Tye exposes the following commands:
• init - create a tye.yaml (discussed later)
• run - run an application locally (for development)
• build - build an application's containers.
• push - push an application's containers.
• deploy - deploy an application (for deployment)
• undeploy - remove a deployed application.

Run, Tye, run!
Dashboard
*.sln
*.csproj
tye.yaml
build
start
build
start
tye run
Information & Monitoring
On start, each service is configured with:
• addresses of other services through
environment variables.
A “build” can be:
• literally building a service from sources or an image from Dockerfile
• pulling container image from container registry
• cloning a git repository and doing one of the above-mentioned things

Deploy, Tye, deploy!
tye deploy command execution is very similar to tye run, except:
• No dashboard.
• All services are normalized to container images (so, if service was
built from sources, now it will be build using autogenerated
Dockerfile) which are pushed to container registry.
• All services receive autogenerated Kubernetes manifests which are
applied to Kubernetes cluster.

How run and deploy commands do these things?
To perform its job tye intensively leverages existing infrastructure and
tooling:
• To build C# or F# project tye uses dotnet cli.
• To build, pull or pushing container images tye uses docker cli.
• To apply Kubernetes manifest to a cluster tye uses kubectl.
• To clone git repository tye uses git.

DEMO

… and tye can do more!
Besides mentioned and demonstrated things tye supports:
• Integration with DAPR
• Azure Functions
• Distributed Tracing
• Elastic Stack
• … and more!

CTRL+C
Oleg Karasik olegkarasik@coherentsolutions.com