Subscribe
Share
Share
Embed
Billions & Billions of eyeballs, six continents, 10k+ servers, and plenty of lessons learned over 2+ decades in IT. If you're looking for quick tips on optimizing tech, managing suppliers, and growing a business, 20 Minutes Max is the space for you.
Join me as I talk about things that come up during my day and share insights on taking your business to the next level. In less than 20 minutes, you'll walk away with actionable advice and strategies for success. Take advantage of this valuable resource for CEOs, CFOs, and business leader.
Hi. I'm Max Clark. And in IT, more is less. I'll give you three examples. Maybe I'll give you more examples, but I'm gonna start with three examples.
Speaker 1:In the late nineties, early 2000, the rage was Java application development. And we had application servers like BEA WebLogic that hit the market and then incredible options from the Apache project with Tomcat and then JBoss, and IBM had a platform. I mean, it was if you were doing enterprise development and you were building enterprise platforms, odds are you were using Java to do it. And by the way, Java is still very much a thing today. It just doesn't get the same hype cycle as it had at that point.
Speaker 1:Part of what you had to do when you were tuning and doing performance profiling optimization on a Java application server was JVM heat tuning. Bear with me. But if you know Java and program with Java, you understand this reference. If you don't, I'm gonna try to explain it to you in a way, which is if you think about having a a bucket and you slowly pour water into the bucket. And when the bucket fills up, you then have to pour the bucket out.
Speaker 1:And this is basically what happens with Java and its heap. So heap is memory, and it's an allocation. So when the application creates references to data, stores data, conducts operations, etcetera. It adds things to its memory. Right?
Speaker 1:So just think of the visual in terms of putting water into a bucket. And the issue with Java and JVM in heap profiling, heap settings is there were a lot of knobs you could turn. Like, what was the actual methodology? What was the mechanism for, you know, how it would reclaim heap? Right.
Speaker 1:You know, was was it dipping a ladle into the bucket and ladling out? Was it pouring the bucket out? Was it poking holes in it? Right? Like, there's different algorithms that would actually approach this, and then you had other options in terms of tuning, how big the heap was.
Speaker 1:By the way, this is basically what most people just did was said how big the heap was. But you could actually manipulate a little bit how the algorithm worked. You could select the algorithm. You could select which JVM you were running. The JVM would would function a little bit differently.
Speaker 1:Like, were you running SUNS? Were you running IBMs? Were you running, you know, open JDK? You know, like, there was different things that you could do. And, of course, then, you know, by default, you know, you get into a conversation with somebody and they'd say, hey.
Speaker 1:By the way, back then, RAM was really expensive. Really expensive. Like, a gig of RAM was like, holy smokes. We got a lot of RAM. But you get into these conversations of like, oh, you know, we've got a, you know, Sun, E 420 server, and we've put 8 gig of RAM in it.
Speaker 1:Let's just get 6 gig RAM to the heap, you know, to Java, and, like, it'll be so unbelievably fast. Like, it'll be incredible. And in this case, more is less. And every Java application environment that I've ever been involved with when we actually started going through profiling and tuning, you find that by giving it less memory and giving the heap less space, that operation to clean itself out runs faster, which is what you more than likely actually care about because there's conditions where the application server would just pause. It could do nothing until that operation completed.
Speaker 1:So by going from a bucket, you know, like a a trash can to a bucket to maybe, you know, a a a picture and I'm trying to use, like, visual references here. On the surface, you'll you think about that. You're like, oh, no. The bucket's way better because we can put more stuff in it. But the picture empties so much faster that it actually gives you what you want, which in many cases is just a really fast application and a really fast experience for your users.
Speaker 1:And, again, right, really specific to the application. If you had something and you needed to store, you know, like, for some reason that much, you know, your application needed, you know, 1.2 gig worth of heap. Right? Like, you couldn't give it 500 mega heat. Like, it wouldn't work.
Speaker 1:Right? But, again, we're talking in general here. In general in general, more is less. Right? So we need less, and then less becomes more.
Speaker 1:Another example that I still see to this day, which is wireless coverage inside of buildings. And you get into a conversation and the conversation kind of goes like, hey. We have really bad wireless performance in this building. Let's just go buy more access points. You know?
Speaker 1:Sounds great. Right? Like, you know, you've you've got 8 access points right now. I mean, you gonna buy 4 more, you're gonna have 12. Like, why not just get 30 more?
Speaker 1:Why not have 38 access points? You know, you can have an access point. And on top of everybody's head, just running the entire building. Same issue. More or less.
Speaker 1:If you haven't gone through and actually taken and done a study, a wireless distribution study in that building, you do not understand what is actually going on and why signal might be bad in certain areas. You might have interference. You know? I had a client and they their designer had this really fancy interior plan, and they used there was large glass windows and offices. So, you know, kind of your your your typical thing where you think, like, you know, a row of of offices on the outside window with, like, with, like, bullpens and shared space in the inside and then, like, cool collaborative work areas where you could kinda go in and, you know, like, think like a conference room.
Speaker 1:And they put they put these really cool window coverings and designs and patterns and, you know, art and stuff on these windows. And and it was. It was really cool. Only problem was whatever the freaking material was, I mean, I I'm assuming it wasn't lead because that'd be a big no no in the US. Right?
Speaker 1:But whatever the material was absolutely nuked Wi Fi signal. So, I mean, in a lot of cases, there was a Wi Fi access point sitting, you know, like, 25 feet away from that conference room with a glass window, and you're like, why can I not have it? You know, is there no wireless signal in this room? And you're like, oh, yeah. You know, whatever is on that window, it's like you know, it's it's like a Faraday cage for Wi Fi signal.
Speaker 1:That was a fun one. So, you know, you really you really do wanna invest the time and try to do a a wireless study, you know, if you can. It's worth it. You'll come through. They'll give you a map.
Speaker 1:They'll show they'll figure out different Wi Fi placement. They'll find hot zones. They'll find cold zones. They'll tell you, you know, where signal is not propagating. They'll find things that are interfering with signal, air conditioning ducting, pump motors, beautiful art on your conference room windows, you know, whatever it actually may be.
Speaker 1:And we'll help you figure out and actually tell you, you know, how many APs do you need and where you wanna go with it. Also, a big difference between 5 gigahertz and 2.4 gigahertz in and then, of course, with Wi Fi, you know, 6 starting to see devices support it and then Wi Fi 7, you know, coming out in terms of AP. Like, this changes the games again in terms of what frequencies and what spectrums you have to actually run. But let's just stick with 5 and 2.4. If you have, an access point that supports the 5 gigahertz band, it also supports 2.4 gigahertz band.
Speaker 1:The 2.4 gigahertz band goes a lot farther than the 5 gigahertz band, and now you have to deal with handoffs. You know, how does one AP handoff to another AP, and how does the device know to handoff? And maybe that device will go and switch from 5 gigahertz to 2.4 gigahertz. And you'll be walking through, and you'll be under another access point, but your device is still talking to the AP down the hall. And, you know, you've switched from 5 gigahertz to 2.4 gigahertz.
Speaker 1:Your performance is lousy, and you're like, you're looking up, and there's there's an AP right above you. But, like, why do you get bad service? And the answer again, more is less. You know, resist the temptation just to go out and buy 30 access points. Because what you really need to understand is what the heck is going on with your access points in the 1st place and your signal.
Speaker 1:And do you need to go through and change the channels that you're on? Do you have interference from your neighbors or something else in your space? Do you need to go through and tune your power output and receive sensitivity on your APs? Do you have to go through and configure how they hand off to each other? And the answer, by the way, you know, open book test, the answer to all those things is yes, yes, and yes.
Speaker 1:And if you haven't done that, you have to go do it. AP manufacturers will tell you they do this automatically. Some of them tell you that they have fancy AI that does this for you automatically. You know, like, whatever. Trust me.
Speaker 1:Yes. Yes. Yes. You have to do it. You have to do it.
Speaker 1:You have to do it. So more is less. What's another good one? More is less. Redundancy.
Speaker 1:Redundancy is a more is less thing for me as well. And if you've never configured spanning tree on a switch stack, I envy you. If you have configured spanning tree on a switch stack, you understand why I'm laughing. The, you know oh, we need redundancy. We can't have any single points of failure.
Speaker 1:Like, let's throw more network devices at the problem. You know? We need to have you know? And this by the way, the spiral's out of control really quickly. Okay?
Speaker 1:You know? We need to have a switch. We're gonna plug something into that switch. Oh, that switch is now a single point of failure. Let's get dual power supplies in that switch.
Speaker 1:Okay. Great. Now it's got dual power supplies, but still a single switch. Let's get a second switch. K.
Speaker 1:Great. We have 2 switches with 2 power supplies. Are our PDUs separate? Okay. Good.
Speaker 1:They're separate. Are they running to different electrical distribution panels or switches? Yes. Okay. Great.
Speaker 1:Do those have different batteries behind them? Yes? Okay. Great. Do those run into different generators?
Speaker 1:I mean, so I mean, this is like a tier 4 data center design. You probably don't have this in your office, but we can just just keep talking through this. Okay. So now you have 2 switches. The 2 switches.
Speaker 1:Now your server needs 2 NIC cards. K. It's plugged into 2 switches. How does a server decide which NIC it's sending traffic over? How does the network decide what interface serves back down to you?
Speaker 1:By the way, here's a little side pro tip. When you are doing bonding or teaming with your network interface cards with your NICs on a server, if you have 2 25 gig NICs on a server or 2 10 gig let's just say 10. If you have 2 10 gig NICS in a server, yes, you can build an ether channel. You can team them. You can bond them.
Speaker 1:Whatever terminology you wanna use, I don't care. And in theory, you've now have 20 gig of capacity. And, yes, you do, in theory. The caveat to that is your maximum stream for data. Like, if you're doing a data transfer, unless you're breaking that data transfer up into multiple streams of transmit, it will saturate at the network interface.
Speaker 1:Right? So you've got 20 gig worth of, you know, of network. Right? But you really only have 10 gig for data transfer. So if you were wondering why why things aren't working in our network, it's probably just because of that.
Speaker 1:Anyways, so you've teamed the 2 next, which which which switch is it talking to. Right? So what do you have to tell the server? You have to tell the switches which which interface is coming down. How do you manage that?
Speaker 1:Okay. Now you've got 2 switches that your server is plugged into. Then those 2 switches have to go plug into 2, you know, and we can talk about leaf and spline. We can talk about, you know, what your core distribution looks like. Let's just keep it really simple and just say you've got some sort of central distribution with some sort of, like, interact distribution.
Speaker 1:Or if you're in an office, you've got switches in an MDF on a floor, and those switches in the MDF then come down to some sort of central aggregation point or core core distribution point. Right? Well, now, of course, you have to have 2 switches in that core. Right? And you need a firewall, but, nope, you need 2 firewalls.
Speaker 1:So those 2 switches have to plug into 2 different firewalls, and those 2 different firewalls now need to have 2 switches on the outside of those firewalls and those 2 and those switches on the outside need to have redundant interconnections. Maybe you have routers, maybe you don't. Maybe your switches are your routers. And what you've created is you've got a really nice diagram now where, like, you know I mean, if you just draw the public side of your firewalls, your firewalls, and your switches and your inside side, you've got a lot of lines on that diagram. Right?
Speaker 1:Because your firewalls, more than likely, your default is your firewall is gonna have 2, 4, 5 interfaces on it. Right? So it's got one to each top switch, one to each bottom switch, and and going into each other. Right? So there's 5 interfaces.
Speaker 1:And this isn't like you just plug it in and it works. Right? This is you have to plug it in, and now you have to go through, and you have to start configuring each element of your network with how it actually sends traffic on a normal state. And then almost on a failure state, what happens, and how do you define a failure state, what goes on with it? And then at some point, you know, you finally add that one last magic piece of device, and you have no idea why, but you plug in a, you know, a fish tank, and the entire thing just goes it just stops working.
Speaker 1:And then, you know, after spending hours trying to figure out why it isn't working and struggling, maybe you call somebody like me in a past life in, and we get to physically unplug every network cable, trace everything, plug everything back in together, and then rebuild this over a really excruciating long weekend where we don't sleep for 80 hours to get your network back up and running. So that way you can process orders and ship product at your at your warehouse. And by the way, this is a true story. And if you notice my attitude right now, I was supposed to be on vacation when that particularly story happened and, you know, didn't happen for me. But, anyways, a lot of times in IT, more is less.
Speaker 1:So, you know, before you throw stuff at the wall and and hope it solves a problem, maybe just take a moment and think about it. Like, how often does a switch actually fail? Like, how how you know, I'm not talking about infant mortality rates. I'm not talking about you bought, you know, 500 switches from, you know, non enterprise switches, but, you know, 500 switches from your, you know, server manufacturer of choice. And you're expecting, you know, 10% of them just to not work when they unbox.
Speaker 1:But how often has your switch failed, and what happens if it does fail? And what is your recovery pattern of having 2 switches and trying to have them both online at the same time versus just having a switch in the box sitting next to it that you can take and plug into the rack and move all your cables. And also pro tip on this one, print out the config and have the config taped to the device that you're gonna replace. Now you should have configs management, and you should be doing a bunch of other things. But in a pinch, if you've got that config printed at least to a state that you knew that device was working and you can type in all the commands sequentially, you can get back online, and it's usually really fast.
Speaker 1:Almost might be faster than trying to get the config management system talking to that device and pushing that config back down to it. I'm a really big fan of just having spares on-site. Most applications, unless you really do have a true life or and death or measurable financial impact that dictates that level of redundancy, don't poo poo on having, you know, single devices, a single firewall, and a single switch distribution with a single edge. Like, it's a really simple network. It's hard to break that.
Speaker 1:It's hard, you know, for bad things to happen to you there. It's not as sexy. I get it. But, you know, more is less. Anyways, I'm Max Clark.
Speaker 1:If you have questions, you know, comment below. Yes. You should have redundancy, and people are gonna yell at me for that. And if you wanna just get into it, fine. You know?
Speaker 1:I'll I'll I'll be there for you in the comments. You know? Like, go for it. But, anyways, hope this helps. If you have any questions, need help, reach out.
Speaker 1:Happy to help.