Why It's Time to Ditch Servers for the Serverless Cloud

Perfection is the enemy of progress...

Lets talk server elimination. Why do we need to eliminate servers, and how do we do it? What does that even mean? Before we get into that, lets address the most common objections: "My clients have to have servers! They require Quickbooks or, my clients want their files in house because they don't trust the cloud or, they have huge files we need to have on local network storage or, their primary [application] only work on Server 2008 (seriously) or, [fill in the blank]". Yes, it's true, sometimes we can't eliminate all servers and I'm not naive to that. The problem is, this conversation always gets started with how it won't work instead of how it can, so we continue on a path of stagnation, getting ourselves further behind the obvious future...which surprise, is now the present. If you've been against going full cloud, or at least hesitant, by the end of this article I hope to finally tip the scales and get you started on eliminating servers in your own environments.

Servers directly represent complexity

The second a server exists we create complexity that we're responsible to build, maintain, and support...and it's not just a few things, it's most of what you do. When I say servers I'm not just talking about your physical servers or your VMs on your on-prem hosts– I even mean VMs in the cloud whether that's Azure or AWS or whatever it may be. This is literally server elimination. In this article, we're primarily going to talk about moving to just 365, but there are many more examples of how to replace a server with SaaS or PaaS. To get my head in the right space I like to walk it backwards from "if I had no servers and everything was in 365, what parts of the on-prem infrastructure, maintenance or even cloud VMs could go?". For on-prem, here is a list to start:

Hosts / Hypervisors wouldn't need to exist
SANs don't need to exist
NASs don't need to exist
Core switches can go away
VPNs can be turned off
The need for complex VLANs drastically reduces
The need for onsite hands mostly disappears
Network performance and troubleshooting basically disappears
Backups you have to manage and maintain go away
Monitoring server services and uptime goes away
Vulnerability detection and management goes away for the host, the VMs, the core switches, the SANs, the NASs...
Restores from backup on OS or application errors or corruption goes away
OS troubleshooting goes away
Third party application troubleshooting goes away

There's plenty more and it all compounds on support desk and literally your whole company. We're so used to the massive list of things we have to support and maintain that we don't stop to think "what if we just didn't?". At the very least, if you're not doing vulnerability detection and management right now then I can promise you that the second you start it will alone be justification to move toward this. Those firmware / OS / third party constant updates slowly eat away at your soul and you start praying for a miracle to make it go away. Well, look no further!

Okay so what about Azure or AWS or other cloud providers where I can put a VM? If there's no "server" to maintain and just a VM with the infrastructure managed in the cloud, isn't that pretty much the same thing? No. Not at all. I constantly see people forgetting that just because you put the VM in Azure or any other cloud platform instead of your datacenter doesn't mean that it magically took away your concept of an edge to manage. What I mean is, you go look at someone's datacenter and they're running the latest Fortigate, ASA, Sonicwall, or whatever, fully licensed with IDS/IPS and tuned to be as tight as possible. Then when you build a VM in the cloud you use their default built in firewall with none of those safeguards and toss it on the internet. Why? Putting the VM in the cloud only abstracts the hardware and related updates for it (firmware), not the software, so we still have an edge to protect in the same way, and of course, don't forget we still just stood up a guest OS in the cloud that we're responsible for as well...so we're back to:

Network performance and troubleshooting
Monitoring server services and uptime
Vulnerability detection and management
Restores from backup on OS or application errors or corruption
OS troubleshooting
Third party application troubleshooting
more...

The clients get these benefits too

Remember that a lot of the considerations above can and often will result in more expense for the client. Eventually major upgrades are required at the OS level or the LoB (Line of Business) applications, maybe new physical servers, replacement drives, or more RAM, they need better HA in every way which gets you started on clusters, geo redundancy, live replicated DR sites, and more. When a vendor just has a SaaS offering instead of you being required to host it, how much cheaper and easier is it to satisfy those HA needs? The point is that all infrastructure will create more complexity and eat more time so ultimately, we can save our clients a lot of money too. It's not just for us!

Don't take my word for it, go measure

The good thing about the MSP space is that if you're doing it right at all, you shouldn't need to just trust me here...go look at your own ticket data. Run some reports. What are they for? I can almost promise you that ~70%+ of all incidents you can draw a line back to the presence of servers in some way and if all servers were gone, then the surrounding infrastructure is gone, and the problem wouldn't exist. Go back to that list up there...THAT'S A LOT OF THINGS that go away.

