Our Current Setup

 “Currently, our organization follows a hybrid multi-cloud architecture that includes on-premises infrastructure along with workloads running on AWS, Azure, and a small footprint in OCI. The majority of the workloads are hosted in AWS and Azure, while OCI is mainly used for a few specialized VM-based workloads. The environment is designed for high availability, scalability, disaster recovery, and secure connectivity across all platforms.

Starting with the overall architecture, we have a mix of traditional applications, containerized microservices, and legacy systems. Some critical applications still run on-premises due to compliance, licensing, and low-latency requirements, while cloud-native applications are distributed across AWS and Azure.

From the on-premises side, we maintain VMware-based virtualization infrastructure hosting internal applications, Active Directory services, file servers, monitoring tools, and a few legacy databases. The on-premises datacenter is connected securely to AWS and Azure using site-to-site VPNs and, for critical traffic, dedicated private connectivity such as AWS Direct Connect and Azure ExpressRoute. This provides stable low-latency communication between cloud and on-prem environments.

In AWS, most production workloads are hosted there. We primarily use Amazon EKS for Kubernetes-based microservices deployments and EC2 instances for some traditional workloads. The AWS environment is organized using multiple VPCs segregated by environments like development, staging, and production. Within each VPC, we have public and private subnets distributed across multiple availability zones for high availability.

Application traffic in AWS typically flows through Route 53 for DNS resolution, then through an Application Load Balancer or Network Load Balancer depending on the use case. Traffic is routed into EKS clusters or EC2 instances hosted in private subnets. Security Groups and Network ACLs are implemented for traffic filtering and network security.

For storage and databases in AWS, we use services like RDS, Aurora, DynamoDB, S3, and EFS. S3 is heavily used for application artifacts, backups, logs, and static content storage. IAM roles and policies are strictly enforced to control access to resources.

In Azure, we mainly host enterprise applications, integration services, and some internal APIs. AKS is used for container orchestration similar to EKS in AWS. Azure Virtual Networks are designed with subnet segregation for AKS, databases, and application gateways. Azure Application Gateway with WAF is used for secure ingress traffic management.

Azure services such as Azure SQL Database, Cosmos DB, Storage Accounts, and Key Vault are integrated into the environment. Azure Active Directory acts as the centralized identity provider for both Azure services and some federated on-prem applications.

OCI is comparatively smaller in our setup. We mainly use OCI for a few VM-based workloads that require Oracle-specific integrations or licensing advantages. These workloads are hosted on OCI Compute Instances with VCN networking. Connectivity between OCI and the rest of the environment is maintained through VPN tunnels.

For connectivity between all platforms — on-prem, AWS, Azure, and OCI — secure hybrid networking is established using VPNs and private connectivity solutions. Internal DNS resolution and routing are configured carefully to allow secure inter-service communication across clouds.

From a CI/CD perspective, we use centralized DevOps pipelines through Jenkins and Azure DevOps. Source code is stored in Git repositories. Pipelines handle build, testing, Docker image creation, vulnerability scanning, and deployments across Kubernetes clusters in AWS and Azure.

Container images are stored in ECR for AWS workloads and ACR for Azure workloads. Infrastructure provisioning is automated using Terraform, which helps us maintain consistent infrastructure deployment across multiple cloud providers.

For monitoring and observability, we use a centralized monitoring approach. AWS CloudWatch, Azure Monitor, and on-prem monitoring tools feed logs and metrics into centralized dashboards. Application logs are aggregated using tools like ELK Stack or Splunk. Alerts are integrated with incident management systems for proactive monitoring.

Security is implemented using multiple layers. Identity and access management are handled using IAM in AWS, Azure AD in Azure, and RBAC controls in Kubernetes. Secrets and certificates are stored securely using AWS Secrets Manager, Azure Key Vault, and occasionally HashiCorp Vault for cross-platform secret management.

Disaster recovery and business continuity are important parts of the environment. Critical workloads are distributed across multiple availability zones and regions. Backup strategies are implemented across databases, storage systems, and Kubernetes clusters. Some workloads also have cross-cloud DR strategies where failover environments exist in another cloud provider.

Overall, the environment is designed as a secure, scalable, hybrid multi-cloud platform where AWS and Azure host the majority of workloads, OCI supports a few Oracle-specific systems, and on-premises infrastructure continues to support legacy and compliance-driven applications. Automation, monitoring, security, and high availability are key architectural principles followed throughout the environment.”

Comments

Post a Comment

Popular posts from this blog

Azure Migrate

Image
 Azure Site Recovery an earlier tool for migration: Thought purpose built for Disaster Recovery ASR: Azure Site Recovery Yes — Azure Site Recovery (ASR) is commonly used as a migration tool , even though its primary purpose is disaster recovery. How ASR Is Used for Migration Organizations use ASR to perform: Lift-and-shift migrations VMware to Azure migrations Hyper-V to Azure migrations Physical server to Azure migrations ASR replicates workloads continuously from on-premises infrastructure to Azure. During the final cutover, the replicated VM is started in Azure with minimal downtime. Migration Workflow Using ASR Typical Flow Discover on-prem servers Enable replication Continuous data synchronization Test failover (optional) Planned failover/cutover Azure VM becomes production workload This approach minimizes: Downtime Data loss Manual rebuild effort Why ASR Is Popular for Migration ASR vs Azure Migrate Real-World Use Case Example: Company has 200 VMware VMs on-premises. The...
Read more

Azure -- All Networking Components

   1. Virtual Network (VNet) 📌 One-paragraph explanation A Virtual Network (VNet) is the core private networking space in Azure where all cloud resources communicate securely. It is used to isolate workloads, control IP ranges, and create a private environment similar to a traditional data center network but fully software-defined in the cloud. 🔍 Details Where used: Hosting VMs, AKS clusters, databases, internal services Connected services: VM, Load Balancer, Application Gateway, Azure Firewall, Private Endpoint Dependencies: None (foundation component) Purpose in architecture: Acts as the main “network boundary” for all resources 🧩 2. Subnet 📌 One-paragraph explanation A subnet is used to divide a VNet into smaller logical networks so that different layers of an application (web, app, database) can be separated and controlled independently for security and traffic management. 🔍 Details Where used: Tiered architectures (web/app/db layers), microse...
Read more

All Kuberneters - Components

  Kubernetes Core Resources Explained 1. Pods What It Is A Pod is the smallest deployable unit in Kubernetes. It contains one or more containers that share: Network Storage Lifecycle Used For Running application containers Grouping tightly coupled containers together Example A web application container running inside a pod. 2. Deployments What It Is A Deployment manages Pods and ReplicaSets. Used For Rolling updates Application version upgrades Scaling applications Self-healing applications Example Deploying 3 replicas of an NGINX application. 3. ReplicaSets What It Is A ReplicaSet ensures a specified number of pod replicas are always running. Used For High availability Maintaining desired pod count Example Keeping 5 backend pods running at all times. 4. DaemonSets What It Is A DaemonSet ensures one pod runs on every node (or selected nodes). Used For Monitoring agents Log collectors Security agents Example Running Fluentd or Prometheus Node Exporter on all nodes. 5. StatefulSets W...
Read more