cloud journey mikevilliger
TRANSCRIPT
Journey to Cloud NativeHow to move to the cloud in three steps
• Mike Villiger, @mikevilliger
Bimodal ITNot every project is a cloud project, but cloud thinking is everywhere
Develop
Big monolithic application. Small interconnected purpose-built services.
Pizza Box TeamsSmall teams can deliver features into production
New Rules in the Game
You build it, you run it.
Werner Vogels, CTO Amazon
Ship
Deploy
Big Bang Releases of single special built applications. Small continuous service delivery of standardized delivery blocks.
Compute
Hardwired datacenters. Datacenter as an API.Confidential, Dynatrace LLC
The journey to become cloud-native
We see three different stages how companies embrace transformation
Stage 1: Continuous Delivery
“Lift and Shift” to modern platformsApplications stay the sameRelease speed massively increases
Writing fast cloud native applications easily
Rule #1: Don’t write slow code
Control code complexityN+1 interaction patterns - control flow designDuplicate interactions - bounded context, SPOFMore than 10 service hops - hard to debugHighly asynchronous - hard to understandUnusual Log Activity
Continuous Performance Management
Stage 2: Refactoring towards Micro Services
First micro services Scheduling and OrchestrationArchitectures become polyglotIndependent Release Cycles
Writing fast cloud native applications easily
Rule #1: Don’t write slow codeRule #2: Don’t write code that doesn’t scale
Control Environment Complexity
Service Call Payload - < 500 kbChatty services - > 50 service callsInter-tier heavy interactions - granularity and localityStatus Codes - only Ok is 200
Understand Micro Service Interactions
Stage 3: Dynamic Micro Services
Up and down scaling near real timeAdvanced resilience mechanismsInfrastructure totally abstracted
Writing fast cloud native applications easily
Rule #1: Don’t write slow codeRule #2: Don’t write code that doesn’t scaleRule #3: Understand application behavior
Watch your application live
Health monitoring – symptoms Orchestration monitoring - causalityApplication monitoring - root cause
7:00 a.m.Low Load and Service runningon minimum redudancy
12:00 p.m.Scaled up service during peak loadwith failover of problematic node
7:00 p.m.Scaled down again to lower loadand move to different geo location
Deployments are no longer static
You don’t fly blindly here820 Billion dependencies
Network Problem Mushroom cloud effect
Container Network Monitoring
Make it part of your environment
Thank you!Mike [email protected]@mikevilliger