Cloud Native Application Development
- 1. CLOUD NATIVE SHIFT IN APPLICATION DEVELOPMENT PARADIGM SIVA RAMA KRISHNA
- 2. CLOUD NATIVE ORIGINATED IN CUSTOMER FACING TECH COMPANIES
- 3. VOICE OF THE VENDORS
- 4. NEW AD PROJECTS WITH IN IT ORGANIZATIONS ANALYST PERSPECTIVE 1 Focus on functional and non-functional requirements to drive what “cloudiness” characteristics are needed to deliver 2 Choose both an application architecture and runtime environment that supports the application’s requisite “cloudiness‟ characteristics. 3 The burden of responsibility required to meet these “cloudiness” characteristics within application code versus the system infrastructure. 4 Real world limitations in developer resources, skills, time, etc. may force you to reconsider either the choice of deployment platform OR the degree of “cloudiness” present in the application 5 Rinse and repeat until you find the solution that best balances “cloudiness” with both development and runtime constraints. STEPS TO BUILD A CLOUD APPLICATION
- 5. WE MUST RE-INVENT OUR PROFESSION Then only we can do better Cloud Native is difficult But not doing it is worse The gist is that applications should be, - built in the cloud - for the cloud - maximizing the benefits of the cloud
- 6. Application Architectures MicroServices DevOps * as a Service Distributed Computing TOPICS TO LEARN
- 7. TOPICS TO LEARN Application Architectures MicroServices DevOps * as a Service Distributed Computing • Deployment Target Types • Development Methodology • Legacy Architectures • Service Based Architectures
- 8. — Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs, Monticello, Illinois, September 1997 A big ball of mud is a software system that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer turnover and code entropy. BIG BALL OF MUD – AN ANTI-PATTERN
- 9. QUARRY THE DEPLOYMENT TARGET TYPES Virtual Machine Compute with Operating System, Networking and attached Storage Container An Operating System level virtualization method Application Platform as a Service (aPaaS) Application deployment in Containers Functions (Serverless) …code execution model in which cloud provider fully manages starting and stopping of the function’s container platform as a service as necessary to serve requests
- 10. QUARRY THE DEPLOYMENT TARGET TYPES - EXAMPLE Virtual Machine AWS Azure Oracle Cloud IBM …. Container Docker, Rocket, RunC, LXC, …. Application Platform as a Service (aPaaS) Heroku, Bluemix, Oracle Application Container Functions (Serverless) Amazon Lambda Bluemix OpenWhisk Microsoft Functions Oracle Functions ….
- 11. Adam Wiggins https://12factor.net/ Co-Founder of Heroku Cloud• 12 Factor App principals are commonly viewed as defining Cloud Native • 12 Factor makes sense for new applications but hard to retrofit to existing applications
- 12. LEGACY ARCHITECTURES 12 Source: Software Architecture Patterns by Mark Richards Layered Architecture Event Driven Architecture Micro Kernel Architecture ANALYSIS Overall Agility Deployment Testability Performance Scalability Development Layered Event Driven Micro Kernel
- 13. SERVICE BASED ARCHITECTURE MicroServices Service Oriented Architecture Service Oriented Integration
- 14. Application Architectures MicroServices DevOps * as a Service Distributed Computing • Minimal Function • Service Discovery • API-first • Polyglot • Choreography • Loose Coupling TOPICS TO LEARN
- 15. “Erik Doernenburg first shared with me the idea that we should think of our role more as town planners than architects for the built environment” - Sam Newman
- 16. MICROSERVICES Break up your application into many small pieces to get features to market quickly. Each MicroService Characteristics – Small & Independently deployable De-coupled Has its own team to design, develop, deploy and maintain Exposes an API Has its own databases
- 17. USE A HIGHER LEVEL OF REST 17 REST is the currency of cloud native • Level 1 – Start requesting individual resources – Interact with /OrderService/12345 • Level 2 – Start using HTTP verbs - HTTP GET/POST/PUT/DELETE/etc – Responses come back using correct HTTP codes – e.g. HTTP 409 for a conflict • Level 3 – Application itself tells client how to interact with it - similar to hyperlinks in a web page – <link rel = "delete" uri = "/OrderService/12345/delete"/> under <order id="12345"> Richardson Maturity Model • Level 0 • Use HTTP as a tunneling mechanism only • Interact with /OrderService • Use HTTP GET/POST only
- 18. A SIMPLE RUBRIC – MINIMUM VIABLE PLATFORM • Optimize SDLC and Delivery Pipeline with tenets of Cloud Native operability • It requires Operationally mature platform • Minimum capabilities of MVP • Dynamic DNS, routing and load balancing • Automated service discovery and brokering • Infrastructure automation • Health Management, monitoring and recovery • Immutable artifact repository • Log aggregation 18
- 19. 19 X-axis scaling • consists of running multiple copies of an application behind a load balancer. Y-axis scaling • splits the application into multiple, different services. Z-axis scaling • Each server run identical copy of code. • Each server responsible for subset of data. THE ART OF SCALABILITY – ACOLYTE SYSTEM y-axis Functionaldecomposition
- 20. Application Architectures MicroServices DevOps * as a Service Distributed Computing TOPICS TO LEARN •Automated Provisioning •Automated Setup •Continuous Integration •Continuous Delivery •Automated Testing •Agile •Culture Change
- 21. 21 The nicest thing about Teamwork is that You always have others on your side.
- 22. GARTNER DEVOPS MODEL - CATALOG OF DEVOPS PRACTICES 22 People Process Culture Technical Debt Test-driven Development Test-Driven Deployment Test Everything Instrument Everything Trust Culture Engineering Culture Collective Ownership Autonomous Teams Joint Meetings Learning Culture Job RotationFull-Stack Teams Minimum Viable Process Common Metrics Feature Flags Optimize Flow Chaos Monkey Value Streams Collaborative Culture Never Done Small Batches Automated Testing Minimum Viable Product Release Automation Automated Builds Canary Rollouts Fail Forward Version Everything Servant Leadership Site Reliability Engineers Platform Engineers Technology Continuous Monitoring Integrated Tool Chains Monitor Everything Infrastructure as Code Developer Self- Service Continuous Testing Continuous Integration ChatOpsOne-Step Build, Test, Deploy Continuous Delivery Feature Teams Starting point of DevOps could be from any of the categories: People, Process, Culture or Technology.
- 23. TAKE THE BARRICADES OUT TO KICK START THE DISCUSSION • Code Quality • MTBF • MTTR • Bug Escape Distance • Code Complexity • Impacts the speed • Unit Test Coverage • Lower values turns to risk • Commit Rates • Longer the rates, more code to be merged – can cause problems, delays, bugs 23 • Environment Stability • Continuous Automated Tests • Combine Tests & System Monitoring • Real time Application Monitoring • Faster Platform Upgradation • Business Metrics • # of deployments • Time to production • # of release candidates built • Software stack under CD pipeline Engineering Operations
- 24. Plan Code Build Test Package Release Deploy Monitor DEVOPS PIPELINE Pattern Description Plan Agile Project Management Code Team Infrastructure (Code, Review, Merging, Version Control, Documentation etc.) Build Continuous Integration Test Continuous Testing Package Artifact repository Release Change Management, Release automation Deploy Deployment plans, Infra provisioning, Infra configuration & management Monitor Application performance monitoring, End user experience 24
- 25. Plan Code Build Test Package Release Deploy Monitor HARNESS THE DELIVERY PROCESS Plan Code Build Test Package Release Deploy Monitor Agile Continuous Integration Plan Code Build Test Package Release Deploy Monitor Continuous Delivery If Agile software development was the opening act to a great performance, continuous delivery is the headliner. - Kurt Bittner, Principle Analyst 25
- 26. DEVOPS PATTERNS AND TOOLSET AVAILABLE IN MARKET 26 A shared version control system that contains system provisioning scripts as well as application code. One tool to manage both application configuration and infrastructure configuration. Common methods and tools for building, testing and quality assurance. Dev Ops Both Coding & Platform for Application Both System & Application on Platform Source Code Management Continuous Integration/ Deployment Configuration Management Software defined Infrastructure Monitoring
- 27. Application Architectures MicroServices DevOps * as a Service Distributed Computing TOPICS TO LEARN •Consume IaaS and PaaS •Fault Tolerant by Definition •Auto-scaling •Infinite Elasticity
- 29. * AS A SERVICE Requires fundamental shift in how applications are built 29 Your Code Highly innovative, differentiated, etc Configuration Caching Load Balancing Eventing Logging Monitoring Database NoSQLState Messaging Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Building Block Where you’re not differentiating, consume building blocks from 3rd party cloud vendor
- 30. EVERYTHING IS NOW SOFTWARE 30 Person p = new Person(); $ docker run -v /host:/container example/myapp curl -X POST "name=MyFirstApp" "runtime=java” "archiveURL=/binaries/myapp.zip" $ puppet module install puppetlabs-java Today, Everything is 100% Code. Automation at scale is standard Provision a new server just like you would provision a new object in Java
- 31. CONTAINERS Is it compulsion to be part of? 31
- 32. • #1 value – app packaging • MicroServices doesn't rely on containers but they do help: • Higher density • Easy to start/stop • Portability • Containers are lightweight, just like MicroServices themselves • Containers can run in VMs too 32 Helpful to MicroServices but not a requirement Hardware Hypervisor VM 1 OS App VM 2 OS App Hardware Virtualization Hardware Operating System Hypervisor VM 1 OS App VM 2 OS App Para-virtualization Hardware Operating System Container 1 App Container 2 App Containers START USING CONTAINERS
- 33. STRICT REQUIREMENT: ONE INSTANCE PER CONTAINER • Run ONE instance (unique host/port combination) per container • Running multiple instances of the same application or different applications will make scheduling very difficult • Expose one port per container 33 Physical Host Operating System Container App Container App Just One Per Container
- 34. Application Architectures MicroServices DevOps * as a Service Distributed Computing TOPICS TO LEARN •Multi-master •Many Data Centers •Many Fault Domains •Many Regions •Global Server Load Balancing •Replication
- 35. "I don't need a hard disk in my computer if I can get to the server faster... carrying around these non- connected computers is byzantine by comparison." - Steve Jobs
- 36. DISTRIBUTED COMPUTING Run your applications across multiple data centers, fault domains, regions, etc36 Cloud Region Fault Domain Data Center Host Container Microservice Microservice Microservice Microservice Hundreds of milliseconds of latency Everything is now distributed Even within the same data center
- 37. 37 SMUGLY OPTION TO CHOOSE Consistency Each node shows the same data at all times Availability Each node is available for writes at all times Partition Tolerance Able to handle network outages CAP Theorem – Pick Any Two C A P Theory Practice Pick One Partition Tolerance is non-negotiable because we have networks that can always fail Enterprise IT Systems: Often CP Microservice Systems: Often AP Each microservice can be CP, AP or CA but the system as a whole is always CP or AP Pick Any Two Computer science is about tradeoffs
- 38. 38 MICROSERVICES FORCES MOVE TO DISTRIBUTED COMPUTING • Distributed computing is a natural consequence of microservices because each microservice has its own data store • Sharing data stores across microservices introduces coupling – very bad! • There will always be latency between microservices • Latency leads to eventual consistency API Application Datastore Infrastructure API Application Datastore Infrastructure API Application Datastore Infrastructure API Application Datastore Infrastructure Microservice A Microservice B Microservice C Microservice D Monoliths don’t suffer from this
- 39. DevOps + * as a Service + Microservices + Distributed Make Cloud Native Available to Everyone Else 39