When Networks Meet Apps, Samuel Bercovici & Nati Shalom
•Download as PPTX, PDF•
1 like•844 views
This document discusses how networking and applications are converging, with three key points: 1. Everything is becoming software-defined, allowing automation of networking, compute, and other resources through APIs. 2. Networking and applications can be orchestrated together using templates in Heat or TOSCA, provisioning related resources like load balancers, subnets, and security groups. 3. Future work includes tighter integration of TOSCA and Heat, group-based policies to address network requirements from applications, and handling real-life scenarios around high availability and continuous deployment.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (18)
Similar to When Networks Meet Apps, Samuel Bercovici & Nati Shalom
Similar to When Networks Meet Apps, Samuel Bercovici & Nati Shalom (20)
More from Cloud Native Day Tel Aviv
More from Cloud Native Day Tel Aviv (20)
Recently uploaded
Recently uploaded (20)
When Networks Meet Apps, Samuel Bercovici & Nati Shalom
- 1. When Network Meets Apps! Putting networking and application together Nati Shalom GigaSpaces @natishalom Samuel Bercovici Radware @samuelbercovici
- 2. Agenda • Overview of Networking and Apps • What’s Changed? • Putting Networking and Apps by Example • Future Work
- 5. Zoom into a Tier Server (Physical/VM) Operating System (RHEL 6.5 64bits) Database System (MySQL) Schema (Word-press) IP Address IP Address TCP Port
- 10. Web Tier Middle Tier DB Tier Layer 3 Services • Subnet • GW • IPAM – DHCP • DNS • Subnet • GW • IPAM – DHCP • DNS • Subnet • GW • IPAM – DHCP • DNS
- 13. Web Tier Middle Tier DB Tier Security, Availability & Scalability SLB SLB SLB FW
- 15. Expertise & Responsibilities • Network / Security Manager – Network (L2, L3) – Network Services (Router, NAT, DHCP, DNS, LB) – Network Security (FW, VPN) • IT / Application Manager – Server – Operating System – Software Stack – Application Artifacts – Server’s Security
- 16. Load Balancer - Management • Network based – L2 and L3 – L4 Load balancing • Application based – Cookie based, L7 Content Switching, L7 Content Modifications, etc. Network Manager Network Manager ? Application Manager ?
- 17. What’s Changed? Everything is Software Defined
- 18. We Can Automate Everything.. Orchestration Networking Compute
- 19. Neutron/Nova APIs • Layer 2 networks • Layer 3 subnets – IP address management – DHCP based – Router / gateway / NAT • Port • Security groups • Floating IP • Layer 4-7 Services – Load balancing – VPN – Firewall
- 20. Putting Network and Apps Together by Example HEAT •OpenStack Orchestration TOSCA •Topology •Orchestration •Specification of •Cloud •Application
- 21. Apache Server DB Server Apache Wordpress MySQL WordPress Simple Example • App Network • App Subnet • App Port • Security Group • Apache Floating IP • Router Gateway • Data Network • Data Subnet • Data Port • Security Group Router
- 24. Heat Template
- 25. Apache Server DB Server NodeJS NodeCeller MongoDB TOSCA (Like) Example • App Network • App Subnet • App Port • Security Group • Apache Floating IP • Router Gateway • Data Network • Data Subnet • Data Port • Security Group Router Monitoring, Logging CI
- 26. Network View
- 27. Topology View
- 30. Scalability & Availability Router L3 Tenant1 Network Tenant1 Project VIP1 Management Network Web VM 3 VIP1VIP1 Alteon VA Project VM 4 VM 5
- 31. AutoScaling - Heat Template • web_server_group - OS::Heat::AutoScalingGroup • web_server_scaleup_policy - OS::Heat::ScalingPolicy • web_server_scaledown_policy - OS::Heat::ScalingPolicy • cpu_alarm_high - OS::Ceilometer::Alarm • cpu_alarm_low - OS::Ceilometer::Alarm • monitor - OS::Neutron::HealthMonitor • pool - OS::Neutron::Pool • lb - OS::Neutron::LoadBalancer
- 32. So far so good, but...
- 33. Considering Real Life Scenarios Continuous Availability Across AZ’s and Regions – Adding Affinity Rules for Compute, Storage – Auto-Scaling, etc. Continuous Deployment – Updating policies and workflow – Creating new deployments every day
- 34. Real Life Example (HP Print) • 30 HP Helion Public Cloud accounts • 500+compute instances • 1400 Peak deployments per day • 100+compute instances per management cluster • 100xdevelopers doing deployments in a consistent fashion • <2HMove from HP Helion Public Cloud tenant to a fully provisioned and deployed service
- 35. Networking and Apps in Real Life...
- 36. Future work..
- 37. Putting TOSCA and HEAT Closer.. • TOSCA HEAT Translator Project (IBM, GigaSpaces, Huawei, Vnomic ..) • TOSCA enablement in Heat Juno • Integrating Cloudify and Heat
- 38. Group Based Policies • Addressing Network Requirements from the application perspective • Delegation of Responsibilities
- 39. References • Examples (Step by Step Guide) – Heat Example – TOSCA (like) Example • TOSCA Translator Project – Git Project • OpenStack Heat Project • Cloudify – getcloudify.org • Radware Load Balancing as a Service • Group Based Policies – GPB • AutoScaling Policies – Heat Template
Editor's Notes
- Goals: Why Workflows are critical part of automation of applications on the cloud Clarify the need for something like OpsWorks Why do we think this OpsWorks is needed in addition to other projects
- Original example: https://github.com/openstack/heat-templates/blob/master/hot/F18/WordPress_Native.yaml Wordpress with Netowrking: http://s3.amazonaws.com/yoramw/wordpress.yaml
- https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml