In this lesson we’ll be talking about a culture of collaboration. We’ll do an introduction to Agile, which is a modern development framework. You may have heard of Agile software development, and that’s really where Agile originates, as a software development framework. It’s not just applicable to software development, as we’ll see over this lesson. It also applies very well to any development process where you are taking requirements from some customer, creating some product, and then delivering that product to your customer, or to an operations team.
Let’s first talk about some modern networking challenges that we encounter as network engineers.
First up, networks are of an unprecedented scale in modern times. A network is treated a lot like a software project honestly, that bigger, faster and more reliable are often the ever-demanding requirements we face. The businesses these networks serve need bigger data center networks, bigger WAN networks and LAN networks.
These networks need to move more data faster, and need to be as reliable as can be, with several 9s of availability. As if that weren’t demanding enough, we need to roll out these changes as quickly as we can with minimal room for error.
Manual configuration doesn’t scale, or allow the necessary reliability or efficiency to meet these unprecedented network scales and demands.
The world is changing very fast, not only must our networks be faster than ever, but they also must support changes in service types and provisioning faster than ever before.
Perhaps your customer has a need for a multicast L3VPN, which your network is not currently configured to be able to provide. These changes to production need to be accurate, reliable and securely implemented. When we’re doing manual configuration at this scale, we typically fall into a firefighting culture due to inevitable error and network instability.
Many of us have seen this first hand, when you’re in a support role and every change is very reactive, with manual human intervention required for all incidents. In this situation, if you have a device down then you as a NOC (Network Operations Center) technician are going to be logging in and retrieving information about that device, and doing some troubleshooting steps. It’s you as an individual that needs to put forth these intervening steps. If there are many trouble tickets due to unreliable areas of the network caused by inconsistent deployments and configurations, then this creates a firefighting culture, where many personnel are always trying to put out the fires that are going on.
Sometimes networks can be so inconsistent that any new services, like our multicast L3VPN mentioned earlier, requires a possible total network redesign to implement. We may need to make changes to many areas of the network, in a potentially very slow change management process, to be able to deliver this product.
This brings us into our traditional development process. We receive our requirements from our customer, we’re developing our changes to production, we’re testing them and then we are deploying our changes out.
The reason why we said develop is because Agile is primarily focused on software development, though it does apply very well to general product development, like our network products that we are developing. This traditional development model is called the waterfall model.
In this traditional model, the next phase in development only starts after finishing the previous phase. As illustrated above, in the beginning we are taking in our requirements from our customer, then we’re having a bunch of design meetings with our engineers. Next, we are developing (develop being substituted for ‘code’ in the illustration) our changes to make sure they satisfy our design, and then once we have them developed, we are testing them. Maybe we’ll have to do this process a few times, to develop and test to make sure it’s actually working correctly. Finally, we go out and deploy our changes.
In this traditional model, let’s say when you are in the middle of developing your new network service or writing changes to the production environment, that the requirements end up changing. This means we now need to come all the way back to the requirements phase of the workflow, have more meetings with your customer, have more design meetings with your engineers and go ahead and develop your product and test it again. We’ll probably have to run through the develop and test cycle a couple of iterations to make sure you’re actually getting it right and then go and deploy your changes to your customer or production environment.
So, this really lacks flexibility, because any changes to the feature set generally require going back to square one; to our requirements phase. Having more meetings with our customer, and then having more design meetings with our engineers, then developing again and so on and so forth. I’m sure if you’re an engineer you have run into this cycle before, it can feel very bogging down sometimes, where it feels like you have periods where all you’re doing is having meetings and meetings and more meetings to make sure you have your requirements. Then your design meetings, then you actually get to the fun part of developing your change to production, network feature or service. This process can be very frustrating sometimes, and it really results in large monolithic changes to production.
Large changes to production environments are dangerous. The more you change, the more likely it is something won’t go as you expect. Additionally, the change itself is typically then more complex, creating difficulty in resolving issues when they do occur.
So, that’s traditional development, right, now step into Agile development. Note that we do have our exclamation sign here, this is a very important slide to make sure you are aware of the Agile Manifesto bullet points and values. I would recommend taking a quick screenshot here and saving that for later to study if you’re going for the JNCIA-DevOps.
The manifesto for Agile software development, or just Agile development, and this is coming from agilemanifesto.org, not only will you have some questions on this on the exam but it’s really valuable stuff. It really changes the way you think about interacting with your customer and making sure that you develop really value-added products for your customers, and it will make you feel much prouder of the products that you are developing.
Our highest priority is customer satisfaction through early and continuous delivery of valuable software, according to the Agile manifesto. This can easily be applied to network engineering by simply replacing ‘software’ with ‘network services or features’. So, what this is not saying is always finish projects early and under budget. I mean, that’s how you are a hero as a network engineer, is by getting things done ahead of schedule and under budget, and that’s not really what they’re saying. This is saying to make smaller changes that you deploy early on in the overall development process and continuous delivery is to make small incremental changes so that we can deliver some working product. Some small piece in the beginning that’s a module or a chunk of the whole, and then keep bolting on pieces to that and be able to have our software or product developed in a way.
Consider the difference here between traditional and Agile. In traditional, we would generally only deliver the product at the very end when we think we’ve developed it entirely and to specification. With Agile though, we look to provide value to the client as quickly as possible and continue to provide value throughout the development process.
I’m sure you know that businesses move very quickly, our customer requirements may change every week, even every day, heck they might call you a couple times in a day with changing requirements. Because of that we need to really embrace and welcome these changing requirements and Agile development helps us stay nimble in our development practice.
This ends up resulting in shorter release time scales, the smaller the better. The smaller changes we can make, the more reliable they will be and the quicker that we can show that we are making some progress and deliver some value to the customer.
Business people and developers must work together throughout the project, so this is something you may have been involved in before, is that the BD team, the business development team, they will usually go out and drum up some business for your company. Once they get the requirements or have some meetings with the engineers and the customer, it’s handed off to the engineers or project management, and there you go, the project’s off to a start. Then you as the engineer will get going. Now the problem that you might encounter with this is that you don’t have enough customer collaboration.
As we see in the snip above, one of the values of the Agile manifesto. When your business people aren’t involved enough, then you as the engineers aren’t understanding the changes in requirements from your customer and that you don’t really know what will be valuable to your customers’ business. That’s the whole key, right? Delivering valuable products to the end customer. That’s why we need our business people and the customers business people interacting with the developers or the engineers continuously throughout the project, to make sure we’re in alignment with what the needs are and that we’re actually developing something that is useful and valuable to our customer. This is why working software or services are the primary measure of progress according to Agile. Again, this is where our shorter time scales and frequent delivery come into play; when you deliver a small piece of working network service, that is really the primary show of progress. Then you can bolt on another small piece of working software or service onto that and be able to build your end product larger and larger into this full system that your customer will actually get a great deal of value from.
Agile and DevOps, this is where things get a little muddy sometimes, because some people use these interchangeably, saying Agile is DevOps, and that’s just not really the case. There are really two separate gaps that are addressed by these two different frameworks and concepts. First up, Agile.
Agile really addresses the gap here between our developers / engineers and our customer or our business development. It focuses on consistent changes and helps manage complex projects and refers to an iterative approach which focuses on collaboration with the customer and customer feedback, with small rapid releases to make sure that our customer is really getting the value that they need out of our product.
DevOps over here though, is considered a practice of bringing development and operations teams together. The culture facilitating more collaboration and communication between our engineers and our operations teams. The central concept is to manage end-to-end engineering processes and that it focuses on constant / continuous testing and delivery. The gap between our engineers or developers and our operations teams is the one that’s being addressed by DevOps. If your operations team can’t manage or operate what your development teams or engineers have created then you don’t have a very functional product then do you? So, we need to have a culture of communication and collaboration between our engineering teams and our operations teams, and that is what DevOps really is. It is a cultural shift to try and enable collaboration and bring together as much communication between these teams as you can to make sure that engineering really understands the problems that operations encounters, and can make sure that they address these and are working together and collaborating with operations to make sure not only are they delivering features that the customer needs and are delivering value, but also a product that operations is able to manage and operate.