.NET Cloud-Native Bootcamp

Goal of this boot camp.
Introduce you to practices, platforms and tools for
building modern .NET applications.

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

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.

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.

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.

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.

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?

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.

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

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

So, what actually makes up a cloud-native
platform?

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
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

PCF 2.0
Any App
Every Cloud
One Platform

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

~$ 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

$ cf push my-app -p target/myapp.jar
or
$ cf push my-app --docker-image pivotal/my-image

Deploy source code
that the platform
containerizes for
you
or
Deploy container
images that you
build yourself

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!

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

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

•  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
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

THREADING Threads • Thread Pool • Tasks
IO Files • Compression • MMF
DATA DataSet • DataTable • SQLClient
APIs in .NET Standard 2.0

THREADING Threads • Thread Pool • Tasks
IO Files • Compression • MMF
DATA DataSet • DataTable • SQLClient
APIs in .NET Standard 2.0
https://github.com/dotnet/standard

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

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

The dotnet
CLI tool
dotnet new
dotnet add | remove package
dotnet restore
dotnet build
dotnet run
dotnet test
dotnet publish

Where to run cloud-native .NET apps?
•  .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.

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

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

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

Pivotal packaged up
key Spring Cloud
capabilities into a
managed bundle for
called Spring Cloud
Services.

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

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)

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
•  ASP.NET Core

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

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

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

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

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
•  ASP.NET Core

Spring Cloud Service Registry Basics
•  Use Service IDs, not URLs, to
locate services
•  Client-side or server-side load
balancing

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:…

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

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

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
•  ASP.NET Core

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
•  ASP.NET Core

Steeltoe Circuit Breaker Overview
•  Stop sending requests to a
failing service (allowing time
to recover)
•  Fail gracefully by
implementing fall-back
behavior

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

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.

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.

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.

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.

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!

Learn more!
http://pivotal.io/microservices
https://www.microsoft.com/net/learn/architecture
http://steeltoe.io
https://github.com/steeltoeoss

.NET Cloud-Native Bootcamp

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to .NET Cloud-Native Bootcamp

Similar to .NET Cloud-Native Bootcamp (20)

More from VMware Tanzu

More from VMware Tanzu (20)

Recently uploaded

Recently uploaded (20)

.NET Cloud-Native Bootcamp