DevOps for Network Engineers

Editor's Notes

1. There is a constant feed of new and changed requirements from customers and users. Normally the developers and network engineers are not in close contact with the end-users. In contrast they get new requirements thrown over the wall without interaction.   In turn: - the developers develop new apps to fulfill the requirements and throw over the wall to operations team. - network engineers manually reconfigures the network and throw that over the wall to the operations team.   These two walls create: - confusion: from requirements to implementation, from reconfigured network to operational issues - time lag: the hand-over process is time-consuming
2. It is very important to distinguish different lifecycles. Two important layers are illustrated in the figure. BOTTOM: The long-lived lifecycle with running VMs/VNFs and TOP: the short-lived providing end-user services: telco:services, IT:applications Walk through the example bullets. Talk bottom-up Design separately, maybe different tools (more on this soon). BUT, they act together in a client-server relationship. Needs clear API linkage between the layers. The top-layer requests resources from the bottom layer. The top-layer does run-time config of the bottom layer. The bottom layer notifies the top layer on changes. The top layer need to adopt.
3. It is very important to distinguish different lifecycles. Two important layers are illustrated in the figure. BOTTOM: The long-lived lifecycle with running VMs/VNFs and TOP: the short-lived providing end-user services: telco:services, IT:applications Walk through the example bullets. Talk bottom-up Design separately, maybe different tools (more on this soon). BUT, they act together in a client-server relationship. Needs clear API linkage between the layers. The top-layer requests resources from the bottom layer. The top-layer does run-time config of the bottom layer. The bottom layer notifies the top layer on changes. The top layer need to adopt.
4. Look at the tools to the right. There are more well-known tools for the bottom layer. This also means that there is a risk that these tools are applied in the top-layer since they are known. Top-layer: APIs and fine-grained operations Bottom-layer: more templating Also, the “services” to use an over-loaded word in the top-layer varies much more than in the bottom-layer. A business VPN is very different between service providers, whereas starting a MYSQL server is more main-stream. Tools in the top-layer also depends heavily on if you are an IT Application-centric shop or a network service provider. For the first category the tools in the bottom layer might be ok.
5. If you are selling applications, the tools for long-lived life-cycles are appropriate also in the top-layer. The networking can be abstracted in the bottom layer. VIMs like OpenStack will hide/hard-code networking. Same with the tuning for the VMs, less effort in tuning the VIM for different VMs. I am not saying that IT is easy. Main challenge: Deployment of new application code several times per day. Needs extreme control on DevOps process for changing the application code itself. If you have internal control this is of course easier. External dev team, puts extreme focus on regression tests and deployment process.
6. For a network centric offering: Only the underlay network is performed in the bottom layer The top layer does all overlay networking The network layer can not be abstracted by for example OpenStack and VMWare or in the automation tools like Juju, HEAT,… More effort in tuning the virtual infrastructure VIMs for packet processing applications In the previous slide we talked about application centric offerings. There we said that a major challenge is that the application code might change several times per day. For a network centric offering it is the configuration that changes extremely frequently, thousands per day. the application code is changed with very low frequency. Since the top-layer is about high-frequency fine-grained configuration changes for varying offerings we need: Explicit data-models for the offerings APIs that support fine-grained operations
7. Process: Learning Sharing Collaboration Understanding business, other roles Practices: Automation Lean and agile Infrastructure as code Self-Service Automated rollback and recovery Tools: Share tools across organisation Configuration changes of different nature, different tools Pick-up tools from distributed programming, tools act upon text, not vendor blobs