The Shift in Availability – Network Design Principle Availability – ZNDP 069

ZNDP 069: The Shift In Availability - Network Design Principle Availability

Zig Zsiga:
The shift in availability Network design principle availability episode 69 in today's episode I want to help you I want to highlight the shift in availability we've seen over the last few years what does this mean this is about the network design principle availability. I want to make sure you're setting yourself up for Success here with your network design decisions so stick around and here we go.

Zigbits Podcast Intro:
Welcome back my friends, nerds, geeks, and Ziglets out there we have another episode of the Zigbits Network Design Podcast where Zigabytes are faster than gigabytes we strive to provide real-world context around technology.

Zig:
Hey what's up everybody I hope everyone is doing great today. Zig here and welcome to episode 69 of the Zigbits Network Design Podcast my name is Zig Zsiga and I am here to help you with Network Engineering, Network Design and Network Architecture, and one of those topics I want to cover today. That we should be covering is availability. Specifically the shift in availability and how it changes our design mindsets and how it impacts and influences our design decisions.

Zig:
Let's go ahead and dive into Network availability and part of network availability includes resiliency which we covered in ZNDP 64 and it also includes reliability which we covered in the previous episode ZNDP 63. Network availability includes resiliency and reliability of a network. It also includes concepts and techniques like redundancy, fast convergence, scalability, simplicity, and manageability.

Zig:
We also did a recent episode of the Zigbits Network Design Podcast Episode 67 where we had a conversation with a fellow CCDE and Network Designer and Network Architect Darren Fullwell. We discussed how availability is part of the CIA triangle of confidentiality, integrity, and availability.

Zig:
All of this comes down to the large shift with availability is that it's no longer Network availability, but rather an application and service availability. I would also say it's extremely imperative and important to highlight that this is an unstated requirement. What do I mean by unstated requirement? That means that our customers, our users, they do not come out and say they need a high level of availability, that application that service needs to be highly available. You as a designer as an architect even as a network engineer you have to get that information from them. You have to ask leading questions to get that information so that you can make proper design decisions.

Zig:
Why do we have a network in the first place? I have to be fully transparent and honest. I never actually processed this question in my early years in this career, in this industry, in this field. If you do not know the answer this question, like me and those beginning years, well here it is. Here's my answer right now. The network is a service. It is specifically getting data from point A to point B, at the right time so that it can be properly leveraged by whatever's on the other end.

Zig:
If you take that kind of definition, this leads to the Focus Shift on applications and services that are sitting on that other side. Think of it like you have the applications and services on one side, and you have the end users and clients sitting on the other side. That's traditionally how things work. You have consumers users of those applications and services but nowadays you also have applications and services consuming other applications and services so that it kind of changes the perspective of the flow of traffic if you will.

Zig:
If we boil all of this down the network facilitates all of this and it's seamless to the resources. I would do resources of air quotes if I was on video so that's the point the resources is everything. It's all of the things, it's your applications, your services, your servers, your users, your devices, and your clients. Whatever you can think of whatever physically or logically connects and gets on the environment in some fashion. It could be virtually, it could be physically, those are resources

Zig:
From all of this, we can say that it's not necessarily Network availability we are truly concerned about when we are Designing Networks. It's application availability and service availability. This is that specific shift in our mindset and our design mindset that has to happen. The network is the plumbing to our running water and our house and data is that water. Without the network, data cannot arrive and I think that kind of sits pretty well from an analogy perspective because. The network is the underlying infrastructure like the plumbing is the underlying infrastructure, the electrical current electricity to a house is underlying infrastructure the network has become an underlying infrastructure to data and applications and services.

Zig:
If we can transition this kind of thought process we take this a step further because this is a larger concept. Now, these days it's not just data transporting the network. No one else understands what data is or the bytes in bits on the network the ones and zeros. Remember perspective matters here. Users only care
if their application works when they go to leverage it.

Zig:
Have you ever picked up a POTS phone, a plain old telephone system phone, And not had a dial tone? For those that can remember the days when we all had landlines at home then. I don't have one anymore but some of you might. I personally don't recall ever picking up one of those phones and it not working. This is where the network sits now if we pick up a VoIP phone and it doesn't work what's the impact? If a user tries to access email but it doesn't load what's the impact? If the cloud provider that hosts your company’s SaaS application has an outage that affects your SaaS application and now your customers can no longer access it, what's the impact?

Zig:
These are leading questions mind you and they're open-ended questions. You have to think about the impact and the impact is going to vary depending on the situation that you are in and how your organization and your company functions. The impact is going to be about the business. As a network designer, even a network engineer, even a network architect, all three roles we are talking about, we have to identify the required, and in most cases unstated requirements here, level of availability for these applications and services. We have to strive to maximize this identified level of availability while keeping the constraints in mind.

Zig:
This is not easy. This is not an easy task. This is hard, but as Network Designers, Network Engineers, Network Architects this is what we do.

Zig:
Now I would transition this because again we're talking about application availability, we're talking about service availability. We have to partner with the application owners to truly understand the requirements and interdependencies of each application and service.

Zig:
Over the last year, I've recommended to companies and customers, and colleagues that they create an Application Assessment Team. You can name it whatever you want. Some people like to use tiger teams and this you know special application team. Whatever the concept is still the same. This team has the following roles and purposes.

Line of Business Owner - This is your driving business stakeholder for that application. They understand the application's business role and its impact. They also understand the monetary implications of this application and they can help you appropriate business resources and priorities today to help this effort.

Security Specialist - Here this is going to be all about security controls, compliance regulations, and auditing of code. These are all critical functions that will direct decisions and actions from a risk management perspective for the specific application

