In Part 1 I talked about the steps I normally take to understand why the business is trying to move to the cloud, what they expect to accomplish and how to measure if this is correct for your business. In part 2, I will explain the next steps that should be completed prior to getting started.
Planning your cloud deployment consists of technical work balanced with business needs. In this part, we focus on Microsoft Azure’s offerings, but most of the concepts will be similar in other cloud offerings. These are the keys area I focus on at this stage:
IAAS or PAAS
One of the fundamental questions for any deployment is whether or not it will be Infrastructure as a Service (IAAS) or Platform as a Service (PAAS). My recommendation is almost always the same, PAAS is the better choice for multiple reasons. PAAS costs less, scales better, is easier to manage, and easier to develop for.
With that strong of a recommendation, when would I recommend IAAS? The most obvious reason is that there is some piece of software required for your system that will not run in any of the PAAS services. In this circumstance, you still have the option of doing the rest of the system as PAAS, but this is not as obvious of a choice. The other reason to use IAAS is that you have a system already running in a set of VM’s and want to do a lift and shift without any refactoring. Even in this circumstance, you should carefully evaluate the cost. In my experience lift and shift lead to very high costs and low performance.
Azure Kubernetes Service (AKS) is a third option that has become very compelling with recent releases. This is basically Kubernetes for Azure, which allows you to deploy containers with an orchestration engine. This allows for portability to other platforms (such as a developers machine) while still maintaining all of the advantages of PAAS. For my clients that are doing new development, this is almost always my current recommendation. Look for my next blog post with a deep dive into AKS!
Hybrid or Cloud Only?
The obvious answer is Cloud Only, we are trying to move to the cloud after all! However, this is not realistic in most circumstances. The reality for most businesses is that they have a deployment in a local or co-located data center. This data center usually has business-critical applications running on the servers housed there. A deployment to the cloud often involves a subset of these applications or new application that has dependencies on the servers in that infrastructure. I always assume that I will be in a hybrid scenario for the foreseeable future and plan accordingly. Even if you don’t believe what you are currently developing will have any dependencies on the on-premise data center, assume that someday something will. It is much easier to plan a Hybrid scenario and never connect up the on-premise data center to the cloud then it is to refactor your architecture later.
What are my Security and SLA requirements?
Two major non-functional requirements that often are an afterthought are Security and Service Level Agreement. Often clients have said to me, “Of course, I want security, make it as secure as possible!“. What they don’t realize is that you pay for the level of security that you want. Sometimes that payment is in actual cost, but often it results in usability compromises for end users or more development hurdles for your team. Developing an understanding of what security makes sense for your application will help your team architect and design a system that balances security with other competing interests.
Service Level Agreement (SLA) is very similar to security, most business stakeholders will want to maximize SLA. The cost increase to get higher levels of SLA is usually not proportional but exponential. The result is that your costs can increase dramatically for a negligible improvement in SLA. This makes it critical to understand the SLA that is required and target that level.
What architecture should I use?
The software architecture that you target in the cloud will be similar to the software architecture that you would select for on-premise deployment. This requires the same upfront planning and thoughtfulness and should be done as upfront planning. A great reference for architectures that fit well in Azure has been created by the Microsoft Patterns and Practices team called the Azure Architecture Center.
How should I store data?
There are many options for data storage within Azure and each one trades off cost, speed, and ease of search. This is an important part of your architecture and is something that can not easily be changed after development has begun. Some of my favorite options to look at include:
- Cosmos DB for Document and Graph Databases
- Azure SQL for relational databases
- Azure Cache for Redis for a data store that prioritize performance
- Table Storage for an inexpensive table based key-value store
- Blob Storage for when the lowest cost is critical
Most systems of significant complexity will use multiple data storage options. My recommendation is to not get laser-focused on just one option, but pick what is best for the problem you are trying to solve. The cloud makes it easy to use multiple data storage solutions simultaneously!
How do I optimize for cost?
The best way I have found to optimize cost is to complete your architecture and then map out the exact costs in a spreadsheet. Once the costs are detailed, the team can look at areas that may be extremely expensive and refactor that part of the design or even map out the costs of an alternate design. This time investment has lead to architectural adjustments at some clients that have reduced monthly costs by 50% or greater!
Need some help getting to Azure? Reach out to SafeNet Consulting and we will help make your Cloud journey successful!