Billions of dollars and thousands of engineering years worth of effort from some of the brightest minds have gone into building resilient, well-architected and performant services offered by hyperscalers.
“If you are not adopting native services specific to the hyperscaling cloud service provider you have adopted, you may be leaving money on the table,” says Dale Slabbert, CEO of TrueMark. “As an AWS partner, we consistently see companies attempting to design workloads to be cloud agnostic. This does not mean multicloud, which can be a sound strategy where you place the right workloads with the technology that best fits your requirements. Instead, we are referring to architecting the same workload to run on multiple hyperscalers.
“The common argument we hear is that it’s expensive to move cloud providers and vendor lock-in is to be avoided at all costs. We argue that a cloud-agnostic approach will increase engineering effort, complexity and scope and this increases upfront costs and the opportunity cost of getting your changes to market. We also argue that these costs are equal to or greater than what you will pay to re-engineer for a cloud swap in the future.”
Slabbert explains that with a cloud-agnostic approach – unless the business plans to engineer for each cloud provider – it will be limited to engineering with virtual machines or the open source Kubernetes software platform as they are the common services across AWS, Azure and GCP.
“Both Amazon EC2 and Amazon Elastic Kubernetes Service (EKS) require more effort, time and engineering skill than leveraging services like AWS Elastic Container Service (ECS) or Azure App Services,” continues Slabbert.
Rocket science
“With Kubernetes specifically, you will have to implement node autoscaling patterns, ingress controller patterns, secrets management and cluster DNS, for example, which also have to be maintained, patched and monitored. Any engineer who has worked extensively with Kubernetes would agree with the quote, ‘it’s not rocket science, but it can be’.
“Even if you opt for an Infrastructure-as-Code (IaC) platform that’s cross-cloud, such as Hashicorp Terraform, Pulumi or Open Tofu, you will be writing code specific to each cloud provider, increasing your upfront costs. As the most basic example below, look at the resource to create an EC2 and Azure Virtual Machine in Terraform – which are distinctly different resources.”
resource "aws_instance" "example" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t4g.small"
…
}
resource "azurerm_linux_virtual_machine" "example" {
name = "example-vm"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
size = "Standard_F2"
…
}
Slabbert says there is cost-saving by using services that are pay-for-use rather than pay-to-run.
“Always on means that you are always paying for it. This cost adds up when you could leverage serverless technologies like AWS Lambda or Azure Functions. Running AWS Lambda, for example, especially on graviton, is often far cheaper than running an EC2 instance or small EKS cluster that’s always on.”
Amplify engineering efforts
According to Slabbert, with less code to write, fewer resources to manage and reduced design complexity, engineers will be able to speed up delivery times. He also says that leveraging services that are performant, robust and designed with fault tolerance like SQS/SNS, Firehose, EventBridge, StepFunctions, DynamoDB and RDS, amplify engineers’ efforts.
“You can speed up time to market when you can code and manage less to achieve complex outcomes. All AWS services have high-availability and fault tolerance designed into them, which means that you don’t have to architect these yourself.
“Hyperscalers know how to secure workloads in their clouds and have provided pay-as-you-use services you can leverage to assist in cyber security efforts. AWS specifically has native security tools you can leverage such as SecurityHub, Trusted Advisor, Guard Duty and Config.
“South Africa has done remarkable things with technology, but inaccurate perceptions remain around how to derive the best from cloud services. Cloud migration here is not as far advanced as is assumed and the bottom line, especially with the country’s economic pressure, is there is value in talking turkey with a company like TrueMark, drawing from global expertise that has its foundation in over a decade of tackling application migrations, modernisation, automation and management,” concludes Slabbert.
Share