Cloud is not a new technology in market. Enterprise are using it for in house applications on private IT datacenters since beginning of 21st century. Driven by virtualization, Carrier grade hardwares with top of industry specs are providing shared resources to run multiple workloads on virtual machines.

While, monolith applications slowly proven non-viable with introduction of Service Oriented Architecture, I will keep that discussion for some other day. For this blog, I will keep my agenda to discuss various strategies one should keep in mind while designing system based on cloud architecture. Bear in mind though, by cloud I basically means any cloud, be public, hybrid or multi vendor.

1. Selection of Region/Location/Zones

In order to production grade system on cloud, selection of Location or Regions as termed in public cloud is vital. You may decide location for private vitualized cloud or region in public cloud based on various factors, few of them can be,

• Proximity to end users & clients to minimize latency and reduce network backbone cost
• Cost variable changing from region to region
• Compliance of policies sketched by local government, especially for secured data

2. Multi Tenancy

Now, this may totally depend on type of applications you plan to deploy on your cloud later, project based seggregation is one of key aspect one should conside in design phase itself. You don’t want to lose new customers in later stage if you never considered multi-tenanacy in beginning of your digital transformation journey.

3. Compute Options

Few years back, this point might have only covered what sort of capability your application expecting from underlying compute resources. You need high spec processors for compute intensive applications or larger RAM for database or analytics.

Now though, scope is more diverse than what it used to be. We have to design compute requirements based on three broad categories,

• Compute Resources for Legacy monolith applications or Cloud Native VNFs
• Kubernetes Cluster for Container based workloads on Service oriented architecture
• Serverless services for ready to run codes and services on the go

Hence, system design for compute options cover much wider breadth than ever. So, like said before, its better to decide before and design now than tuning system later.

4. Migration Strategy

Migration in itself is a big topic and sequeezing it in one single pointer is not enough. Yet, few broad migration strategies while designing you infra can help us give essence of what need to keep in mind.

• Lift/Shift or in layman terms, migration of your existing application design as it is on Cloud platform
• Re-Architect, basically, rethink your application design and mould it into more advanced Cloud Native or Containerized way of deployment
• Re-Purchase, or simply move ahead with latest serverless services provided by your cloud platform, like instead of mmigrating your database on redeployed version, you just purchase Database as a Service from Cloud providers

5. Scalability

Probably very first benefit of using any type of cloud is scalability. We all know it and want to reap its benefits, yet actual implementation of scalable solution is not as simple as it may sound. Various factors play role in deciding whether designed solution covers all scenarios with minimal or no impact on end users.

• CAP Principle i.e. Consistency, Availability and Partition. Scalable Workloads and Infra, both must be designed around this principle. You may have to trade off, to ensure atleast two out of three areas are covered
• LoadBalancing for your scalable workloads also grade your system design. Beside deciding on load balancing algorithm for your LB, design should also avoid making your loadbalancer as SPOF (Single Point of Failure)

6. Networking

This one may be one of the easiest part for cloud newbies as well. Design and role of resilient, low latency and high bandwidth network is more or less same. We need to Carrier grade FW in front, NAT for Internet access, Direct Peering and VPNs for site access and highly available telemetery system for keeping an eye on network performance. Again, for public cloud we may purchase most them from cloud provide itself, though things may change if we setting up our own enterprise private cloud.

7. Storage

Like, other topics mentioned here, covering whole storage requirements and scenarios may take a full length blog discussion. But I may cover few pointers here and than you may decide which solution to use in your design.

• File, Block or Object Storage based on workloads requirement
• Based on IOPS, you can chose SSD or HDD. It can also help in deciding and cutting down your cost
• Data security by considering Data at Rest, Data in Transit encryption techniques
• Use of CDNs to have less frequant data traffic over internet in case of multi region applications
• Frequancy of data access in order to decide on using cheap archive data lake solutions instead of regular storage

In my next blog, I will cover what to consider for Operations, Security and DevOps frameworks in designing your Cloud Architecture.