Have you ever received an email that claims if you switch to a new service, platform, software, or vendor, it will save you money over your current costs? If an email like this ACTUALLY causes you to pause and consider the call to action it is because it struck a nerve. The first step is to NOT reply but to roll up your sleeves and do some homework. Specifically, evaluate your current environment and individual situation so you are prepared and armed with information. This article will help you with the questions to ask yourself and process to follow through the systematic, intentional approach we take at Baufest to conduct such efforts.
For this exercise, we’ll take the position of comparing a hypothetical legacy on-premise computing environment to the promise of a fully cloud architecture. Your specific environment, set-up and business context is uniquely yours, but the process/approach being outlined is basically the same whether you are looking at an individual application, integrations, portions of or your whole technology strategy.
First, here are some questions to ask yourself and we recommend writing down the answers for later reference:
- Do you have an accurate enough snapshot of the current operating costs on-premise to make it comparable to a new environment in the cloud?
- Is this snapshot in alignment with the broader business objectives, goals, strategies and tactics?
- Do you have this snapshot of usage in your current environment during the peak and valley times of your business cycle?
- Do you want/need an identical environment to be built or will you be modernizing or reengineering along the way that will alter the calculus of your ‘comparables’?
- Should you consider the personnel/staffing resources involved in addition to hardware and software resources?
- Are there capabilities missing or extraneous when comparing the environments?
These questions can feel overwhelming when evaluating your computing needs but getting to the right numbers can be worth the journey into a cloud environment. Below are the steps (and the applicability of the hypothetical case in parenthesis for reference) to approach the questions:
Step 1 – GATHER METRICS (Hardware, Software and Network Level)
Step 2 – GATHER METRICS (System Architecture level)
Step 3 – GATHER METRICS (Cost)
Metrics and the context for past decisions are crucial to this initiative’s success; it consumes all three phases! What metrics and context, you ask? When considering a migration to the cloud, for example, you need to understand the resources currently used at the hardware, software and network level. Chances are good the legacy hardware on-prem you are looking to replace was oversized for your needs when purchased – what were those needs and how did you do on getting your sizing right? What affected getting it right – or wrong? For example: software has evolved quickly, did your hardware evolve with it? Are you discovering your hardware no longer has enough RAM, storage or perhaps your disk speed is causing database performance issues during reads and writes? If you have never monitored these resources, you might be surprised by some of the resource constraints you find and the source of the bottleneck. Resource constraints might not be apparent in the current environment, but if you plan to “right-size” your cloud foundation, you will want to ensure your cloud build accounts for these findings. True, it is easier to add resources once in the cloud, but the price tag of adding unplanned resources might cause sticker shock.
PRO TIP: While there is no set time for how long you should run these monitors, look to cover your peak and valley usage periods to ensure you have an accurate view of resource consumption. There are many monitors out there to choose from, which can help you monitor your environment: SysGauge, PRTG, SolarWinds, Site24x7, or APPOPTICS, to name a few. There is no ‘best solution’ as every organization is unique in utilizing its resources; it is never a one-size-fits-all scenario.
Gathering metrics for individual servers and applications is essential, but you also need to consider the entire system architecture and how the information flow is affected. Where will your integration engine sit? How will your integrations connect into the new cloud space? Do your systems overlap? Do patterns emerge? For example: when one application has pegged a server’s memory, do you see another server’s network connection pegged? These are clues for how your entire architecture can be streamlined for performance when building in a cloud environment.
In this step, you should also take into consideration your growth projections. Are you adding new systems to the mix that increase architecture needs and change how you use your existing resources? It can be tricky to gauge new application resource needs, and integrations can have a more considerable impact on older applications. Be agile in this situation – a cloud environment might alleviate some unknown resource risk.
What are the cost metrics? Now that you have a holistic picture of your current environment you can revisit that email that caught your attention and be informed when considering what you NEED. The evolution of virtual machines has allowed the right sizing of computing power for each application and use. Layer that flexibility into the cloud and you could only pay for what you use NOW with the option to flex into what you NEED later. Gone are the days of buying fat servers and hoping they fit current and future needs.
How do you begin to set up this monitoring and then evaluate the findings? Do you know your opportunity costs for migrating to the cloud? Is it more than the cost of running your business on-premise today? These are the types of tricky questions we at Baufest want to help you answer. Don’t be shy; we love a good challenge.