Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

"Project Tye to Tie .NET Microservices", Oleg Karasik

•Download as PPTX, PDF•
•
Fwdays
Fwdays

In this talk, Oleg will explain and show how you can simplify (and maybe even speed up) the development of modern .NET applications based on micro-service architecture and aimed at deployment in Kubernetes. We will also talk about a young and promising Tye project from Microsoft. We will look at what the Tye project is and how it simplifies the development process, both with examples from several .NET microservices and with more complex examples that involve interaction with external services.

1 of 29
"Project Tye to Tie .NET Microservices", Oleg Karasik
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

More Related Content

"Project Tye to Tie .NET Microservices", Oleg Karasik

  • 2. 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.
  • 3. What is modern .NET application? Modern .NET application - is an application with all latest and greatest.
  • 4. What does «latest and greatest» mean in .NET? A group of .NET developers from development club
  • 5. What does «latest and greatest» mean in .NET?
  • 6. What does «latest and greatest» mean in .NET?
  • 7. 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.
  • 8. 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.
  • 9. 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.
  • 10. 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.
  • 11. What is modern .NET application? (cont.) Modern .NET application - is an application with all latest and greatest, which are: • .NET 5 • Microservices • Cloud • Kubernetes
  • 12. Modern .NET application in imagination > High load detected. Scaling out... > No load detect. Scaling in. > Routing requests > Outage. Restoring... > Operational. > Incoming requests
  • 13. 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.
  • 14. Cons of modern .NET apps in development (#2) High overhead when multiple services are involved in both development and debugging scenarios.
  • 15. 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.
  • 16. 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.
  • 17. 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.
  • 18. 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.
  • 19. 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.
  • 21. 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.
  • 22. 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 "…"
  • 23. 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.
  • 24. 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
  • 25. 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.
  • 26. 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.
  • 27. DEMO
  • 28. … and tye can do more! Besides mentioned and demonstrated things tye supports: • Integration with DAPR • Azure Functions • Distributed Tracing • Elastic Stack • … and more!

Editor's Notes

  1. (следующий слайд)
  2. Здравствуйте, меня зовут Олег и я разработчик *щелк* :) За более чем 10 лет я работал на разных проектах, от больших до маленьких, но почти все они в той или иной степени были связаны с веб-разработкой на .NET. Помимо основной работы, я периодически вношу свой небольшой вклад в open source и веду блог, где каждый месяц публикую подборку о .NET и не только. *пауза* Теперь, когда мы немного познакомились, я бы хотел поговорить о современных .NET приложениях. (следующий слайд)
  3. Какое приложение на .NET можно назвать «современным»? *короткая пауза* Немного шутя, можно ответить, *щелк* что это «приложение в котором все самое-самое». Но что входит в это «самое-самое»? (следующий слайд)
  4. Никто не может знать ответ на этот вопрос лучше чем сами разработчики. Поэтому я пригласил сюда нескольких ребята из клуба разработчиков и попросил их поделится своим мнением. (следующий слайд)
  5. (анимация)
  6. (конец анимации)
  7. .NET 6. *короткая пауза* Полностью согласен. Сейчас, когда .NET Framework находится в стадии поддержки, а все силы разработчиков направлены на .NET 6. Это без сомнения попадает в категорию «самое-самое». (следующий слайд)
  8. Микросервисы. *короткая пауза* Конечно. Наверное никто не хочет работать над огромным монолитом состоящим из спагетти кода, singletons и прочих прелестей беспорядочной разработки. (следующий слайд)
  9. Облака. *краткая пауза* Сейчас без этого никуда. Использование облачных технологий на самом деле значительно упрощают разработку и позволяют сконцентрироваться на решении проблем, вместо изобретения очередного колеса. (следующий слайд)
  10. Kubernetes. *короткая пауза* Хороший выбор. Особенно учитывая, что использование Kubernetes означает использование контейнеров, а это несомненно является частью того «самого-самого». (следующий слайд)
  11. Полученный список выглядит интригующе. *пауза* Смотря на него, можно представить… *пауза* (следующий слайд)
  12. Высоконагруженную систему, обслуживающую тысячи *короткая пауза* и тысячи запросов в секунду. *пауза* Систему, которая самостоятельно масштабируется *короткая пауза* и восстанавливается в случае ошибок. *пауза* Завораживающее. Однако в этой идеальной картинке, кое-чего не хватает, а если быть точным, не хватает там сложностей связанных с разработкой таких приложений. (следующий слайд)
  13. И первое, что приходит на ум это настройка связи между сервисами в приложении. Когда представляешь микросервисы, они как правило уже общаются между собой, но ведь это общение необходимо организовать. В development это как правило реализуется *щелк* через перечисления URL и connection string прямо в конфигурационном файле каждого сервиса. Наличие такой конфигурации вынуждает разработчиков *щелк* следить за адресами и пересечение портов. И в это нет ничего страшного пока это два сервиса. Однако когда таких сервисов становится 5? 10? 20? Но ведь это еще не все. Теперь нам нужно поддерживать конфигурацию в других *щелк* environment. И не важно, будет это именно в конфигурационных файлах или *щелк* в коде. Нам необходимо это делать. Нам необходимо за этим заниматься. (следующий слайд)
  14. Но это только начало. Помимо этого, в микросервисных приложениях полно сложностей связанных непосредственно с процессом написание и отладки кода. (следующий слайд)
  15. В частности, если код наших сервисов находится в разных репозиториях это приводит к необходимости скачивать и обновлять каждый репозиторий в отдельности. Затем, сервисы из этих репозиториев необходимо по отдельности собрать и запустить. И так каждый раз, *пауза* при каждом обновлении. Очень часто это приводит к тому, что у нас открыто по 10 студий, мы постоянно перепрыгиваем между ними, останавливаем отладку не того сервиса, а иногда даже собираем не тот сервис. (следующий слайд)
  16. И если говорить откровенно, ситуация не становится легче если весь код размещается в одном репозитории. Ведь теперь, если мы используем один solution, нам чтобы собрать один сервис, необходимо руками выбрать нужный проект, либо же собрать все. Или мы можем написать скрипты и сделать отдельные solution для каждого сервиса, что по сути возвращает нас к уже описанным проблемам и 10 окнам студии. (следующий слайд)
  17. А теперь представьте, что часть этих сервисов вообще может быть запущена только в виде контейнера. Или еще лучше, что например часть сервисов которые вам нужны распространяются как контейнеры. В этом случае, ко всему выше перечисленному, нам придется еще собирать и обновлять images этих контейнеров, запускать их локально, причем так, чтобы они не конфликтовали с другими сервисами. (следующий слайд)
  18. Но и это еще не все. Ведь помимо самого кода, нам необходимо поддерживать такие инфраструктурных элементы как Dockerfile и Kubernetes manifest. Причем в каждом сервисе. *пауза* И да, это именно необходимость. Ведь если мы говорим о микросервисах, то зачастую эти элементы не содержат никакой «хитрой» логики, а являются типовыми и шаблонными. *пауза* При этом обращение с ними часто приобретает прямо ритуальный характер *щелк*. По моему опыту это достаточно распространённый случай, когда однажды созданный кем-то Helm chart копируют от сервиса к сервису как черный ящик. При этом, никто уже и не знает, что там внутри. И это работает. *пауза* И работает именно потому, что там нет и никогда не было никакой «хитрой логики». И на самом деле типовой helm chart, как и Dockerfile может быть легко сгенерирован машиной. (следующий слайд)
  19. При желании, этот список сложностей можно продолжать. *щелк* Однако, все ровно понятно, что со всеми этими сложностями можно «мирится» иначе таких проектов просто бы не было. *щелк* Но сегодня, я хочу вам рассказать и показать, что все это можно обойти. (следующий слайд)
  20. И сделать это нам поможет проект tye. (следующий слайд)
  21. Проект tye призван облегчить разработку микросервисных приложений. *щелк* С точки зрения разработки, tye упрощает сборку, запуск и администрирование микро-сервисов. *щелк* С точки зрения развертки, tye автоматически генерирует Dockerfile, загружает image в container registry и разворачивает их на Kubernetes кластере при помощи автоматически сгенерированного Kubernetes manifest. (следующий слайд)
  22. Физически же, tye представляет собой dotnet tool. *пауза* Вот так просто. *щелк* И поэтому, все что нужно сделать, чтобы получить tye в свое распоряжение это установить его одной командой. *пауза* *щелк* а потом, если вы планируете заниматься разверткой, то еще установить Docker, Kubernetes, развернуть container registry. Хотя если вы работаете или собираетесь работать с микросервисами, то перечисленные инструменты и так должны присутствовать на вашей рабочей станции. (следующий слайд)
  23. После установке, tye предоставляет нам целый набор команд. Мы не будем рассматривать их все а остановимся только на двух из них - run и deploy, поскольку именно они делают основную работу. (следующий слайд)
  24. Начнем с команды run. Основным параметром этой команды является путь к tye,yaml (о котором мы поговорим позже), *.sln или проектному файлу. Как только tye обнаруживает свою цель, *щелк* он сканирует её на наличие сервисов. *щелк* Затем, выполняет сборку каждого сервиса. *щелк* После чего запускает их на выполнение. *щелк* Параллельно с этим, tye запускает так называемый dashboard – небольшое веб-приложение позволяющее получить информацию о запущенных сервисах. Важно отметить что: *щелк* «сборка» сервиса на самом деле может представлять собой как в прямом смысле сборку исполняемого файла из исходных кодов, сборку image из Dockerfile, загрузку image из container registry или даже клонирование git репозитория и повторением в нем процесса сборки. *щелк* во время запуска, каждый сервис при через переменные окружения получает информацию об адресах остальных сервисов, таким образом, нам нет необходимости самостоятельно настраивать общение между сервисами. (следующий слайд)
  25. При выполнении команды deploy описанный цикл практически полностью повторяется за исключением следующего: *щелк* Не запускается dashboard. *щелк* Все сервисы собираются в image, поэтому если сервис собирался из исходников, то теперь он будет собран при помощи автоматически сгенерированного Dockerfile. После сборки, все эти images загружаются в container registry. *щелк* Все сервисы получают автоматически сгенерированные Kubernetes манифесты, которые применяются на Kubernetes кластере. (следующий слайд)
  26. Под капотом, при выполнение run & deploy команд, tye использует существующие инструменты. *щелк* Так, сборка .NET проектов выполняется с помощью dotnet cli. *щелк* Сборка и загрузка container images – при помощь docker cli. *щелк* Процедура развертки в Kubernetes кластер – при помощи kubernetes cli, *щелк* а клонирование репозиториев при помощи git. Использование существующих инструментов позволяет нам, как пользователям tye выполнить настройку всех эти инструментов не взаимодействуя с tye, не подстраиваясь под него и не боясь, что он каким-либо образом вмешается в это. (следующий слайд)
  27. Ну, а теперь, когда мы прошлись по основным моментам, я предлагаю перейти от слов к делу и познакомится с tye поближе. (следующий слайд)
  28. Помимо всего что мне удалось рассказать и показать, tye поддерживает: *щелк* новейший DAPR runtime. *щелк* Azure Functions. *щелк* Distributed Tracing. *щелк* Elastic Stack. *щелк* и многое другое. И что важно, все это обходится минимальным вмешательством в код наших проектов и просто работает от одной команды - tye run. (следующий слайд)
  29. Спасибо за внимание! И обязательно попробуйте tye! (конце презентации)