Purchasing and implementing new solutions is a big part of the game for IT departments. Any time we deal with purchasing new gear or solutions, we are working with vendors, partners, and resellers. When working with these outside entities, there are different requests that we can draft to send to our partners/resellers/service providers. These are named request for information (RFI), request for proposal (RFP), and request for quote (RFQ). Here are my interpretations of these three request types.

Request for Information (RFI)
A request for information (RFI) is sent to vendors, partners, resellers, or service providers when an organization knows at least at a high level the business need, but they require more information about how a solution functions, the problems it solves, and how it is implemented. An RFI will generally contain at least the following information:

-Description of the need or definition of the project at hand.
-Any necessary background information on the organization or the need/project.
-Any qualifications or caveats for selection of the solution/product.
-List of objectives for the need, project, or initiative.
-Timeframe of when the organiztion wants to purchase and implement the potential solution.

Request for Proposal (RFP)
To me, an RFI would be sent early on; in the investigation process of a potential project, when an organization is trying to find out what potential solutions are out there and available. A request for proposal (RFP), on the other hand, is sent out when a business is more serious about a particular solution. An RFP is sent out when a customer wants to see the specifics on how a vendor, partner, or service provider will implement a given solution and how it will fit and operate within the customer’s environment. At a high level, the RFP should outline:

-The project or need in question.
-The customer’s budget for the project/need.
-The timeline for which the customer wants to implement the proposed solution.

Request for Quote (RFQ)
My interpretation here is that a request for quote (RFQ) is similar to an RFP, but more focused on the associated costs of a solution. The RFQ is sent out to vendors/partners/resellers when an organization is ready to make a decision on a potential solution and wants to see both how the given solution will be implemented, but also the associated costs. Once a solution is selected as a result of an RFQ, that is when the contract/purchasing process will begin.

Rounding it Out
Unfortunately, products and solutions do not just magically show up on our doorsteps when we need something. For more in depth solutions, there may be multiple phases to the purchasing process and we can use request types such as the RFI, RFP, and RFQ to help us along the journey to meeting a business need.

In the previous post in this series titled Be Ready for ‘Anything’, we introduced the concept of disaster recovery. While organizations can do their best to design and implement redundant, highly available systems, disaster recovery plans still need to be made to handle the recovery process from large downtimes and/or disasters when they happen. Disaster recovery planning can be a daunting task and potentially even difficult to know where to start. We need tools and methods to help us determine what types of solutions to implement and how much we may need to invest in disaster recovery. As I have brought up before, any type of technology planning and implementation should first start with knowing and understanding the business requirements, and DR is no different. A couple of concepts to help us plan for and implement an efficient DR process are recovery time objective (RTO) and recovery point objective (RPO). I will be honest, these are two concepts that I had come across before and had no idea what they meant, so I was very glad to get to dig into the meanings as part of this Cloud Essentials+ journey. In the rest of this post I will cover what I have learned about the definitions of RTO and RPO.

Recovery Time Objective (RTO)
In my opinion, recovery time objective (RTO) is a bit more of a straightforward concept of the the two recovery objectives. Just as it is there in the name, time is the key concept with RTO. The goal of recovery time objective is to understand the amount of time a system or application can be unavailable before it is highly detrimental to the business and customers. Another way to look at it is that RTO is the amount of time in which applications/services must be back online after an outage or disaster.

Recovery Point Objective (RPO)
While RTO is focused strictly around understanding the amount of time in which recovery needs to happen, recovery point objective (RPO) is centered around data loss toleration. There is still a time concept with RPO, but it is directly related to data loss. RPO helps us understand how far out of date our data can be when it is restored so that an application or service is still relevant and usable. Understanding how far out of date data can be upon restoration ties directly to helping us know how often we need to take backups of our data. A more direct description of RPO is that it is the amount of time between the last known, good backup and a the outage or disaster. Let’s get into a quick example. An organization has an application that they support. The application’s database server is currently backed up once per day at midnight. That database server fails at 10:00 AM and must be restored from backup. Once that server is restored, there would be 10+ hours of data that is lost. The organization can use the recovery point objective concept to determine if that is good enough or if backups need to be taken more frequently.

Rounding Out Our Objectives
Understanding and leveraging the concepts of recovery time objective (RTO) and recovery point objective (RPO) can help us ensure that we are designing and implementing effective and efficient disaster recovery plans. In order to understand the requirements that go into determining RTO and RPO values, I feel that it is important for IT leaders to communicate with business leaders. IT departments need to properly understand the needs of the business to make sure they are delivering technology solutions, including disaster recovery, that meet the needs of the business.

