Define the desired outcome moving to the cloud
As you begin to evaluate whether moving to the cloud is a viable option, it’s important to define success. After all the dust has settled, what does the future state of your application look like? There are many value propositions that moving to the cloud offers, here are a few:
- Higher reliability through improved uptime.
- Lower costs with appropriately sized infrastructure.
- Easier scaling and load balancing.
- Less developer toil with a better deployment strategy.
I could go on and on with these. But the point is to generate several KPIs (Key Performance Indicators) that will indicate if you are hitting your goal.
With these KPIs in place, they effectively become your “why” so write them down. These will be your “true North” as you progress further in the process. As technical decisions arise, you will be able to look back on your desired outcome and choose the best course of action.
Evaluate the current state of your application
When looking into the current state of your application, it’s important not to get too deep in the technical details. Yes, those details will matter, but this is a high level evaluation of where you are.
Infrastructure
The infrastructure of your application describes the components, physical and digital, that make up your application. These are things like application servers, web servers, messaging servers, data storage, databases, and networking, to name a few. Be sure to document the physical assets as well as the software and services that are running on them.
Architecture
The architecture of your application describes the design of how the components that make up your application work together. Some terms that describe application architecture are 3-tier, microservices, monolithic, and event driven. How do the components of your infrastructure relate to one another? Write down these relationships. Don’t worry if you can’t pin down exactly one type of architecture here, it is possible for an application to span multiple architectures. The point here is to have a clear map of all the components that comprise your application.
A very rudimentary example of an infrastructure and architecture diagram for a generic application.
One more consideration to note is data sensitivity. Are you dealing with HIPAA or PII? Often there are regulations on how you secure sensitive data; even if there are not you will want to make sure your (or your customer’s) data is secure. Having this documented will help you as you move forward and make decisions.
Project cloud services
Once you have the current state of your application mapped out, you can begin to look at cloud providers and services. Up until this point, things have been fairly straightforward but now some real knowledge is required. You are free to learn about the different cloud providers and what they offer on your own, or you can hire a consultant to help. Now, planning your new cloud implementation.
At this point you should be crystal clear on your goals for the cloud and where your application is, currently. This information will be your guide to your design decisions. You may be familiar with the, commonly referred to as the, six R’s of cloud migration. They describe common methods for migrating to the cloud. For the purposes of this article I will be speaking to three of the six.
- Re-host – Also known as “lift and shift,” is when you closely mimic your existing infrastructure and architecture with resources in the cloud. In my example above, I would need one web server, four app servers, two database servers, one messaging server, and a partridge in a pear tree. I recreated my application, with its same topology, just in the cloud.
- Re-platform – When you begin to make changes to your infrastructure and architecture to take advantage of services in the cloud. Instead of mimicking your existing environment, you off-load certain aspects. Using our running example, you might replace the database servers with a database service while simply re-hosting the rest of the application.
- Re-engineer – Refactoring the core of your application and optimizing it to run on the cloud. Depending on the current state of your application, re-engineering your application to run on the cloud can be the most expensive option listed. The benefits however provide the most flexibility and agility in the future. Going back to our example, in addition to replacing the databases with a service, you might also replace the application servers with containers, and serve the static web frontend with a storage/CDN (Content Delivery Network) solution.
As you can see, there are many factors that affect how you migrate to the cloud. The decision you make here can have a serious financial impact on your future cloud implementation. There are tools that cloud providers make available to aid you in the decision. These tools, like the AWS pricing calculator and Azure’s pricing calculator, allow you to estimate your monthly cost in the cloud. Take your time and be as detailed as you can in this step. In doing so, you will be better equipped with accurate data with which to make the best decision for your organization.
Roadmap path to cloud
This and the last step go hand-in-hand. As you project the costs of your cloud infrastructure take the time to write out diagrams for a few of the architectures that you’re considering. Having these “maps” will allow you to look at each option holistically and choose the best path forward.
In the above example, I’ve re-engineered my generic 3-tier application into the cloud. Here is a summary of what I changed.
- I have a single page application (SPA) hosted on a storage service and global access to it is provided by the CDN.
- I moved my application to containers within Kubernetes andI got rid of the pub/sub feature addition since I was already rewriting my code.
- I moved my databases to a database service.
This is an oversimplified example, but it does show the transition from our traditional infrastructure and architecture to a cloud native application.
Complete any application refactoring
At this point you should have a clear path forward with your application. You know what your end design will be and now you need to get there. I won’t say too much here because this step is highly specific to your situation and is outside the scope of this article, but there are a few points to consider.
- If you do not have your code in source control (like GitHub) now is a great time to make that happen.
- You should be thinking about how you are going to test, package, and deliver your code to the cloud. If you do not already have a CI/CD pipeline in place (or planned) take this time to build one. It will help you automate your deployments and reduce labor and toil deploying as you go forward.
- Look into application specific monitoring. As you begin to complete the process of migrating to the cloud, collecting and analyzing your performance data will give you great insight into what improvements to make in the future.
Execute the switch
Now that you have everything built out and ready it’s time to change over to the new system. Again there are a lot of details that are specific to your situation to provide a lot of detail in an article but, as in the previous step, here are some things to think about.
- You might consider employing a load balancer and shifting all of your traffic to it early in the process of migrating to the cloud. After you have your cloud deployment up and running you can begin to shift traffic to it gradually. This can greatly lower the risk of widespread outages and allow you to find bugs with minimal impact to your users.
Monitor and adapt
One major benefit to the cloud that comes standard with most providers is high observability. Many services that you will use have logging and monitoring built in, so take advantage of that. Spend time looking at the metrics and test against the KPIs that you established in the beginning. Take the time to build out dashboards from your application and cloud service performance data. These dashboards allow you to see, at a high level, how things are performing.
Moving into the future, in addition to observability, the cloud also affords you increased agility. With the performance data, you will be able to generate features and enhancements to better serve your users. You will be able to deploy these changes with less developer toil and with greater speed.
In closing, it is no small undertaking to migrate your application to the cloud; there is significant knowledge and engineering required. The skies ahead are stormy indeed but, with proper planning, you can forge ahead with confidence to your destination. Take the time to understand where you are currently and you will be able to chart a smooth path to your destination.
If you would like to find out how I can help your organization on its cloud journey, send me an email on the contact page.
