Cloud Networking and Security Challenges and Solutions - Part 2
In Part one of this blog, we covered off how Networking is one of the key foundations for success in the Cloud and addressed the challenges and options related to: Connectivity, IDAM and DNS.
In this Part 2 of the Blog we will address the challenges and solutions related to: BC and DR, Security and Automation.
Business Continuity and Disaster Recovery
Resilience and Disaster Recovery are done differently in the Public Cloud.
Things we take for granted on-premises like Virtual Machines accessing shared storage, which enables features like HA, V-Motion and Fault Tolerance- do not exist in the public cloud. This makes resilience within the network architecture even more important.
Dependent on the business needs of each application, we need to architect layers of availability and resiliency across all your environments and clouds. This includes architecting for:
· Multi Availability Zone resilience,
· Having subnets that can span across Availability Zones,
· Ensuring that your Load Balancers are Availability Zone resilient,
· Deploying Virtual Machines across Availability Zones so you can easily failover.
Each of these layers needs to be designed with this in mind.
Automation is really important, and you should be provisioning using Infrastructure as Code tools and automating as much as possible.
Automation also makes cloud governance easier, as through using things like naming conventions and tags for resources, you can identify and control costs. This is because you can track and allocate spend to the right cost centres in your organisation.
If you are using only 1 Public Cloud, the Cloud native tools will be easier to automate than third party tools, as the tooling and API’s are more seamless and integrated. In Azure ARM templates are good and also Hashicorp’s Terraform are great as they work across different clouds and on-premises platforms.
It is vital to be aware that there is a fine line between global scripting of templates vs more defined local templates as the blast radius is larger, because an error in code that you deploy across your whole environment will bring everything down.
SDWAN also has a place in the architecture.
It is easier to deploy SDWAN if you’re only connecting a few sites but when you reach a certain threshold, the number of subscriptions you need to purchase, and costs will increase.
However, SD WAN is fantastic for bonding cheap links together and providing QoS and Failover across lower cost links.
Many of the SD WAN providers have solutions that integrate with the Public Clouds both for SaaS and IaaS.
There are even a few services like Arayaka where you can consume SD WAN as a Service.
If you are interested in our other Cloud, Infrastructure and Security related Blogs please click here.