An application or service is really only good to a consumer if it is functional and available for use. As much as we may wish they wouldn’t, IT systems break, go offline, and thus become unavailable. With this in mind, we know that if our business and customers cannot tolerate certain amounts of downtime, we have to plan for that and implement systems that can withstand certain levels of adversity. As with anything in IT, knowing the business level requirements is highly important so that you can design systems that meet and exceed expectations. The collective “we” have been designing and implementing redundant and highly available systems in on-premises data centers for years. The problem of things breaking does not go away in the cloud. Even in the cloud, we still need to understand our requirements and design, build, and deploy systems with redundancy, high availability, and disaster recovery in mind. In the rest of this post, I will do my best to give my interpretation of the definitions of these concepts.

Redundancy
If nothing ever broke down or had major issues, then we would not really need to worry about redundancy. Redundancy means that you are taking potential failures into account and removing single points of failure in the environment. The concept is that if one device or component goes down, there is another such device or component ready to carry the load, preventing large, lengthy downtimes and service interruptions. Given my background, I will give a networking example. In traditional Layer 2 campus networks, within a building we may have access layer switches where endpoints attach to the network, then connected to a distribution layer that aggregates the access layer. If business requirements suggest that there is a low desire for downtime, and budget allows, we will most likely have two switches in that distribution layer. Each access layer switch will have at least one link to each distribution switch. If there is a link failure between the access and distribution layers, or if one of the distribution switches goes down, the other is still available to pass traffic. Now, just because there is redundancy, does not mean there is no downtime. In the traditional Layer 2 network scenario, if a distribution switch goes down, some clients may still experience a service interruption while the Spanning Tree Protocol does its thing and the network re-converges. However, that downtime should be relatively brief and much better than if there was only one distribution switch and clients/devices were down until the switch could be repaired or replaced. If we want to further lessen the impact of device/system failure, we may need to take redundancy a step further and investigate high availability options.

High Availability
The goal with high availability is to reduce the impact of a failure as much as possible. In my experience, devices configured in HA share configuration and operational state information so that if one device goes online, the other takes over immediately. I have come across two main different types of HA systems, active/standby and active/active. With active/standby systems, both devices are synced, but only one (the active) is handling traffic. The active and standby are constantly communicating so that the standby knows if the active goes down. Once that happens, the standby takes over immediately, limiting the amount of impact and downtime. In the active/active scenarios that I have seen (and think I understand), both devices actively pass traffic for the data plane, but only one device handles the control plane functions. If the active control plane device fails, the standby takes over. Because the standby device was actively participating in the data plane before the failure, impact should be limited (Note: there are actions you can take with network devices to further speed up the control plane switchover to reduce that control plane impact as well.)

Disaster Recovery
While organizations can go through due-diligence in designing redundant, highly available systems, they still need to plan for failures, outages, and disasters. That is where disaster recovery enters the picture. At a high level, disaster recovery involves having specific plans and procedures for restoring services and operations after an outage or disaster. DR plans really need to be catered to the needs and requirements of the business. Two tools to help us in the disaster recovery planning process are recovery time objective (RTO) and recovery point objective (RPO). These will be covered in a subsequent post.

In Closing
Being ready for anything is a tall order and probably not feasible. What we can do is be as prepared as possible for adversity and things to go wrong (as they will). An important step is working with business leaders to understand their operations and what the availability requirements are for the different systems in the organization. Once those requirements are known and understood, we can better serve our organizations through the concepts of redundancy, high availability, and disaster recovery.

Networks have definitely been evolving over the years. While you can certainly still build and manage networks the good old fashioned way with the command line interface and interacting with your network on a device by device basis, there are definitely alternatives. There are technologies, applications, and systems that will automate your network operations and even assist with the initial build! Or, if you are not ready for that or don’t quite have the budget, you can still script the typical manual device interaction process to make it quicker, easier, and more streamlined. In this post, we are going to dig into the main alternative that I mentioned above. I am referring to the concept of software-defined networking (SDN). This was a phrase and concept that was very nebulous to me for quite some time (and it still is some days). I think you may get different answers from different people when you ask them to define software-defined networking. My high level definition, or at least my interpretation of SDN is as such. Software-defined networking abstracts the underlying network from the applications it supports in an attempt to have a dynamic, flexible infrastructure to support the varying business needs while remaining stable and resilient. Alright, I know what you’re thinking, “wow, it doesn’t get much more nebulous than that”. I guess that is my fancy way of saying “hooray for overlays”! I think that the keys to SDN are more-so in the characteristics than the definition, but I at least wanted to get my high level interpretation out there. In the rest of this post, we will go over the characteristics of and a use case for software-defined networking.

