What network architects need to know about the evolving software lifecycle (SDLC)
•Download as PPTX, PDF•
0 likes•106 views
As our applications transform to cloud-native-first architectures, policy replaces configuration files to define infrastructure at all layers; networking, compute, storage, and of course application. Developers now have almost unlimited choices in how to solve their architecture, agility and scale challenges using the software defined infrastructure that powers our cloud-native world. Prescriptive topologies for networks are too rigid to support the needed agile iterations of today’s application. The software development lifecycle (SDLC) evolved to support multiple iterations for innovation and has some lessons for all of us. This session describes SDLC evolutions to help network and infrastructure experts as they strive to connect business value to applications to infrastructure while constructing the networks of the future.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to What network architects need to know about the evolving software lifecycle (SDLC)
Similar to What network architects need to know about the evolving software lifecycle (SDLC) (20)
Recently uploaded
Recently uploaded (20)
What network architects need to know about the evolving software lifecycle (SDLC)
- 1. #CLUS
- 2. #CLUS Marco Coulter,Technical Evangelist, AppDynamics @marcocoulter PSOGEN-1013 What Network Architects Need to Know About the Evolving Software Lifecycle (SDLC)
- 3. POLL QUESTION: Why did we move to software-defined infrastructure?
- 4. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS PSOGEN-1013 4 Agenda • Software defined paradigm shift • The SDLC in a nutshell • AppDev software defined networking • Reliability is everyone’s responsibility • Becoming dangerous in the new world
- 5. Questions? Use Cisco Webex Teams to chat with the speaker after the session Find this session in the Cisco Live Mobile App Click “Join the Discussion” Install Webex Teams or go directly to the team space Enter messages/questions in the team space How Webex Teams will be moderated by the speaker until June 16, 2019. 1 2 3 4 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Cisco WebexTeams cs.co/ciscolivebot# WEBEX TEAMS 5 PSOGEN-1013
- 6. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS #about_marco Marco Coulter TechnicalEvangelist @marcocoulter marco.coulter@appdynamics.com PSOGEN-1013 6
- 7. Oh Software…
- 8. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Software is Eating theWorld 8 PSOGEN-1013
- 9. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS WhoWants aTaco? 9 PSOGEN-1013
- 10. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The Olden Days 10 PSOGEN-1013 Active Warm Standby Requests
- 11. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The Modern Days 11 PSOGEN-1013 Requests State A State B State C
- 12. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The Future-ish Days 12 PSOGEN-1013 Request
- 13. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Since we have to re-create… 13 PSOGEN-1013
- 14. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The Pipeline Paradigm 14 PSOGEN-1013 Request Recreate Recreate Recreate
- 15. Hello SDLC
- 16. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Welcome to Agile! 16 PSOGEN-1013
- 17. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Usually not Perfect 17 PSOGEN-1013
- 18. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Iteration 18 PSOGEN-1013
- 19. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Multiple Environments 19 PSOGEN-1013
- 20. You want it when?!
- 21. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Just one more endpoint PLS 21 PSOGEN-1013
- 22. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Networking Request Nirvana 22 PSOGEN-1013 Host Port Who to let in?
- 23. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The olden days 23 PSOGEN-1013 Active Warm Standby Requests
- 24. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The olden days 24 PSOGEN-1013 • 4 StaticAddresses • Your Infrastructure
- 25. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The modern days 25 PSOGEN-1013 Requests State A State B State C
- 26. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The Modern Days 26 PSOGEN-1013 • 1 Static Endpoint • 1 SRV Record • 4 Records/Addresses • 4 Routes • Mostly Your Infrastructure
- 27. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The Future-ish Days 27 PSOGEN-1013 Request
- 28. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The Future-ish Days 28 PSOGEN-1013 • 3 Static Endpoints • N SRV Records • N Routes • N Addresses • NotYour Infrastructure
- 29. ReliabilityYou++
- 30. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS /8 vs /16 CIDR? 30 PSOGEN-1013
- 31. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS You are Reliability! 31 PSOGEN-1013
- 32. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS What is the PlatformTeam? 32 PSOGEN-1013
- 33. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS NetOps to the Rescue 33 PSOGEN-1013
- 35. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Infrastructure as Code 35 PSOGEN-1013
- 36. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Service Mesh 36 PSOGEN-1013
- 37. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Routing Rules = Dev? 37 PSOGEN-1013
- 38. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS The Pipeline (Again) 38 PSOGEN-1013
- 39. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS APM + ACI = Amaze 39 PSOGEN-1013
- 40. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Jevons Paradox • A 20% increase in efficiency causes a 40% increase in usage. • Consumption increases and the Jevons paradox occurs. 1865 William Jevons (Economist) By Lawrencekhoo - Own work, CC BY-SA 4.0, PSOGEN-1013 40
- 41. We are all Engineers!
- 42. Complete your online session evaluation • Please complete your session survey after each session.Your feedback is very important. • Complete a minimum of 4 session surveys and the Overall Conference survey (starting onThursday) to receive your Cisco Live water bottle. • All surveys can be taken in the Cisco Live Mobile App or by logging in to the Session Catalog on ciscolive.cisco.com/us. Cisco Live sessions will be available for viewing on demand after the event at ciscolive.cisco.com. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS PSOGEN-1013 42
- 43. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS Continue your education 43 PSOGEN-1013 Related sessions Walk-in self-paced labs Demos in the Cisco campus Meet the engineer 1:1 meetings
- 44. © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public #CLUS What’s Next 44 AppDynamicsVisibility Pack Demos in the Business Insights village 1:1 meetings with our experts
- 45. Thank you #CLUS
- 46. #CLUS
Editor's Notes
- There is a paradigm shift occurring Understand the develement concepts going on today. Look at service mesh & routing rules. PSOGEN-1013 What Network Architects Need to Know About the Evolving Software Lifecycle (SDLC) As our applications transform to cloud-native-first architectures, policy replaces configuration files to define infrastructure at all layers; networking, compute, storage, and of course application. Developers now have almost unlimited choices in how to solve their architecture, agility and scale challenges using the software defined infrastructure that powers our cloud-native world. Prescriptive topologies for networks are too rigid to support the needed agile iterations of today’s application. The software development lifecycle (SDLC) evolved to support multiple iterations for innovation and has some lessons for all of us. This session describes SDLC evolutions to help network and infrastructure experts as they strive to connect business value to applications to infrastructure while constructing the networks of the future.
- Software defined paradigm shift The SDLC in a nutshell – a lot of this is shifting left. AppDev software defined networking Reliability is everyone’s responsibility Becoming dangerous in the new world
- Hi, I am marco, and I have worked for one of the top 50 international banks, managed data centers for hospitals as part of CSC (now DXC) and managed teams in 13 different countries. Before joining AppDynamics, I spent 5 years as an industry analyst and running the data science team at 451 Research. These are a few of the places where you can read my writing or interviews. I have seen technology from every side: as a vendor, operations, development , analyst and buyer. So enough about me.
- Marc Andreessen's Famous Quote Since we are in San Diego, here are some taco’s since I have the 1pm session. Software has been feeding the world!
- Let’s go through an evolution of application infrastructure. In this example the taco is actually a request.
- This is how fulfilling requests used to look. You would have a load balancer feeding the request into a choice of active VM’s. And in case of problems, you would have a pair of standby VMs. This is pretty easy to plan for and connect. And remember, I am taking a developer viewpoint here rather than an operations one. But what is happening today?
- Today is more dynamic. We would use a container orchestrator like K8S. Now, the state can change on a regular basis. We have caught up to here. So when our request comes in, K8S might say ’umm state B looks best for that, that state B’. Cluster size is more predictable. But where we are heading is even more dynamic.
- This may be the future, or you may already be there. This is the serverless revolution. Who is using microservices today? With any request, the infrastructure is spun up and down per request. Wow! Totally dynamic to the point of being ephemeral. This is the modern paradigm. An important part of it is that the serverless function being called does not know the trigger that is calling it. That trigger could be 3 or 4 levels upstream in the code. The function is simply called and it produces an output. I will come back to this a little later. The ability to re-create and re-constitute infrastructure at every step of the lifecycle is the big difference.
- Sicne we have to recreate infrastructure along with the software. So here we have a container orchestrator definition. I describe what I want and the orchestrator will go and get it. This format is yaml. Since we are at Cisco live, this defines my Cisco live Taco! In the middle here is an application-centric concept that usually the network team would have. What are the ports that I need? What are the virtual IP’s? And also setting up some of the ingress needs. This is what we call shifting left for the development team. They are defining eventual production infrastructure needs while developing code. And with JenkinsX, they can create testing frameworks for their code to ensure compatibility. This is the execution of software defined infrastructure from the developer viewpoint.
- This is the pipeline paradigm. Anytime there is a request, we have to recreate! And this paradigm led to the bloom of SDI. THIS IS IT. Just using what you need when you need it.
- Hello SDLC. Software Development Lifecycle. So what can infrastructure and operations folks learn from the trends in development? SDLC allows a lot of innovation to occur because when doing something you do not have to be perfect. In the past, with waterfall, you would spend months before a customer got to see it and let the developer know whether the work paid off.
- By moving left, and becoming agile, there is a lot more experimentation possible. It all becomes about iteration. A lot of trial and error to get things to work. And they are allowed to fail. A lot of time now, you are making small changes. Building a little piece of the application environment at a time. Requirements come along iteratively. You are building a little piece of the environment at a time and you want to build it iteratively. Incremental value is crucial in the agile world. You want to create not a fixed set of definitions, but a definition of the requirement that can be passed to an orchestrator.
- And it is ok that you will not get it completely right on the first attempt. It takes iteration to make something perfect. These tacos are FAR from perfect, but with iteration …
- We can definitely get there. So in networking, what does this actually look like.
- So SDLC has the concept of multiple environments – we are separating the places where we make change. So if we want to make a particular change in development, we can blow away the dev environment and make the changes without impacting other environments. And the key aspect here is – in the same way that the developer code is transferred from dev, to test, to QA, to production making sure it is not changed along the way. That what we tested is what ends up in production. We need to ensure the ephemeral controls, the yaml descriptors also travel and live with the code and go through the same processes. The automated builds and testing from the DevOps discipline is not just for developers, it is for network as well.
- These silly AppDev teams keep asking for more networking resources. JUST ONE MORE TACO! Or in the networking case, just one more endpoint. Why do developers keep asking for more endpoints?
- This is an oversimplification, but with a trifecta like this we can start applying networking goals. I was part of a panel interview in Atlanta last week and one of the audience questions was around how a network person could know what ports a monitored application used. This has been a continual conflict of balancing the security and performance needs against the appdev lack of clarity of what specifically is being used. Lets go back to our Taco request to understand how the changes in SDLC changed the network.
- This is easy. There are 4 boxes.
- It is pretty easy, and we have a lot of control.
- As we come forward in time … we are more dynamic. The state can change on a regular basis.
- To represent this, we have to introduce more concepts. One static endpoint = ciscolivetaco.com Depending on some choices K8S makes, we might have 4 separate addresses AND 4 separate routes to those addresses. And while it is still maybe MOSTLY yours, we also have concepts of third party cloud providers and infrastructure providers.
- Finally with the future state:
- This is a lot harder. You will have 3 static endpoints, but you will have an indeterminate number of routes and addresses AND this is NOT your infrastructure! So you are dealing with a paradigm where software is defining and making decisions around the network in a dynamic way. Survival for network admins means taking a policy approach that can scale and deploy automatically AND can improve with iteration.
- Software engineers don’t know that CIDR means. They do not understand what a different world /8 and /16 create. A good friend of mine had his biggest outage as a result of not understanding this. He was part of the first team in his enterprise to move to AWS. And in those early days his networking team too the attitude that they were not going to get involved in architecting networking that was not on-premise. As part of that they had to learn how to setup a VPC or virtual private cloud. By getting this setting wrong, he basically cut off half the internet. The questions raised here was “He was an app developer, why is he working on CIDR? A purely network function’ ---======----- Classless Inter-Domain Routing (CIDR) Classless Inter-Domain Routing is a method for allocating IP addresses and IP routing. The Internet Engineering Task Force introduced CIDR in 1993 to replace the previous addressing architecture of classful network design in the Internet. Its goal was to slow the growth of routing tables on routers across the Internet, and to help slow the rapid exhaustion of IPv4 addresses. /8 255.0.0.0 1 A 16,777,214 /16 255.255.0.0 1 B 65,024
- The reality is that developers ARE and WILL be defining network needs within their solutions. My friends comment in the aftermath was ‘he wished he had learned sooner’. They need the network engineering or netops team to help them out!
- There is a middle ground happening now. Many enterprises are now building a platform engineering team that builds the places where the applications will go. Networking now can be seen as part of the platform.
- Networking now can be seen as part of the platform. Understand the SDLC and how their process works, then help understand how networking works. Find a developer peer and jointly hold a brownbag for the dev team on how to configure networks in K8S, or Jenkins, or whatever is used. Explain how ACI policy works. Rescue them!
- Now, let’s get dangerous and talk about the developer pipeline.
- This is what the devops teams are working with in the last few years. This is a webserver installation defined for chef. We are describing an end state. We need to have a particular internet server with this certificate. This is what modern infrastructure is: we describe what we need and having it execute on a particular platform. https://docs.chef.io/resource_rpm_package.html And some thing else you should be aware of is service mesh.
- Service Mesh, side car Is pushing a lot of network concepts. Servicemesh is a place where serverless services can be made discoverable and it defines how they interoperate with each other. So looking at an example from Istio.
- Maxconnections was a sort of thing that was dealt with load-balancer team. Now, this is core within the code being built. This is difficult for Developers, to build application-centric networking logic. https://istio.io/docs/concepts/traffic-management/
- Coming back to the pipeline idea again, you could be using spinnaker, but this example is using harness. So as we are moving something to production, it gets pushed through a pipeline. This even gets to the extent that if you are in an AppDev team you may have heard of GitOps. Lots of developers are using git as a source management solution. From git you can kickoff a chain of events that moves things into production automatically. And one final point about how to survive this SDLC-driven infrastructure.
- As you will know AppDynamics is part of Cisco. And that combines our existing strengths around applications with cisco’s strengths around networking and infrastructure. This combination is really about helping you troubleshooting issues whether in the development, QA and testing environments, and of course in production should something get through to that point. You may wonder how it works that we make things more efficient and end up using more resources. There is a name for that.
- He was talking about coal consumption and the improvements of the Watt’s steam engine that delivered more efficient steam for less coal. Economists predicted less coal usage, but instead coal usage went up. Jevon identified that when there is elastic demand, increased efficiency can lead to paradoxical increased consumption. With the efficiency and agility that cloud provides, people end up using more of it! Good news is – you can use our product to fight the paradox.
- Software building and deployment pipeline is going through a massive paradigm shift. The outcome is that AppDev teams are engaging on an intimate level with networking concepts. Routing rules are moving into the development team. The key takeaway here is that as networks and infrastructure become software defined, network experts need to be more closely aligned to the platform and SDLC teams. Find a peer in the SDLC team to help you understand the software deployment process from coding to production – not just the last step. Pay them back by helping them understand networking policy and ACI. Get to the point where you are working jointly on Chef and K8S yaml. You will deliver network as a platform. In a software defined world, we are all engineers.
- The important messages we want to highlight are 1) appd is in the showcase in the “Business Insights” area 2) you can schedule 1:1 meetings with product specialists during the event and 3) ask about AppDynamics visibility packs to get started.