Intro
Last blogpost we started with the question “should we move towards VMC on AWS, or not”. We made a quick recap of what VMC on AWS can offer, and some of the considerations you should have regarding the design or when you are moving towards the cloud. We didn’t go fully in-depth into some of the features, use cases or challenges, but that will be covered into different posts. However, with the big VMware Portfolio and the services of AWS, it is safe to say that their cloud solution has some unique selling points to offer that really can help companies with their business & IT strategy. The ability to combine an on-premise platform with a cloud platform, which creates a so called “Hybrid Platform” is something unique, which can help Business & IT to leverage the power of both platforms. However, this doesn’t answer the question “should we move to VMC on AWS” or any cloud service in general? To answer that question, we need to review the application landscape. So, let’s talk about that. 
Reviewing the Application Landscape
Reviewing the Application Landscape, this is the first step organizations should have executed before they even begin to look towards a cloud solution. Still, this step is often forgotten and overlooked. We tend to move straight towards infrastructure, SLA’s & availability requirements & considerations, and focus on how the next solutions should solve this for us. At the same time, we often don’t take the time to review of what we have in place and how our Application Landscape looks like. There are quite some organizations that don’t seem to have an overview or understanding of how their own applications work. This can be simple things like: which ports are being used, which service, server or applications talks to what or which, what are the application or service dependencies, where is my data or which database is being used, is the application latency or time sensitive, and what is the network flow in general? These are just some basic questions, but quite some organizations seem to have problems to answer this. Some organizations don’t even know how many or which applications they are actually running.
Now do note, I’m not saying this to shame or to make fun of, it is unfortunately a trend that seems to happen in a lots of organizations (both big and small) and is actually a quite common and normal challenge in IT. These situations are often explained by historical growth and changes within the organization while IT is just trying to keep up with the demand. This is often also the way how shadow IT starts of. However, with that being said, the state and (documented) knowledge of the current Application Landscape, is therefor the most important factor for a migration project or platform change to be successful. You cannot expect that a platform change will be simple and quick and solve your problems automatically if you don’t have the right information on hand. Let alone if you don’t really know what it is that you need for your applications and business. We can have all the technical solutions that we want, but it still needs input. And when that input is unclear or vague, we will always spend a lot of time on gathering that information or ending with “unexpected” results.
One of those common “unexpected” results after an AWS project, is the amount of data that is send out the platform. As you may know, AWS charges you mostly on the data that is going out, not the data that is coming in. Having a bad misconception of how your application landscape is operating, or doing things like making online backups and storing it offline, can give you unpleasant high bill at the end of the month.
There are organizations that exist for more then 20 years, and still don’t have that kind of basic information on hand. Yet, at the same time can have an unrealistic expectation of how fast they should (and can) move towards the cloud. If an organization couldn’t gather that type of information within 20 years, you should ask yourself of how much time you will spend on the information gathering phase. In my own experience the information gathering is the most intensive part of a project. Which is actually the case for most (IT) projects. When talking to other consultants, colleagues and customers, most of them agree that 70% of the project time is planning and information gathering, while only 30% of the time is spend on the execution part. I guess this holds even more truth towards cloud (migration) projects. Especially when the organization want to go cloud all the way.
Now I don’t want to bring this up as a negative thing. Since these kinds of projects are actually a beautiful way to help organizations to understand each other even better, and finally, get IT & Business to become better aligned with each other. It is however, something that needs to be said since this is one of the biggest challenges that comes back every time. We can look towards technical solutions and tools to solve our problems, we still need to talk to understand each other needs. There are definitely tools that can help you with this phase of information gathering, for example Network Insight, but we still need to communicate in order to understand the business, security, user and applications needs. Which is not only important for the implementer but also for the internal organizations and different teams as well.
Once we have done that, we are able to understand and help the organization even better and can set the right expectations. We than move towards the next phase, which I like to call “Rethink your Application Landscape”. Which definitely help with our starting question “Should we move or not move towards VMC on AWS”. Hope to see you in the next post as well.
Samir
Samir is the author of vSAM.Pro & a Life enthusiast who works as a consultant in the field of IT. With a great passion for Tech & Personal Development, he loves to help people with their problems, but also inspire them with a positive outlook on life.
Besides that, he is also a big Sport & Music junky that loves to spend a big chunk of his time on producing music or physically stretching himself.
