In the
previous post of this series, we talked about the importance of requirements and gaining a solid understanding of the “why” before embarking on a hybrid cloud journey. As direct experience in other areas of life might have already demonstrated, “because everyone else is doing it” isn’t going to cut it here.
The type of information gathered during the initial phase focused on the business benefits you hope to realize by transitioning to a hybrid cloud architecture. Realizing those benefits, we discussed, depends on making intelligent, well-reasoned decisions about what should live where, from a service and application standpoint, and why.
But what do we need to know to prepare to make those critical decisions? How do we come to an understanding of our existing environment that’s complete enough to base our future architecture on?
The answer, as you might suspect, lies in asking even more questions. Except this time, we’ll be focusing more on the “what,” which is often more straightforward for us technical folk to wrap our nerdy, data-loving heads around.
The Challenge of Discovery
It would be great if we could lay out one prescriptive series of steps that would work flawlessly in all situations, but in reality, environments take many forms. The number and type of applications hosted within these varied environments is even more numerous.
This variety of applications, and potential issues associated with them, keeps things interesting for support personnel who interact with these applications daily. But if you’re responsible for making architectural decisions for an organization, this variety and potential infrequency of interaction can present a challenge.
In the face of this type of challenge, a good approach is to start gathering data and let the information be your guide.
For discussion purposes, we’ll assume existing documentation and systems of record, like monitoring and management systems, are either out of date or don’t contain a fully accurate picture of the environment. We’ll be starting from scratch.
We’ll also assume a full dependency map establishing the relationship between business functions, applications, and underlying systems and infrastructure hasn’t been created. (Side note, how unsafe is this assumption, really? This is the real world, after all…)
So, let’s dive in and start our discovery by following the high-level process below.
Completing the Assessment
Phase I—Gather Business Information
During the first phase, you’ll want to talk with business stakeholders, application owners, and end users to identify which business functions are supported by which applications, along with their level of importance to the business.
Take time to get a feel for the workflow of your users and how the applications in your environment interact. Departments and teams are not islands, after all, and often work output from one serves as an input for the work of another.
These are just a few examples, but the end goal is to get a better view of how things work at the business level and how the people within your organization use technology to perform their job duties.
As you’ll see, defining the function and importance of an application, the impact of downtime, input and output processes, and location of end users will be critical in determining where an application is placed in your future-state hybrid architecture.
Phase II—Gather Technical Information
Within the second phase, we’ll attempt to gather technical detail to fill in the blanks and support the information we learned during our business-level assessment.
Start by gathering an inventory of physical and virtual systems, ensuring essential details like system name, IP address, resource allocations, OS, and running applications are captured. Analyze this information and take notes on which role(s) the system performs, and which application(s) it supports.
If possible, take the opportunity to analyze the communication patterns of your systems, as well. This could involve getting all systems rolled into an existing monitoring solution or deploying a new tool specifically for this purpose.
This will help you see how the tiers of an application interact and from where user communication originates. You’ll also see evidence of the interaction between the teams and applications you discovered during the first phase.
As you piece this information together, you may need to stop, take ten deep breaths, and calmly ask yourself why the previous admin or architect allowed ONE system to be a single point of failure AND performance bottleneck for multiple business-critical applications.
Take comfort in knowing things are in your hands now! A thorough and methodical approach, and an abundance of information, is the way out of this situation.
Now that you have a firm understanding of resource requirements, dependencies, and traffic patterns, you have what you need to consider the impact a potential relocation of the application will have on the operation of the business.
During the later phases of the transition, like migration and ongoing management, the investment of effort here will prove worthwhile.
Phase III—Merging and Mapping
At this point, you’ve gained an understanding of the important applications your business uses, who uses them, and which underlying software and hardware components support them. Now you’re in a much better position to begin making decisions.
However, it can be very helpful to go one step further and merge this business and technical information into some form of unified spreadsheet, or even a series of diagrams. You may need to support your decisions later or otherwise present the current state in a way digestible by businesspeople.
This would be a great way to approach the problem and get buy-in for your approach and architecture. Plus, short of a crowded series of CLI windows open on your desktop, there’s no better way to feel like a “pro” than to spend hours working on a diagram until it’s perfect.
Application Rationalization
Let’s pause for a moment. As you talk with your business stakeholders, run through capturing your technical inventory, and map things out, a few questions might come to mind, like:
- Why are we doing things this way? Wouldn’t a modified process be more efficient?
- Why does this application even exist? Wouldn’t a managed service offering do this better and at a lower cost?
- Are my eyes deceiving me or is that really Windows Server 2003?!
If we’re investing effort in potentially re-platforming our applications, it may be worthwhile to take a step back and
rationalize our use of applications first, as these things really go hand-in-hand.
After all, why create an elegant, new technical architecture to support an application that should be replaced anyway?
Wrap-Up
Whew. We covered a lot of ground there.
Suffice it to say, a critical stepping stone on the way to creating our future-state architecture is a firm grasp of what exists within our current environment, and the business function these various applications perform.
It can also be useful to stop and ask why things are the way they are, and whether those ways of doing things should be carried forward, before proceeding.
After all, the term “cloud repatriation” exists for a reason. Enough people made the decision to transition to the cloud, then turned around and retreated from that decision, for this to be a thing. Yeah…we’re going to try to avoid that.
In the next post, we’ll discuss how we go about selecting the right platform for a given application within our hybrid architecture.
