Going from servers to services is a lot like playing a game of Jenga. You have to pull out all the various blocks (apps) without knocking over the tower (your business). You can go for the slow methodical method, or the “turn if off and see who complains” method. We have found a balance between these approaches that give maximum speed to implementation without knocking the tower over. Stringfellow has been incorporating this into all our Technology Roadmaps since 2010, and today we rarely sell a Client a “new metal box” called a server if we can help it!
Last year we talked about how to move to an app-based delivery model, which is very similar to how we approach the first step in the Servers to Services transformation.
*Please note: When we refer to a server we really mean a server instance, not a physical server or virtual host. If you are still running PHYSICAL dedicated servers that can only mean one thing, job security for your internal IT team. If you aren’t ready for this series…..start HERE.
What does the server actually do?
When asked what a server does the response is usually something like, “it hosts our file shares and runs the accounting package.” The reality is it also handles all the networking and Active Directory (security) services, runs the key card system for the door, and some random program the sales team uses to keep track of quotas! Just like Jenga you pull out what you think is one block and several others come falling down.
Figuring out what the server *really* does is a combination of running reporting tools, watching network traffic, and good ‘ol fashion experience. The reporting will show all the applications installed on the server, but not necessarily what they do. This is where experience comes in, knowing the app named KeyMaster2000 is what runs the entire office door badge system and without the app running no one can get in the building, is a lesson you only learn once!
It’s not just applications you need to look for!
Servers typically run as many network-based services as they do applications. Networking functions such as DNS, DHCP, and VPN are still provided by on-premise servers. Printer and scan-to-email services are also overlooked. Reviewing the running services and watching network traffic is an important, and often overlooked, part of the discovery process.
One of the biggest roadblocks to moving completely from services is local Microsoft Active Directory services. We have been talking about this since 2015 and have developed a path to transition these services to the Microsoft Azure Active Directory platform easily. It is critical that this is part of your planning process, as it does no good to STILL need a local server to handle your security, especially in the remote office environment.
Make a list and check it twice
Now it is time to sit down with end users to review the listing of both applications and services. First, review the applications actual usage by end users. The amount of applications that can simply be discarded, typically a sign of less than proactive IT management, is always surprising. Next, legacy applications that are rarely accessed, but needed for compliance reasons, should be marked as such.
Finally, active applications (and services) should be categorized by who is using them. Is it the entire company, a department, a small team, or single user? This will be helpful in the next step in the process which is consolidation and migration of your servers.