There and back again – a server’s story

The best stories start out and end in the same location, where many events and years have passed, lessons are learnt, yet the end goal is to return to how things were at the start. History and stories alike, everything tends to be circles, or maybe more accurately, spirals, where we end up close to where we started despite a long round trip. Bilbo Baggins, Frodo, everyone is eager to leave, yet yearn nothing more than to return once they have begun their adventures. And while this may be slight hyperbole, the story of the cloud is a good example of how we have gone almost full circle in the world of IT infrastructure. Shortly after finishing university, I worked for a company where the old server rooms were being taken apart and turned into additional meeting rooms, the old ventilation systems likely able to still give even the fires of Mordor a run for their money.

These days, the adventuring party has passed Mount Doom and is on their way back home. Many companies have slowly been moving parts of their cloud-based systems back in-house. Larger companies that once had entire warehouses for datacenters embraced the Cloud, allowing them to toss out all that fiddly hardware and support staff away and embrace a simple support contract. But as things matured, both practicality, pricing and compliance started changing the value propositions that once made the cloud look so rosy.

Every story has it’s ancient lore

So, what exactly happened? And why are companies going full circle (or, maybe more aptly, spiraling back to not exactly the old position, but closely adjacent?

Well, as a wise man once said, “The cloud is just another person’s computer”. Hyperbole, sure, and an oversimplification to say the least. But in the end, the cloud is basically the server-worlds’ version of a mercenary company, where enough money gets you the power you require. The day-to-day doldrum of managing hardware, networks, backups, support personnel etc., all abstracted away by a single cheque. No more rent, no worrying about loud ventilation or a sysadmin and server-guru that no-one actually understands what is doing, no upgrading failed drives, etc.

But as the cloud has matured, so has the business model. Like Saurons growing armies in Mordor, darkness engulfs the horizon as dynamic scaling has gotten disproportionally more expensive, data transfer costs have skyrocketed, hell, even storage is not the cheap option it once was. On top of that, the authorities, especially in the EU, have been keeping an eye on digital rights and security, and with things like GDPR and various local laws requiring strict access-limitations to certain types of data, the Cloud has become as much a liability as an asset. With, for example, the United States having laws about accessibility to data within all US based companies, the Cloud suddenly becomes illegal to use for EU-based systems with personal information protected under the GDPR and similar privacy laws. In short, a server is not just a server anymore. Data-residency, -sovereignty and -regionality are all added complexities that make the cloud anything but a simple option for many types of use.

So, whether the pricing for specific use cases is going up, or the legality of the data-storage and –throughput is what causes worries, many companies are looking back at that meeting room and wondering if maybe, just maybe, they should kick out the lounge chairs and IKEA pictures on the wall and repurpose them back into somewhere a server rack or two could live comfortably.

Planning your adventure

Rebuilding a server room is not what it used to be either. As we all got comfortable using the cloud, many functionalities of the cloud have become core to the way we program many things these days. As a result, a hybrid approach is often a better option, taking back control of the parts of our systems that cause problems, while leveraging the flexibility and scalability of the cloud for the rest. As such, when your company starts asking for a small party to buff up and remove the couches from a room in the back, make sure you are cognizant of the true costs it involves and that you have a proper plan to ensure success.

• Do you have personnel that can support and maintain your local hardware?
• Do you have a proper SLA with your maintenance to ensure the necessary uptime?
• Can you scale like the cloud could when Black Friday hits your web-shop or tax season hits government filing applications?
• Do you have admin staff capable of keeping all parts of the stack updated to stay safe from exploits and the Eye of Sauron?

These questions and many more are necessary to ask before attempting to take back control. But, if you still feel comfortable taking on the task and see the business case on the move, it’s time to embark on a quest to escort (some of) your servers back home!

Detailed plans – better than forgetting the GIANT EAGLES!

As with all quests, preparation is key. Where the dwarves in the Silmarillion focused mainly on the journey to the Lonely Mountain and evicting Smaug, you too must focus on the full journey while keeping an eye on the final destination. Creating a modern infrastructure for a complex business is often easier said than done and the pitfalls will take down many an adventurer. To plan things out ahead of time is a no-brainer to many, but should be taken seriously, as many try, but only few truly succeed (at least within budget).

As such, the key phases should be:

• Analysis of business needs and requirements
• Analysis of laws and regulations concerning the affected programs and systems, existing and planned
• Identifying known unknowns
• Deciding on platform based on the acquired analyses
• Solid plan for hiring the required resources for build, migration and maintenance

• Beginning development with air in the budget for unknown unknowns adding to the pile of known unknowns
• Migration
• Day-to-day oversight and maintenance
• Potential expansions to the core platform

These phases cover quite a few things, which can be roughly categorized further and gone into in depth in later articles:

• Organization & Stakeholders
• Architecture & Development
• Hardware acquisition & maintenance

Each of these will, in turn, cover a wide array of subcases and details. For example, organizational needs require an understanding of the stakeholders and thus, the processes which the organization currently utilizes. Then the next question is whether these processes are the correct ones to be supported, or should a new system include changes to the processes as well, allowing for optimization of various workflows? All this is itself constrained by budgets, compliance, laws and available personnel. The same goes for Architecture, which depends on choices made regarding hosting, containerization, open- or closed-source development, etc. This decides what constraints apply to the hardware decisions.

As such, care must be taken to ensure each phase is properly thought out, as the decisions made in one step directly impact the next. At the same time, laws and organizations change dynamically, so moving from one phase to another in a waterfall style is not conductive to a proper development lifecycle. Instead, each step has pre-requisites to beginning, but once it starts, the previous step can itself continue in order to provide additional information or constraints, as well as dynamically adhere to new legislation or requirements.