SDN Characteristics
My interpretation of SDN characteristics are the following.

• Centralization of Management/Configuration
  • A software-defined network should contain a separate management plane. This would typically be redundant servers that admins and engineers interact with to configure, manage, and monitor the network. Having a dedicated management plane controls the configuration of the network and allows for the removal of manual, per-device administration through automation.
• Centralization of Monitoring
  • By having a centralized management plane, you can also have centralized monitoring of your network. The individual network devices can be configured to stream logs and telemetry to the management plane server(s) so that admins and engineers have a single source for monitoring and correlation.
• Separation of Control and Data Planes
  • This characteristic is directly related to the “hooray for overlays” comment I made earlier. With traditional networking, all routers need to hold a route in their routing tables for all possible destinations in the network. Also with traditional networking, when you add routers to the mix, you isolate networks and remove the ability for clients to roam the network and maintain their Layer 2 adjacencies and IP addresses.
  • By removing at least most of the control plane from the individual routers, you allow for more efficient routing tables. SDN also allows for IP mobility through the use of overlay tunnels. Essentially, a native packet gets encapsulated into an overlay packet to get forwarded to the destination router. Rather than routers needing to know about all possible destinations in the network, they leverage a centralized control plane. Routers will inform the centralized control plane of devices connected to themselves and when a router needs to forward a packet to destination it does not know about, it queries the control plane. The control plane process will inform the source router which destination router holds the destination host and the source router creates a tunnel (overlay) with the destination router to forward the packet across the underlay routed network.

Use Case
The major use case that I want to bring up for SDN is around stability and mobility. To mean, a network design dream is to extend Layer 3 to the access layer to remove the complexity and potential stability issues around relying on large spanning tree domains. However, with traditional networking if you extend Layer 3 to the access layer, you remove the ability for clients on separate switches to be on the same Layer 2 domain and subnet. There are legacy applications and systems that rely on this to be possible. With software-defined networking, network engineers can deliver stable, Layer 3 underlay networks while still supporting this legacy mobility with overlay technologies such as LISP and VXLAN.

In Closing
Software-defined networking has really changed how we manage and operate networks over the years. One thing to keep in mind is that while SDN adds many benefits, there are potential downsides to consider. While SDN can remove the complexity of large spanning tree implementations, it adds complexities with overlay technologies. Yes, SDN products can handle that complexity for you, but if something goes wrong, you may need to understand how these overlay technologies operate to be able to troubleshoot quickly.

One of the major benefits of leveraging cloud services is the ability to spin up resources quickly. Depending on what consumers are deploying in the cloud, they, or perhaps their customers may also want fast access and good performance to those services and data. For instance, let’s say you run a video streaming platform. You would want to make sure that your customers experienced fast access to that video content with low latency. You would not necessarily want all of that content centrally located for consumption. Performance might be satisfactory for customers geographically close to the centralized cloud data center, but could be unacceptable for customers further away. This problem is solved with a concept called content delivery networks.

A content delivery network is a system of distributed compute and storage environments. The goal behind content delivery networks is to get data hosted as close to the consumers as possible so that they have a good experience when they access the content. At a high level, content is created originally on a system, then replicated and synchronized to the endpoints participating in the content delivery network, to be consumed by customers. Content delivery networks have the following characteristics/requirements:

• Content synchronization mechanism – As stated above, the content needs to as close to the consumers as possible. A CDN must have a defined method for replicating and synchronizing that data amongst the different cache locations in the network. You as a content owner or distributor want to make sure that a consumer can get to the same content no matter which system they end up accessing within the content delivery network. The look and feel must be the same.
• Global cache locations – To provide the most value, a CDN must have compute and storage environments in as many strategic locations as possible. In my opinion, content creators and distributors would want to be leverage a CDN that has the ability to get them the furthest reach to potential consumers.
• CDN-enabled namespace – How do CDNs steer traffic to make sure that consumers are requesting content from the closest possible source? This is accomplished with Domain Name System (DNS). A CDN-enabled namespace provides support to resolve hostnames to different IP addresses depending on where geographically the DNS queries are sourcing. For instance, if I am a consumer trying to stream a cool new TV show from a service and I am in the northeastern part of the United States, I hope that when my device does a DNS query for the streaming service, it will resolve to a CDN location relatively close to where I am physically located.

To me, content delivery networks, or essentially distributed compute and storage environments are a huge value proposition from cloud service providers. CDNs enable organizations to deliver content quickly and efficiently to consumers without having to build out their own, potentially global presence. On the other side, consumers are able to experience good performance by having content delivered from close proximity.