If you can't measure this, you just found a new initiative to tackle– properly classify the types of issues your team solves in a consistent / repeatable way.

Payroll is the greatest expense

I know I'm beating this into the ground but just take a step back and think about what we just went through, and start going through the amount of labor on your team that literally disappears if you can make this happen. It's worth it. It's REALLY worth it.

Okay fine, what does implementation look like and who is a good fit?

We want to start with the basics. Go through each client and identify all that only really have a file server of some sort, and AD. You'll be surprised how many of your clients fit into this simple bucket. Remember to not pass them by when you notice they have site-to-site VPN, client VPN, a SAN etc...focus on the outcome: what are all of these things providing? If the answer is the infrastructure for file servers and AD, that's what we're looking for. Write them all down, then we go sell them projects to move them to Entra + 365 + Sharepoint + Intune, then toss out all of that infrastructure and watch the beautiful labor savings.

But my team doesn't know how to implement and/or support Entra + Intune + Sharepoint!

I wish there was an easier answer here but the truth is, you just need to make the commitment to figure this out. The future is here, and if these are your thoughts when you read all of this then you had a problem to solve before you read this. Get them trained. Get yourself trained. Reimburse all of your employees for their own personal Business Premium license and have them stand up their own tenants at home and join a test VM to AAD + Intune and mess around with policies and troubleshooting. Join all of your internal machines to AAD + Intune so they have to work on them every day, and troubleshoot in the portal if something doesn't work. Just make the decision that you WILL be experts of this, stop making excuses why it can't work, and get it done. There's much better margins and improved client experience on the other side of a few difficult decisions.

Sometimes the path there isn't what you expect

The last point I want to make here is that once we've made this decision that it needs to bleed into more than just file servers and AD to really change our entire business. I can't cover every single concept in a single article, but in short we need to tackle everything through this lens. If a client uses a LoB application that doesn't have a SaaS solution (so the vendor fully hosts it) but all of the competitors to that software do...then we need to have done the research to know that the competition is SaaS and this vendor has grown stagnant and it's time to evaluate other options, and bring that to the client. Remember that our clients don't know this stuff. They are asking for what they've seen, maybe what a peer has used, or what they saw on an ad somewhere. If we're echo chambers just figuring out how to implement what they say they want, we're not providing technical leadership at all. Challenge what they want. Challenge what they use. Get creative. Take this to every conversation and find new ways you can change the way you and your clients work.

PostgreSQL as a service

I just want to give an example of what this may look like in real life outside of just 365. I recently had a need for a reporting server. That is– I have data from multiple different applications that don't have any pre-built integrations to work together or any built in way to aggregate data in any kind of way, but they all have data available via API. All in all, I had 5 platforms I needed to aggregate data between. I brought in a developer to help with the API scraping work, and we fired up a Postges server as a service and connected it into Grafana. This Postgres database is provided by a PaaS (Platform as a Service) provider, comes with backups built in, HA, geo redundancy if I need it, auto resource scaling depending on the tier I choose, and since it's PaaS remember I'm not responsible for updates, firmware, network, edge, or anything else. I just buy it, connect it to Grafana, and I'm done. They let me restrict what can access the DB by IP, and even provide an SSL connection option to ensure no one else can ever open the data even if somehow they spoofed my IP on the other end. None of this data is critically sensitive, but still, it's nice this all exists. My platforms have data dumped to this database multiple times a day, and Grafana queries the data at frequencies as low as every 1hr (could go lower but not required for this instance). Guess how much this entire PostgreSQL instance costs monthly? An average of $1.50/mo over the last year. The highest bill has been $1.68. If my head wasn't in this "server elimination" space, I could have easily got this job done in another way that may have at first felt more comfortable– stand up a server, install Postgres, etc, but I didn't because my mind has been made up that firing up a server signs me up for all of the work around it we've talked about above and I don't want it, and I'd argue that you don't either.

Wrap up

This can be a lot of work, and it really is a change in mindset to how you approach technology. If you start to view every server as the literal tip of the iceberg of complexity and introducing even one manifests liability, complexity, and labor, you really do start to find better ways. We have to be strong leaders to drive changes, both from our internal MSP leadership and our employees who provide technological leadership to our clients. We have to truly understand and believe in the importance of these changes, and recognize how they will improve both our clients' lives and our own. Remember– if we're spending less time and effort supporting our clients, they're experiencing less downtime and less hassle in technology. It's a win-win. Go get it!