SpringOne Platform 2016 Speaker: Nicholas Grabowski; Managing Principal, Charles Schwab

1. Migrating .NET apps to
Cloud Foundry
A Strategy For Enterprises

2. Your Presenter
● Nicholas Grabowski
● Managing Principal at Charles Schwab & Co.
○ Application Architecture Team
○ R&D Team
● Engineering Leader, Executive, Technologist, Architect
● Primary industries: Financial Services and Retail
● Primary focus: Making technology more efficient
August 4th, 2016

3. Audience
● Architects, Engineering Leaders, Data Center Ops
● .NET Shops or those with lots of .NET apps
● Have 100s of apps or microservices
● Enterprises with lots of software
Assumptions:
● You are somewhat familiar with Cloud Foundry

4. A little about our situation & goals.
Situation:
● 100s of .NET, Java, Mainframe, Legacy C,
C++ applications
● Highly regulated environment
● Security is paramount
● Prefer CAPEX over OPEX
● Availability and reliability critical
● Brand conscious, risk averse
Goals:
● Bend cost curve of infrastructure, licensing
● Reduce complexity of deployments
● Leverage available capacity (app density)
● Adhere to our own standards
● Improve security posture
● Improve availability and reliability SLAs
● Improve agile, self service, devops maturity
● Prepare for public cloud
● Do “More, Better, Faster, Cheaper”

5. Shared Environments - What we built
We started before there were PAAS solutions.
We could see value in consolidating many apps to a
cluster of VMs rather than 1 app per cluster.
So we built Java and .NET “Shared Environments”.
Our .NET env looks like:
● IIS on Windows Server 2008
● Standard server configuration
● Standard networking and firewall rules
● Standard IIS configuration
● All apps deployed to all nodes
Shared Environment DC 2
Shared Environment DC 1
Node1
App1 App2 Appn...
Node2
App1 App2 Appn...
NodeN
App1 App2 Appn...
...
Firewall/Loadbalancer
Client
Apps

6. Shared Environments - Made Some Progress
Goals “kind of” accomplished:
● Bend cost curve of infrastructure, licensing
● Reduce complexity of deployments
● Leverage available capacity (app density)
● Adhere to our own standards.
● Improve security posture
● Improve availability and reliability SLAs
● Improve agile, self service, devops maturity
● Prepare for public cloud
● Do more: “More, Better, Faster, Cheaper”● Avoided 1000s of VMs
● Avoided 1000s of licenses
● Avoided ops team expansion

7. Shared Environment DC 2
Shared Environment DC 1
Shared Environments - But Not Enough
Shared Envs gave us a much greater app density
per machine, provided isolation characteristics,
reduced heterogeneity, and improved CD
integration.
But it had limitations:
● No elasticity
● No life cycle management, Pets not cattle
● Containerization is limited
● Security features are limited
Pet1
App1 App2 Appn...
Pet2
App1 App2 Appn...
PetN
App1 App2 Appn...
...
Firewall/LoadBalancer
Client
Apps
Noisy Neighbor App1 failure impacts other apps

8. Enter Cloud Foundry
● True runtime elasticity
● Lifecycle Management (no more pets)
● Better containerization
● Improved security posture
Goals could be accomplished for Java
● Bend cost curve of infrastructure, licensing
● Reduce complexity of deployments
● Leverage available capacity (app density)
● Adhere to our own standards
● Improve security posture
● Improve availability and reliability SLAs
● Improve agile, self service, devops maturity
● Prepare for public cloud
● Do “More, Better, Faster, Cheaper”

9. Enter Cloud Foundry - BOSH is the Key
“BOSH is a project that unifies release engineering,
deployment, and lifecycle management of small and
large-scale cloud software. BOSH can provision and deploy
software over hundreds of VMs. It also performs monitoring,
failure recovery, and software updates with zero-to-minimal
downtime.” - bosh.io
Bosh, Stem cells, Go router enable:
● Elasticity
● Life cycle management, Cattle not pets
● Containerization is robust
● Security features are robust
Cloud Foundry DC 2
Cloud Foundry DC 1
Node1
App1 App2 Appn...
Node2
App2
NodeN
App1 App3
...
Router
Client
Apps
BOSH
App4
App5

10. .NET CF parity - 2 paths
BOSH Windows
● Life cycle of fully managed by CF
● Will run .NET 4.5
● 100s of Billions (Trillions?) of lines of legacy
code need a home
● Windows only shops need a solution
.NET Core on Linux
● Only .NET Core
● Auditors less concerned with linux
● Limits complexity of CF
● Reduces legacy (Active Directory, IIS, etc.)
● .NET on par with other open source
11/2015 - Windows workloads deployable to CF, but parity not achieved… what is
needed?

11. Migration Considerations
BOSH Windows:
● Consider 12 factor - i.e. cloud readiness
● Remove dependencies on NFS
● Logging will need to change
● Make sure apps are node unaware
● Leverage off host session management
● Externalize environment configuration
● Avoid joining an AD Domain
● Avoid administering nodes directly
.NET Core Linux:
…. All of “BOSH WIndows” +
● .NET Core is more like a port than upgrade
● MSFT infamous for Betas as GAs
● .NET Core support model different
● Replace IIS with Kestrel or Web Listeners.
● Look to integrate CF Managed Services like
○ Messaging (e.g. Rabbit MQ)
○ Session Management (e.g. Redis)
The risk averse should consider a Shared Env first. For the rest of us...

12. Thanks
Contact me at:
● nicholas.grabowski@schwab.com
● ng@ngsoft.org
● http://www.linkedin.com/in/ngsoft
Shameless Recruiting Plug:
● Are you a solutions or enterprise architect?
● Are you a developer who wants to be an architect?
● Interested in working with the latest technology?
If so, Charles Schwab has an endless supply of multi million
dollar challenges?
http://jobs.schwab.com/