Application Owner / Developer - This is the point of contact from a software engineering perspective or development perspective for this application. Think of creating code, modify current code, drive the associated technical requirements from an application perspective.

Network Engineer / Designer / Architect - This is where we have the network engineer, the network designer, and the Network architect. We facilitate the network resources to properly service the application based on the different requirements from the line of business owner that we talked about at first, the security specialist which was second, and then the application owner. These four roles if you will, work hand-in-hand to help drive proper application availability, security, and overall policies.

Zig:
This framework here is how I've been telling people how to identify the applications and properly identify the availability for the application and ensure that it's met honestly. Now I've seen applications go through this process where no one even knew or knows at the time what the application was supposed to be doing.

Zig:
There are so many of these occurrences. Applications were built 20 and 30 years ago but no one remembers why it was built and they don't even know what it's doing. This is why this kind of group of people has to be brought together. You have to kind of assess the application see what it's currently doing validated it should still be doing these things and then documented appropriately.

Zig:
As you go through this process, as you go through this application assessment process from a network design perspective, each application and each service will be leveraging different portions of the network or the infrastructure and you as a designer will need to properly identify what the application is dependent on. Dependencies here. Then make appropriate design decisions to ensure the level of availability for that application.

Zig:
Now I always like to say that part of this process that's really overlooked, that shouldn't be and again like most other items in networking is documentation. The application assessment team should be documenting everything that is discovered, decided on, and implemented for this application. I would kind of call this like the application binder if you will. It should include all failure states with Associated success criteria. It should also include all requirements and where they originated from, and then finally it should include all security controls and regulatory standards that this application must comply with. You put this in this binder and it makes it very clear.

Zig:
This application binder helps in the future when maybe the group is gone and another group comes in and has to review the application again. It's more than that you're documenting these applications from a business perspective, so the business owners can see what the application is doing for the business. This is extremely valuable in a number of ways to a number of different people within the organization. I've gotten so much traction by doing this, from the customers that I work with. I definitely recommend setting this up, this process, this team of people, and you can actually have this team focus on more than one application at a time.

Zig:
You can have this team focused on a few applications a week and once you start documenting everything it gets really quick and really in the process is actually truly outstanding.

Zig:
Let's flip this back over to the topic at hand. This was a sub-topic within the application binder in the application assessment process or team but if we go back to the application and service and actually understand availability.

Zig:
For the end-user it is seamless. They don't know what's going on under the hood. They don't know there's a network and there's data and there are routing protocols and there are security controls and It might be VPNs, they have no idea. All they know is they're going to that application in some fashion, email if it's email like Outlook. A SaaS application that might be like a browser-based application that they're just browsing to that's either on-prem or in the cloud and you know their expectation is it's going to work and if it doesn't work they're going to give that helped us a call or they're going to bug you

Zig:
The point here is that we have to associate the level of availability based on the needs of the business and the needs of that user and the criticality level of that application. Then we have to define the controls the standards the features that are going to govern the availability under the hood for that application.

Zig:
I use this term quality of experience.

Zig:
Quality of experience is critical and that's where this all falls into is the quality of experience for the end-user here is what matters. If we can't maintain that quality of experience for that end-user, we don't maintain it and they can’t complete their job what's the impact of them not completing their job and the right time frame what's the business impact monetary and non-monetary. What's the impact on other teams within the company of the organization? Then what's the impact to other customers potentially depending on what type of business you're in that user that we're talking about that person that client that's leveraging that resource.

Zig:
They are not concerned with anything under the hood the again the networking mechanical functionality under the hood of how the application or how the service is delivered to them. It just simply needs to be available and consumable at the right time, at the right place, with the right data. For us, as Network designers, we have a whole bunch of options here to ensure this happens. We have high availability Technologies we can do fault tolerance we can use some of our Network design principles.

Zig:
We've already kind of talked about but we also use some of our Network design techniques like modularity and fault isolation and fault domains and blast radius. Those are all techniques that we can leverage to isolate issues that could bring down these applications. If we can go ahead and take the network design principles we've talked about, the network design techniques, we've talked about, and the network design fundamentals and really wrap them all together but then focus our availability concerns on the application and services in question. At hand that's how we can ensure a highly available solution for those applications and those services.

Zig:
Hey Friends, Nerds, Geeks, and Ziglets that's going to close out today's episode of the Zigbits Network Design Podcast where we discussed the overall Shift in Availability from the Network to the Application and services. Keep in mind that Availability is one of our Network Design Principles that we all should know. We'll have all the links and all the things mentioned on our show notes page which is https://zigbits.tech/69.

Zig:
Today was fun, I haven’t done a Solo-show in a long time. I hope you enjoyed it.

Zig:
I think a lot of us never learn Network Design elements until later in our careers, and my goal is to fix that. You can check out my other free Podcast Episodes and YouTube Videos that do just that!.

Zig:
If you haven't’ heard yet, I am creating a Network Design course! Yep, I am doing this! It's a real thing and I am super excited about it! This course is a vendor and certification agnostic Network Design Course. My goal is to literally make you the best Network Designer you can be no matter where you are in your career today, be it just starting out or a 30-year seasoned network engineer. If you want to hear weekly status updates on where we are with this course, join the email list here. I send out a quick email every Friday highlighting what I did that week and what I plan to do the next week. If you are interested in knowing more, that sign up link is zigbits.tech/networkdesign.

Zig:
If you have any questions, comments, or just want to say hi, You can find zigbits on all of the socials: Twitter, LinkedIn, and Facebook by searching for Zigbits. You can also find me on twitter @Zig_Zsiga and LinkedIn. You can also email me at zig@zigbits.tech.

Don’t forget to #AttackYourGoals #AttackTheDay #MakeProgress on the things you care about!

As always I appreciate and thank you for listening!

Bye for now!