So you either adopt serverless patterns (the kind of serverless that means scale to zero and pay nothing when you do) or you adopt auto-scaling, where you shut down instances when traffic is lower, to minimize idle time. Or both.
cloud native = use more serverless products (pay as you go with no base price)
For instance, one could implement internal DNS using instance which run bind, and connect everything through some VPC, and put a load balancer in front of the instances. One could also rework its DNS architecture and use route53, with private hosted zones associated with all the appropriate VPCs
Another real example: one could have hundreds of instance running gitlab runners, running all day, waiting for some job to do. One could put those gitlab runners into an autoscaled kubernetes, where nodes are added when there are lots of jobs, and deleted afterwards. One could even run the gitlab runners on Fargate, where a pod is created for each job, to run that job and then exit. No job = no pod = no money spent.
Of course, some work is required to extract the best value of cloud providers. If you use only instances, well, surprise: it costs a lot, and you still have to manage lots of stuff.
Just before I left I was investigating using hetzner instead - our compute bill would have been about 15% cheaper, we would have had no cache storage costs (which was about 5x our compute costs), and the builds would have finished before fargate had processed the request.
Our numbers were small fry, but we spent more on that CI system than we did on every other part of our infra combined.
The term “native” refers to adopting the vendor’s technology stack, which typically includes managed data stores, containerized microservices, serverless functions, and immutable infrastructure.
I work for a very large org, and cloud benefits are not obvious to me ( ie we’re large enough to absorb the cost of a team managing k8s for everyone, another team managing our own data centers around the world etc ).
I view cloud as mutualizing costs and expertise with other people ( engineers and infra), but adding a very hefty margin on top of it, along with vendor lockin.
If you’re big enough to mutualize internally, or don’t need some of the specific ultra scale cloud products, it’s not an obvious fit to me ( in particular , you don’t want to pay the margin )
I understand that for a significant chunk of people it’s useful provided that they use as many mutualizing levers as possible which is what going native is about.
Is my understanding correct ?
I think one point that’s often overlooked is the knowledge gap between the engineers at cloud providers (such as systems, platform, or site reliability engineers) and those that an individual company, even a large one, is able to hire.
This gap is a key reason why some companies are willing—or even forced—to pay the premium.
If average or mediocre management skills and a moderately complex tech stack are sufficient, then on-premise can still be the most cost-effective choice today.
I agree with the gap, and I understand why people would like to pay for the premium.
Where I work currently, wherever we don’t have the right people ( and usually because we can’t find them ), our cloud-like on-premise offering doesn’t work which ends up causing significant extra costs further down the chain.