Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

.NET Cloud-Native Bootcamp

119 views

Published on

Slides from the .NET Cloud-Native Bootcamp, hosted by Pivotal, Microsoft, and Magenic in New York and New Jersey on April 9th & 11th, 2019.

Published in: Software
  • Be the first to comment

  • Be the first to like this

.NET Cloud-Native Bootcamp

  1. 1. .NET Cloud-Native Bootcamp
  2. 2. Goal of this boot camp. Introduce you to practices, platforms and tools for building modern .NET applications.
  3. 3. Hi there. Who are we?
  4. 4. 9-9:15AM Introduction 9:15-9:30AM Getting good at software 9:30-10AM All about microservices 10-10:15AM What’s cloud-native all about? 10:15-10:45A M Introducing Cloud Foundry 10:45-11AM BREAK TIME 11-12:30PM Cloud-native .NET technologies and patterns 12:30-1PM LUNCH 1-4PM Hands on exercises 4-4:30PM Wrap up
  5. 5. Why do you need to be good at software? Customers expect it. Meet demand to operate at scale. Gives you more business options. Your competitors are doing it. It makes everyone happier.
  6. 6. Ok, but how do I know that I’m doing well at software? Improved speed. Faster cycle time, more frequently deployments. Improved scale. More requests per second to apps and services. Improved stability. Greater uptime of customer-facing service. Improved security. Achieving 100% patch coverage. Improved simplicity. Reduce complexity of processes and tools.
  7. 7. What are microservices? It refers to an architectural style that supports constant change in your environment. This is accomplished by creating applications out of independent, loosely-coupled, domain-oriented services.
  8. 8. Microservices architecture Monolithic architecture Single focused services. Software solves many challenges in one software package. Loosely coupled. Tightly coupled. Delivered continuously. Delivered all together, on a schedule. Scale independently. Scale everything together. Independent teams own service lifecycle. Many teams own pieces of the service lifecycle. Emphasis on distributed systems patterns. Emphasis on delivery and organizational processes. Diverse technologies managed through automation. Single, long-lived technology stacks. Short onboarding period for new developers. Larger codebase requires significant time to ramp up new team members.
  9. 9. Moving to microservices ? Here’s what to consider. Do you have a pressing reason to do it? Can you rearrange your teams? Are you ready to decompose your monoliths? How will you decompose? Are you currently doing CI / CD? Is your production environment automated? How will you discover services at runtime? What can you do to prevent cascading failures? Are you ready to evolve your data platforms? Do you need to modernize your messaging and event stream processing toolchain? Are you ready for modern logging, monitoring?
  10. 10. What is “cloud-native” all about? This is an approach to building and operating software that takes advantage of the cloud- computing model. Often seen as a combination of microservices, continuous delivery, containers, and DevOps. It’s all about software that’s built for scale, built for continuous change, built to tolerate failure, built for manageability.
  11. 11. Most cloud-native applications comply with the 12 factor criteria. •  One codebase tracked in version control •  Explicitly declared dependencies •  Configurations stored in the environment •  Backing services treated as attached resources •  Separate build, release, and run stages •  Apps executed as stateless processes •  Services exported via port binding •  Scaled out via more processes •  Fast startup and graceful shutdown •  Parity among dev, staging, and production environments •  Logs treated as event streams •  Admin tasks run as one-off processes
  12. 12. There’s a maturity model on your way to cloud native. •  No file system dependency •  Self contained application •  Platform managed ports/address •  Consume off-platform services Cloud Ready •  Twelve factor app •  Horizontal scalable •  Leverage platform for HA Cloud Friendly •  Designed for failure •  Apps unaffected by dependencies •  Proactive failure testing •  Metrics and monitoring baked in •  Cloud agnostic runtime Cloud Resilient •  Microservice architecture •  API-first designCloud Native
  13. 13. So, what actually makes up a cloud-native platform?
  14. 14. Pivotal Cloud Foundry Architecture DYNAMIC ROUTE SERVICES / API MANAGEMENT APP MICROSERVICES TECHNOLOGY Spring Boot Steeltoe Spring Cloud Services DATA MICROSERVICES TECHNOLOGY Spring Cloud Data Flow Cloud Cache RabbitMQ MySQL YOUR APPLICATIONS PLATFORM Elastic Runtime Concourse App Autoscaler PCF Metrics CredHub Orgs, Spaces, Roles and Permissions EMBEDDED OS CLOUD ORCHESTRATION CONTAINER ORCHESTRATIONWindows Linux Amazon Web Services Microsoft Azure Google Cloud Platform Open Stack VMWare SERVICE BROKER API PIVOTAL APPLICATION SERVICE PIVOTAL CLOUD FOUNDRY BOSH MODERN CLOUD NATIVE PLATFORM MULTI CLOUD
  15. 15. 15 App Manager UI Application Manager Service Service Broker Service Nodes Service Broker Service Nodes Service Services Service Broker Service Nodes Service CLI – Cmd Line Terminal Window Platform Runtime - Cloud Foundry App Log Aggregator Login Server Dynamic Router Cloud Controller UAA Diego Messaging (NATS) Metrics Collection HA Proxy LB CC-Bridge Rep Executor Rep Executor + = BBSAuctioneer Windows Cell Linux Cell
  16. 16. PCF 2.0 Any App Every Cloud One Platform
  17. 17. 17 Deploying .NET applications? It doesn’t have to be terrible. Traditional .NET deployment on VMs Pivotal Cloud Foundry Provision a VM Configure IP, DNS Configure firewall Windows updates, reboot… Install IIS Deploy application Configure app pool Configure SSL Configure load balancer ~$ cf push
  18. 18. ~$ cf push Code Complete & Tested Find available hosts Install & configure runtime Install & configure middleware Pull application source code Retrieve dependent libraries Create application package Install, configure dependent service(s) Deploy container to host(s) Load environment variables Configure load balancer Configure firewalls Update service monitoring tools Configure log collector Application in Production 45 seconds later
  19. 19. $ cf push my-app -p target/myapp.jar or $ cf push my-app --docker-image pivotal/my-image
  20. 20. Buildpacks are language-aware
  21. 21. Deploy source code that the platform containerizes for you or Deploy container images that you build yourself
  22. 22. Deploy source code that the platform containerizes for you or Deploy container images that you build yourself push source code Developer Cloud Foundry Cloud Controller triggers staging Diego creates container Diego mounts root file system Diego lays down buildpack, source code Diego builds and uploads droplet Diego schedules containers onto Cells Running app!
  23. 23. Deploy source code that the platform containerizes for you or Deploy container images that you build yourself Push Docker image Developer Cloud Foundry Cloud Controller triggers staging Diego spins up container to get metadata Cloud Controller stores metadata Diego schedules container onto Cells Running app! Generate and upload image Developer Create Dockerfile Developer Identify base Docker image Developer Package source code Developer
  24. 24. Cloud Foundry offers exceptional support for containers at runtime. Builds OCI-compatible containers Generates both Linux and Windows containers Option to SSH into running containers Can rebuild containers to patch root file system Performs log aggregation and correlation Offers monitoring and auto scaling of containers Introduces policy-driven container networking Can attach persistent storage volumes Intercept traffic via Route Services Securely connect to outside services via Broker Secure-by-default approach to containers
  25. 25. •  Application manifests tells cf push what to do with applications •  What OS stack to run on: Windows or Linux •  How many instances to create and how much memory to use. •  Helps automate deployment, specially of multiple apps at once •  Can list services to be bound to the application •  YAML format – http://yaml.org Define application metadata in a manifest file.
  26. 26. 26 Things about Pivotal Cloud Foundry you should know. ▪  Built for multi-tenancy ▪  Push code or containers ▪  Application manifests written in YAML ▪  Injects environment variables ▪  Aggregates app logs, correlates with metrics ▪  Monitors app health, reacts ▪  Scale manually or automatically ▪  Built in data services, marketplace ▪  Manages apps and underlying VMs ▪  Natively runs on multiple IaaS platforms ▪  Four layers of high availability built in ▪  Access via GUI, REST API, CLI ▪  Dev GUI = Applications Manager ▪  Ops GUI = Operations Manager
  27. 27. demo
  28. 28. break time
  29. 29. .NET is a unified platform
  30. 30. THREADING Threads • Thread Pool • Tasks IO Files • Compression • MMF DATA DataSet • DataTable • SQLClient APIs in .NET Standard 2.0
  31. 31. THREADING Threads • Thread Pool • Tasks IO Files • Compression • MMF DATA DataSet • DataTable • SQLClient APIs in .NET Standard 2.0 https://github.com/dotnet/standard
  32. 32. What’s the story with .NET Core? Cross-platform runtime, library, compilers Fully open source Modular and built on NuGet packages Still a subset of .NET Framework scope Strong CLI tooling available .NET Core != ASP.NET Core
  33. 33. What’s the story with ASP.NET Core? Runs cross framework (.NET Core everywhere, and .NET Framework on Windows) Fully open source Handful of supported project types Can deploy as completely self-contained Multiple hosting options Dependency injection baked in Support for external configuration
  34. 34. The dotnet CLI tool dotnet new dotnet add | remove package dotnet restore dotnet build dotnet run dotnet test dotnet publish
  35. 35. Cloud-Native .NET
  36. 36. Where to run cloud-native .NET apps? Pivotal Cloud Foundry •  .NET 4.x support (web apps, web services, console apps) on Windows. •  Resource and namespace isolation on Windows. •  .NET Core support (web apps, web services, console apps) on Windows or Linux. •  Buildpacks for Hostable Web Core (HWC) on Windows and .NET Core on Linux. •  Connect to service brokers for application services •  Native support for health monitoring, autoscaling, log aggregation, container metrics, and more.
  37. 37. PAS for Windows Powered by Windows Server containers Premium experience for .NET workloads For legacy apps, access to file system, registry, GAC Administrator and developer have SSH capability Use Windows Event Log drains Makes it possible for us to add better autoscaling, C2C networking Remote app debugging enabled
  38. 38. Building 12 factor ASP.NET applications Avoid in-process session state For ASP.NET override MachineKey in web.config and on ASP.NET Core avoid persisting keyring to filesystem On ASP.NET avoid environment specific configuration in web.config Avoid Integrated Windows Authentication Avoid the GAC Avoid custom IIS handlers Avoid anything that uses the Windows registry Avoid using local disk, especially for storing application state Avoid using any Windows specific or disk based logging Avoid any 32-bit specific libraries or libraries that can’t be bin deployable
  39. 39. How to implement cloud-native patterns? Java users have Spring and NetflixOSS. + = Spring Cloud •  Service registration and discovery •  API gateway •  Client-side load balancing •  Git-backed configuration store •  Circuit breakers •  OAuth 2.0 security support •  Distributed tracing •  Event-driven microservices •  Orchestrated data pipelines
  40. 40. Pivotal packaged up key Spring Cloud capabilities into a managed bundle for Pivotal Cloud Foundry called Spring Cloud Services.
  41. 41. Enabling cloud-native .NET apps. Fully open source, part of .NET Foundation For .NET Framework or .NET Core Run on Cloud Foundry, or anywhere Includes: •  Configuration server provider •  Service discovery with Netflix Eureka •  Connectors to OSS data, messaging technology •  Security providers •  Circuit breaker with Netflix Hystrix •  Actuators •  Coming soon: .NET Core 2.0, SQL Server connector, distributed tracing
  42. 42. Microservices Configuration
  43. 43. Steeltoe Configuration Providers •  Built on ASP.NET Core Configuration & Options extensions •  https://github.com/aspnet/Configuration •  https://github.com/aspnet/Options •  https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration •  Two custom providers •  CloudFoundry •  ConfigServer •  Application type support •  ASP.NET - MVC, WebForm, WebAPI, WCF •  ASP.NET Core •  Console apps (.NET Framework and .NET Core)
  44. 44. Steeltoe Config Server Client Provider •  Enables Spring Cloud Config Server to be used as a configuration source •  OSS Config Server - Steeltoe.Extensions.Configuration.ConfigServerCore •  SCS Config Server - Pivotal.Extensions.Configuration.ConfigServerCore •  Application type support •  ASP.NET - MVC, WebForm, WebAPI, WCF •  ASP.NET Core •  Console apps (.NET Framework and .NET Core)
  45. 45. Spring Cloud Config Server Overview •  Supports different back ends •  Local or remote git repos •  Hashicorp Vault •  File System •  Exposes resource HTTP API •  Default starts on port=8080 •  Configuration pulled by •  AppName •  Profile •  Label – optional
  46. 46. Spring Cloud Config Server Overview •  Serves resources: •  /application.yml •  /application.properties •  /application-{profile}.yml •  /application-{profile}.properties •  /{appname}-{profile}.yml •  /{appname}-{profile}.properties •  /{appname}/{profile}[/{label}] •  /{label}/{appname}-{profile}.yml •  /{label}/{appname}-{profile}.properties •  For a git backend •  Configure URL of git repo •  {appname} & {profile} maps to file & directory in repo •  {label} -> git branch •  Git backend example: •  Repo contains files: •  application.yml •  application-development.yml •  foo.yml •  foo-development.yml •  bar.yml •  Client request contains: •  {appname}=foo •  {profile}=development •  Config server returns in precedence order: •  foo-development.yml •  foo.yml •  application-development.yml •  application.yml
  47. 47. Steeltoe Config Server Client Provider •  Use AddConfigServer(environment) extension method on ConfigurationBuilder to add Config Server client provider •  At Build(), client calls Config Server and retrieves configuration data •  Must configure the Config Server client settings •  Easiest to put settings in appsettings.json or other file based config source •  Must add the providers settings before AddConfigServer(environment) so client can find settings •  Two settings are required at minimum •  spring:application:name defines the ‘{appName}’ portion of the Config Server request •  spring:cloud:config:uri defines the REST endpoint of the Config Server •  IHostEnvironment.EnvironmentName is used for ‘{profile}’ portion of Config Server request
  48. 48. Using Config Server on Cloud Foundry •  Create instance of Config Server using CF CLI •  cf create-service p-config-server standard cserver –c config.json •  config.json specifies URL of git repo it uses for configuration data •  Use cf service to check status of service •  Bind instance to applications •  cf bind-service appName cserver •  Also specify binding in manifest.yml •  ‘services:’ section-> add ‘cserver’ •  Steeltoe Config Server Client detects p-config-server binding •  Overrides appsettings.json client settings with binding information •  Enables easier development and testing locally; and then push to CF with no changes
  49. 49. Microservices Discovery
  50. 50. Steeltoe Service Discovery Client Overview •  Provides configurable generalized interface for Service Registry interaction •  Steeltoe.Discovery.ClientCore •  Single configurable provider today: •  Eureka – client for Netflix Eureka Service registry •  Application type support •  ASP.NET - MVC, WebForm, WebAPI, WCF •  ASP.NET Core •  Console apps (.NET Framework and .NET Core)
  51. 51. Spring Cloud Service Registry Basics •  Use Service IDs, not URLs, to locate services •  Client-side or server-side load balancing
  52. 52. Steeltoe Eureka Client •  Enables interaction with Netflix Eureka Service Registry •  OSS Netflix Eureka Server – use Steeltoe.Discovery.ClientCore •  PCF Netflix Eureka Server - use Pivotal.Discovery.ClientCore •  Three step process to enable the Steeltoe Eureka client •  Configure Discovery client settings – use values from the built Configuration •  Add Discovery client to service container - AddDiscoveryClient(Configuration) •  Use Discovery client – UseDiscoveryClient() - starts up client background thread •  For Eureka, registered services are pulled from Eureka Server •  Discovery client settings •  Normally just add settings to Configuration •  Put in appsettings.json, or Config Server repo, etc. •  General client settings and for discovering services: eureka:client:…. •  Settings for registering as a service: eureka:instance:…
  53. 53. Using Steeltoe Eureka Client to Find Services •  Inject IDiscoveryClient into your Controller, View, etc. •  Can use the interface to access registered services by name – GetInstances(name) •  Alternatively, use DiscoveryHttpClientHandler – an HttpClientHandler for use with HttpClient •  Integrates service lookup with issuing HttpClient requests •  Handler intercepts requests and attempts to resolve ‘host’ portion of the request URL as a service name •  Replaces it with resolved address if successful •  Leaves alone if not
  54. 54. Using Eureka Server on Cloud Foundry •  Create instance of Eureka Server using CF CLI •  cf create-service p-service-registry standard myDiscoveryService •  Use cf service to check status of service •  Bind instance to applications •  cf bind-service appName myDiscoveryService •  Also specify binding in manifest.yml •  ‘services’ section-> add ‘myDiscoveryService’ •  Steeltoe Discovery Client detects p-service-registry binding •  Overrides appsettings.json client settings with binding information •  Use Eureka Server dashboard to examine registered services
  55. 55. Microservices Connectivity
  56. 56. Steeltoe Connectors Overview •  Simplify using Cloud Foundry services •  Can configure settings for local usage (e.g. appsettings.json, Config Server, etc.) •  When app pushed to Cloud Foundry bindings auto detected and override settings •  Adds Connection or DbContext objects to service container •  Several connector NuGets •  Steeltoe.CloudFoundry.Connector.MySql •  Steeltoe.CloudFoundry.Connector.Postgres •  Steeltoe.CloudFoundry.Connector.Rabbit •  Steeltoe.CloudFoundry.Connector.Redis •  Steeltoe.CloudFoundry.Connector.OAuth •  Application type support •  ASP.NET - MVC, WebForm, WebAPI, WCF •  ASP.NET Core •  Console apps (.NET Framework and .NET Core)
  57. 57. Cloud Security Providers
  58. 58. Steeltoe Security Provider Overview •  Secure your .NET apps on Cloud Foundry •  Access JWT protected resources (such as the Cloud Controller API) •  Integrate your application with Pivotal Single Sign on, leveraging OAuth2 •  Adds a Redis key ring storage option for ASP.NET Core Data Protection •  Two security NuGets •  Steeltoe.Security.DataProtection.Redis •  Steeltoe.Security.Authentication.CloudFoundry •  Application type support •  ASP.NET - MVC, WebForm, WebAPI, WCF •  ASP.NET Core •  Console apps (.NET Framework and .NET Core)
  59. 59. Circuit Breaker
  60. 60. Steeltoe Circuit Breaker Overview •  Stop sending requests to a failing service (allowing time to recover) •  Fail gracefully by implementing fall-back behavior
  61. 61. Cloud Management
  62. 62. Steeltoe Management Endpoints /info arbitrary app info, e.g. git build tag /health application health information /trace circular buffer of last 100 http requests/responses /loggers shows and modifies configuration of loggers down to the class level
  63. 63. lunch time
  64. 64. Exercise #1 Goal: Set up environment and generate an ASP.NET Core microservice. Expected Result: Laptop configured with Cloud Foundry CLI, Visual Studio Code, .NET Core SDK. PWS account created and Spring Cloud Services instance deployed. ASP.NET core microservice created and deployed to Cloud Foundry.
  65. 65. Exercise #2 Goal: See how to use the Config Server for centralized configuration. Expected Result: ASP.NET Core microservice created and set to use new configuration provider. Service deployed to Cloud Foundry and leveraging Spring Cloud Services Configuration Server.
  66. 66. Exercise #3 Goal: Explore service registration and discovery practices. Expected Result: Register existing microservice with a service registry. Update a client application so that it discovers the microservice and uses it.
  67. 67. Exercise #4 Goal: Check out Cloud Foundry support for .NET applications. Expected Result: The ASP.NET Core microservice scales automatically, recovers from failures, and emits logs that the platform aggregates and displays.
  68. 68. Cloud- native .NET isn’t only possible, it’s now required. Are you ready? Upgrade your patterns Introduce new tools Upgrade your platform Experiment and deploy things!
  69. 69. Learn more! http://pivotal.io/microservices https://www.microsoft.com/net/learn/architecture http://steeltoe.io https://github.com/steeltoeoss

×