Programmability enables the automated configuration and management of network devices via software. Large enterprise and service provider networks are comprised of devices from multiple vendors, with multiple operating systems and OS variants. Within these sprawling heterogeneous environments, programmability has become essential for executing network and service management.
A transactional-based orchestrator (or controller) enables network administrators to manipulate data, rather than devices. To support these environments, I recommend the use of YANG, a data modeling language that describes configuration and operational state data, and NETCONF, a protocol that is used to programmatically apply the changes to the relevant data stores of the devices based on the YANG data models.
Programmability and transactions abstract complexity away from the Orchestrator
In computer programming, a transaction is a sequence of information exchange and related work, like a database update. For a transaction to be completed and database changes to be made permanent, a transaction has to be completed in its entirety. Using YANG, developers can model the capabilities of the underlying devices and the service itself. This enables network operators to automate service provisioning in precise machine-to-machine transactions. They can define what the service needs to do, and implement it programmatically, without manually addressing the specific configurations of each network device.
When provisioning services by configuring network nodes, distributed transactions are essential. With distributed systems, there are many things that can go wrong. Database software or hardware may fail. The application can crash at any time. Interruptions in the network can unexpectedly cut off the application from the database, or one database node from another. Several clients may write to the database at the same time, overwriting each other’s changes. Distributed transactions help to alleviate these issues.
Without transactions, a system must be developed to deal with these faults and ensure they don’t cause catastrophic system failure, in order to maintain reliability. Implementing fault-tolerance is no small task. It requires careful consideration about everything that can go wrong and substantial testing to ensure the system works.
A transaction allows applications to group several writes together and execute them in the transaction as one operation. Either the entire transaction succeeds completely or it fails completely. If it fails, the application can safely retry as it has remained at the starting point of the transaction. Transactions are an abstraction layer to system changes. They enable an application to pretend certain concurrency problems don’t exist, allowing the device to take care of them. This permits a large class of errors to be reduced to one simple response – transaction abort. The application can just try again. Error handling also becomes easier for an application, because it isn’t concerned about having to handle a partial failure.
Transactions represent truth within complex actions, from start to finish
Network programmability driven by NETCONF and YANG is inherently transactional and a key enabler for automation. Network programmability with transactions is the ultimate foundation from which to build automated solutions that are rock-solid.
Transactions impart stability through four inherent characteristics: atomicity, consistency, isolation, and durability. These are referred to as the ACID properties. For a transactional system to be implemented properly, it must have each of these four properties. Atomicity ensures that all the changes in the transaction complete successfully or none of them complete. With consistency, all actions within a transaction take the configuration database from one valid state to another valid state. Isolation ensures that transactions are independent of one another. Durability implies that once a transaction has committed successfully, any data it has written will not be forgotten, even if there is a hardware fault or database crash.
Before we had transactions, network management systems required far more intelligence to be programmed into them. A lot of error recovery code was involved, and programmers had to know details about the system. Two classic network management problems when not using transactions are ordering and grouping. Ordering requires the orchestrator to be programmed to know the order in which to set things. With grouping, orchestrators have to be programmed to know what items can be set at the same time. Everything needs to be known and taken into account within the orchestrator. The orchestrator has to be prepared to perform error recovery and undo all the settings that needed to be made along the way, no matter when during the set of changes the problem occurs, as there are no transactions to guarantee the process worked.
It is important to note that ordering and grouping issues differ from network device to network device, even from the same manufacturer. This complexity grows even more for multi-vendor networks. Without transactions, this ordering and grouping knowledge for every device type used in the network becomes a very large and difficult problem to address.
Transactions solve the ordering and grouping issues. A set of changes is populated into a transaction and then the transaction is committed. The ACID properties of transaction tell us that ordering and grouping is not necessary. For network transactions, the device itself has the intelligence to automatically and consistently order and group the data that it receives in a transaction.
A transaction-enabled orchestrator allows you to populate a transaction with numerous configuration changes, send the transaction to a device, and all of the configuration changes will either happen, or they won’t. The underlying transaction system takes care of all the details enabling the reliability and the upper-level code is simplified. The programmer doesn’t need to do anything for error recovery if something goes wrong during the course of a transaction.
To learn more about the power of transactions, and why they’re so important, download our distributed transactions whitepaper.