Pop-up Webinar: CMS Maintenance - Why Your Website Suddenly Breaks Down

Okay, everybody, thanks a lot for joining me today. Happy Monday morning. 
Today, we have a very important topic, CMS maintenance. We're going to talk about why your website just suddenly breaks down for no reason. It's a super frustrating thing.
With that said, let's dig right into it. I'm not going to have any questions at the end of this webinar, so if you have any questions, you can use the system, WebinarJam. It's our first time using it. Hopefully everything goes well. If you do have any questions, though, feel free to send it in the chat. It'll come directly to me. Or reply to me personally. We can have a conversation about it.
With that said, let's just dig into what we're doing today. First, I love this line from Austin Powers. Not the best movie, but, "Allow myself to introduce myself." I'm Peter Czech, CEO of the New Possibilities Group. Founded NPG back in 2001. My background is custom web development, user experience, and that's my contact information, if you ever need to get in touch with me.
What is a pop-up webinar? Basically, it's always going to be on Monday morning. It's going to be based on our blog post. It's only going to happen if I think it's something that's really exciting that we need to talk about. I swear, I'm going to be quick. I'm trying to get done in less than 20 minutes. If I go on longer, I hope you hang around, but I'm going to try my best.
Today's agenda, we're going to talk about the overview of the website, CMS maintenance, why these meltdowns occur. We're going to define what maintenance really means, and then talk about preparing and avoiding these issues in the future. Finally, we'll wrap up and move on with our day.
First off, about us. What do we do? We're the experts in development of safe, secure, custom content management systems. We focus on complex web development and design to create websites and applications for clients with complex requirements. We don't tend to focus on simple, informational sites for restaurants up the street. We're looking at enterprise level content management system implementation.
We haven't done a webinar in six months.  I have to tell you why. A lot's been going on. On the upper left, we have a new ... That's my son. My second child joined us. We have a new office. There we are kicking it off on the lower left, with a little champagne toast. Some of our employees got some new dogs, new puppies. 
There we are making our new office presentable, putting down some carpet. Some of our employees had vacations in places like the Philippines, and Iceland. In the middle there, this was just last week, we 24 inches of snow dumped on us. So we've been busy. I am planning on doing a couple more webinars in the near future, so hopefully we'll get back to a regular routine.
So why are you here? Most likely, you've had some level of maintenance issues in the past with your website. Maybe one day, you woke up, and your site just wasn't working anymore. Maybe you're trying to plan for what your future maintenance needs are. 
It's frustrating. There's nothing more frustrating then when your website just stops working. People oftentimes can't understand how can it be that if you change nothing, nothing has changed, you wake up, and the site just isn't working anymore. It's frustrating for me too, because a lot of times, there's a lot that's happening on the back end here that we want to explain.
You can sort of compare it to the physical world, and you sort of can't, at the same time. All assets need maintenance. Your website's an asset, much like a building, your house. Buildings somewhat are a little bit easier to understand. Like I said, we had 24 inches of snow. A bunch of things around the house were having issues that day. Mother nature plays a role. 
Maybe you have physical parts. I have a rental property, last week, that something in the tub broke. You expect it, because it's physical, and it's being used. Usage, and then other environmental factors, these contribute to why a building might have an issue. The difference between a building and a website is, well, a building never goes 100% down. It's always usable to a certain extent. But your website, it just suddenly stopped working.
Why do they need maintenance? The issue is websites are really complex. There's hundreds and thousands of moving parts. Unlike a building, where you have your framing, and then you have your electrical inside, your exterior, your roof, plumbing, yeah, those are a lot of complex systems. But at the root, there's not a lot of moving parts underneath. There's not thousands of moving parts.  That's really what makes a website work. All these parts working together. 
This is the number one reason you have to take maintenance seriously. The issue is dependencies. I found this when I was preparing for the webinar. On the right, this was something that was pulled out, it was an automatic mapping of an enterprise piece of software. These are the dependencies. It's not the globe, it's not anything like that, it's dependencies between features. You can see, when he zooms in, just how precise it gets. 
There's more dependencies with websites than with any physical assets. In our blog last week, we created this model, that you can see on your screen in front of you. This model talks about the different layers. I call it the cake, because it has a lot of different layers that affect how your site works, how your application works.
On the top, we have all of our visitors coming in, in a variety of different ways, different routes, or there's different OSes. They're coming in to use your website, your API, your CMS, and all these things underneath it need to work. So what I want to do really quick is break down what each one of these parts are, and try to give you a sense of these dependencies.
Your first thing is the network. The network is the connection of your digital system to the rest of the world. Right now, just to connect to watch this, you're connecting to your local ISP, which is going into the backbone, which is going to WebinarJam. WebinarJam's doing work on the other side, connecting me to you. All these networks working together, this is how your web server actually gets delivered to the world.
Now, interestingly enough, and I'm sure that most people on the call today understand at the top level how the networking works, front end technologies introduced even more networks into this already convoluted thing with every pixel that you place on your site. Not only does your website go through a bunch of hops, 20, 30 hops to get to the server every time a client makes a request, but every pixel you embed is introducing more network connectivity, and a whole 'nother layer of complexity. That's something I think people don't really think about, and you have to keep in mind.
On top of your network, you have your server. The server's a physical box. It's kind of like the home of your tech stack. The computer that I'm on, the computer that you're on, that's much like what a server is. It's a physical computer that has software installed on it. Now, today, obviously, a server can be virtualized, but it's still sitting on a physical piece of hardware.
Some names in this space that you might see, Microsoft, Red Hat, Oracle, CentOS is a flavor of Linux that I prefer to like. You need a computer running server software to be able to communicate to the rest of the world. As you'll see, as you start to understand how the layers work together, the server and the operating system needs a network. Then, on our next level, we're going to dig into what the web server is. That needs a physical server, which needs a network.
The web server is this piece of software that actually facilitates a transaction between the client and the server. When an HTTP request is made, your web server is going to be sending that data through to the client through the network, and that runs on the physical server. That's only on level three. Trying to give you a sense of the complexity here.
So your web server obviously delivers assets to the client via the network, and it connects all your technology stack to the outside world. This is where you're here, where it's Apache, or IIS, and some of these other players that are on the screen here.
Now, on top of all that, now we're going to start getting into what your tech stack consists of, in terms of running the software that might power your CMS. So, we're talking database. You have things like Mongo, MySQL, SQL Server, Oracle. Your database stores critical data. It should connect seamlessly to the scripting language that powers your website, your CMS, and the rest of your ecosystem. 
To confuse you a little bit more, most of these systems are also servers, and they're running on top of the physical server. Again, connecting to the network. It all ties together.
Moving on. If anybody needs to take a break, or to bang your head against the wall, you'll know what it's like on a daily basis, trying to diagnose problems with websites. 
Level five, here, we have scripting. Scripting is really the language. A lot of clients come to me, and they say, "Hey, you work with this language, or that language?" So people are aware of what these are. Maybe not aware how it all ties together, but most people know what these things are.
Scripting, you have to think of it as glue, and it sort of ties everything together. The scripting handles request information from the client, ties it together. The database pulls out data, puts it on a display layer, puts it all together, sends it out via the web server to the client. That's how these transactions typically happen, which could be a simple page load.
Everything has to work in tandem. If it doesn't, you'll start to see that. The scripting language will output errors, so it's a good way to diagnose, at a top level, how things are going.
Popular languages that I put here, PHP has been, for 20 years, the basis for so many different projects that are out there. WordPress, Drupal, Magento. They all work on PHP. A new player is Node.js, a great JavaScript platform. I think it's great. I love messing around with it. Not really recommending it too much. I mean, in our class setting, yeah, but it's a spectacular framework. Rails, built on the Ruby language. ASP, another Microsoft entry. There's literally hundreds of these. Hundreds of scripting languages out there. Perl, Python. You can go on and on. I'm just highlighting some of the ones that I kind of prefer to play with.
We've got that entire cake, all those layers. Now, on top of it finally, you have your front end experience, the CMS and API. Just to summarize, your CMS and user experience is built with scripting languages, which connects to a database, gathers up all of its information, uses the web server to send it to the client, lives on your actual server, connects to the network, and then that goes through the world to get to your client. These are all the moving parts that make your website or application work. Is it complex enough? I'm out of breath.
All these layers, they need to work together. They have to work in tandem. They need connectivity to each other. At any point, anything that goes wrong can happen at any one of these layers, so every single layer needs attention, and it needs support, maintenance, to maintain stability.
On top of all this, don't forget, every one of your clients coming to the website or app are using different devices, different operating systems, different software. Some of it's old. Some of it's new. Some of it's beta. Some it's not supported anymore. The list goes on and on. 
So just because you have a problem, and you look at all those back end reasons why it might be happening, you also have to look on the front end, and try to recreate what's happening for a particular user.  There's a lot of ways. The web is the most complex medium ever, and this is why it's so shocking that so many people don't take maintenance seriously. 
So that's the first concept I wanted to talk about today, was dependencies. The second one starts right here with the NP Group pumpkin, because I think we kept the pumpkin out until December, and then we decided to throw it out the window, because it became a tradition. Rot. Rot is a huge factor in why maintenance is an issue. Much like leftovers and house guests, software starts to rot, and it starts to stink.
Why does it happen? The first thing is dependencies. All those layers, they're changing, they're evolving, they're being updated and upgraded on a regular basis. If your software's not keeping up with those layers, the server, the network, and all those things, the scripting language, the database, your software can start to rot.  It'll happen slowly. 
What might happen also is poor continuous improvement. This happens so often. I think it's just the nature of marketing, and marketers, where you have requests, and you want to make a quick change to the website.  "I have a phone call from an important client on a Friday. I need the website to do this. I need the application to do that." Well, the developers are under duress, they move quickly. They make changes. This leads to technical debt. 
Technical debt is a series of, I guess you could say, bad decisions technically that has a snowball effect, where the snowball's rolling down the hill, starts the size of a baseball, and turns into a boulder. This is something that leads to rot as well.
Another thing is if you just ignore it. You just completely ignore your update and upgrade cycle, especially with off-the-shelf software, like WordPress, and Drupal, and things like that. If you're not updating, if you're not upgrading, it'll lead to chaos. If you've waited too long to do it, it'll make it so much harder to do it later, simply because of, again, all those dependencies. These are some of the reasons that software starts to rot.
Some people say just ignore the updates and it'll keep working. But it won't. It actually leaves you in a worse position, because then you're going to be vulnerable attack, penetration. Terrible things can happen if you're not updating. It's not enough to say, "Well, updates are complex, so I'm going to ignore it." That's not going to get you anywhere. It's just going to create an even bigger problem.
How do you avoid surprises? Waking up at 8:00 in the morning to a website that's been down for five hours? That's avoidable. Having your Friday night plans ruined because the server's down? That's avoidable as well. Really, it depends on having a proper maintenance and setup.
I look at maintenance, it's not necessarily changing light bulbs. It really looks at some of those layers, and approaches those, make it a little bit simpler. We talk about the server and network admin, the tech staff, the CMS, and the user experience.
The server and network admin. I'm going to tell you about the type of people and parties that would conduct this for you. A server and network admin needs a deep understanding of networking, needs to understand how the operating system works, the OS. They need to understand server structure. They also have to have a sense of the client and server relationship, and the type of communication that's happening.
They also need an understanding of what's the software that's being run. One of the things with hosts like AWS, and Rackspace ... and they're great. I use both of them. You call tech support over there, amazing sysadmins, but they're only going to help you to the door of the server. They don't have that understanding of the software that's on the server. That disconnect could be catastrophic when your site's down.
If you're planning on having a team help you for maintenance, you need to make sure they not only understand how the network works, but they also understand the underlying software situation.
Then you have your tech stack. The tech stack is more of a developer, but it can also be a system admin as well. This needs to maintain the parts of the stack, so the scripting, the database. They need to understand what's in the database. What's the data that's being stored. If they have an understanding of that, they'll be better able to index it, which is a method to make everything more efficient. These are things that, if the sysadmin doesn't have a sense of how everything works, they're not going to be very helpful to you. Again, [inaudible 00:15:34] or the AWS example.
The tech stack, again, ties everything together, so you need to make sure that person really understands all those moving parts. And they need to understand both sides around that. They need to understand the server and the network, but they also need to understand how the changes to the tech stack actually affect the software that's been built, whether it be front end or back end.
Also, we have the CMS. Whoever's maintaining this for you needs to understand server and network, because at one time or another, that's going to come into play for them. Then, they need to understand, from a business perspective, what does the CMS do? What's the administrative workflows? What are the goals, and what's it trying to achieve?
They need to be able to manage the code that the CMS is built on. They need to understand how the upgrades below them, to the stack, whether it be the database, or the scripting language, are going to affect the performance of the CMS. This is a major point. So many people don't really have maintenance, but they let their host go into updates, and then their website breaks. Why'd it break? Well, turns out the CMS wasn't ready for the update. Maybe the PHP got upgraded, and a feature got turned off, which is called deprecation. Happens all the time.
Finally, also, the CMS, whoever's managing it needs to understand the front end experience as well, because that is the whole reason we're here. Let me segue over to that. Then you need maintenance to get a sense of ... or, maintenance in terms of your front end experience. 
[inaudible 00:16:55], everything I've talked about for the past 18 minutes, and I'm sort of still on schedule there, everything isn't even client facing, unless your site is down. That's all happening on the back end. So it's not enough to have maintenance on the back end. You need someone maintaining the front end experience as well. This means someone who understands the CMS, understands the tech stack, has a sense of networking, but also knows on the front end how things are supposed to work, and is performing regular sweeps of functionality. 
This is something that you can do in an automated fashion with automated testing, but nothing really beats going and just having somebody fill out contact forms, running through transactions, doing the most important tasks manually on a regular basis, because A, they'll find issues, and B, they'll figure out ways to make it better.
Remember, maintenance, it's like an old 80/20 rule. 80% of it no one's ever going to see, but don't ignore that 20%, which is everything that's client facing.
Really quick, as I'm running out of time here, how do you cope? How do you cope with these possible issues, and avoid surprises? The first thing you can do is just minimize dependencies. Like I spoke about, there's thousands and thousands of dependencies. It's not always an option to minimize them entirely. You can't take WordPress and remove some of the things, or you can't not have a tech stack, and worry about updating it, because WordPress needs it. You can't go and make it into a static site. There's just options that aren't available to you.
But there is new technology that you can use, such as headless CMSs, which basically offloads all of the worry about the server, the network, the CMS, which is the head, obviously, and taking that and handing it over to another organization. What's the difference there? Well, it's a license arrangement. It might be a little bit more expensive than what you're paying today. You're going to have a continuous license fee.
But this is the wave of the future, is taking parts and handing it off to people that can take that stress for you. That'll not be realized as long as platforms like WordPress, and Drupal, and a lot of the commercial stuff as well is as popular as it is. It's the most popular CMS. It's also the least secure. I'm not going to go too far on a tangent there, but again, these dependencies will always be an issue with almost any CMS that's out there, unless you're moving towards this new technology.
A second thing you can do, after minimizing dependencies, if you can't minimize, or if you succeed to a certain extend, is build a team that consists of those people that we just talked about. It's not enough, again, to say, "Oh, my host is going to handle this, and I have this web guy I can call once in a while." You really need a team that's dedicated, and is involved with you on a regular basis. That, again, isn't just ... I'm making quote marks in the air. It's not just the "web guy." It's a sysadmin. It's front and back end developers, and it's somebody who can QA. These are not the same people. I assure you, a QA person is not the same as a sysadmin. Not any day of the week. Isn't true.
Finally, the third thing that you can do is monitor and manage. If you're not monitoring your website 24/7, 365 with someone that's going to actually respond at 2:00 in the morning, then you're doing yourself a massive disservice. You need to be monitoring, and you need to monitor more than just load time and ping. 
There's a lot of services out there you could subscribe to. They'll tell you if your website's up or down. That's great, but by the time you get that, the site's already down, customers are already being affected. You really need to monitor deeper than that. You need software on your server that's telling you what's the memory usage, what's the hard drive space, how's the database performing. There's 30 to 40 different metrics that we monitor on a regular basis, and that's really what you need to be doing as well.
The other thing is conduct regular stress tests, penetration testing, things such as that. These are things that will help you in the long run to avoid unnecessary shock and surprises. Like I said, test that functionality on the front end. I can't really reinforce that fact enough, that you should be doing that on a weekly basis. Filling out forms. Even, sometimes, more than a weekly basis, depending upon how mission critical your app is.
Think about it this way. Maintenance is the insurance policy that your virtualized asset needs to ensure its stable functionality. That's what I tell people when they ask about maintenance services. I say it really is an insurance policy, and it depends on how much of a risk are you willing to bear. You don't need maintenance at all, if you're willing to, say, have your site go down on a Sunday night, and you don't show up to the office till Monday. If you're willing to bear that risk, that's fine. You're willing to bear the risk of people invading the site, and end user data? Now, that's totally up to you. But maintenance, to me, is an insurance policy.
What should it cost? Again, there's no hard and fast rule. We have a maintenance product which is based on two things. One is server uptime, 24/7 support, and the other is based on resources that are in use, such as developers, and things such as that.  I think that you have to think about it in the terms of a hire. It's equivalent to hiring an employee, as it should be. That's how important it should be for you.
All right. One thing you could do, calculate, again, the value to you, like I spoke about before. What's the cost of a breach, or downtime, or some other catastrophic situation? How important is the website to your business and your job? If you're the web manager of an organization, and you don't have a maintenance plan in place, I would worry. 
On that note, I'm going to talk about what should you worry about. What should keep you up at night? If you know your CMS, however, your front end experience is not up to date, if it's software like a WordPress, or a Drupal, or anything that's not up to date, and you haven't acted on it, you should worry. There were major updates to WordPress just a couple months ago, and literally, every week, it seems like, there's a sub update underneath it. I would be worrying if you're not up to date.
The next one is if you don't even know what your server situation is. I know this sounds crazy. Who wouldn't know? I see it all the time. CMOs and marketing managers that call me and they don't even know where the site's hosted, which tells me that they don't know if it's updated, they don't know if it's being watched. If something were to happen, they don't know who to call. If you don't know any of those things, figure it out today. Make that your Monday mission, or make it the mission for the week.
If you haven't prepared 24/7 support. It goes back to the previous things. If you don't know your server situation, who do you call? Who's watching it? If your site goes down at 3:00 in the morning. A lot of people tell me, "I don't need monitoring at 3:00 in the morning, because my customers, they're not really up at 3:00 in the morning." That's great, but when are you going to figure it out? Is it going to be at 10:00 the next day? Are your customers going to be noticing by then? At that point, how long will it take you to fix it?  If you don't have monitoring, I would be concerned.
Finally, like I said over and over on the previous points, if the site goes down, you have nobody to call. That's just the worst. Even if you notice it at an inconvenient time, who do you call on a Friday night? These are things that you should worry about. Oh, actually, I have one final point that's even more important. You should worry if you're responsible for the website, and any of the above points are true.  I'm going to leave this screen up for just a second, for you to think about it.
That is all I have. I went a little bit over time. I apologize. There was a lot to cover. Like I said, we're going to do webinars more often. Our next one is going to be about CMS systems for the chief marketing officer. There was a long series of blog posts I had back in January. We're making it into an e-book. It's going to be available next week. This is really going to be an in depth topic. I might have to break it into two, but we'll see. I do encourage you to read that blog post. Take a look back.
Any other resources that you might want to look at, in terms of education ... that you should look at, rather, check out our blog, videos, or e-books. We're regularly contributing all of those items.
Finally, this is where you can find us in New Jersey. I just noticed that's our old address, so check the website for the new one.
Thanks a lot for joining us. Again, if you have any questions, feel free to submit them in this menu. I didn't have time for a Q&A. I didn't want to hold people hostage for the day. So send it over. I will talk to you guys again next week. Take care.