HN Explorer

Ask HN: Is Cloud Native development a cash cow by big tech?

3 points by exdsq ↗ HN
I was looking through the CNCF tools and certificates, with all the cloud deployment options, and realised the main advocates are Google and Amazon. They appear to make these cloud options seem sexy while it's also very hard to move away from a cloud system once it's built. By sexy, I mean people like to build things how Google builds things and Resume-driven development means that this can result in higher salaries for the people using these tools.

This might be a cynical view, but is the modern approach of software engineering just a giant sales campaign ran by cloud providers to increase their profits?

9 comments

[ 5.7 ms ] story [ 32.5 ms ] thread
emteycz
Cloud native development most definitely has merit. Even when done with proprietary tech. IME, for most workloads, I save money, not pay more.
jqpabc123
There is some vendor lock-in going on but you don't have to play along. You can always use the cloud as a simple, cheaper alternative to co-location or self hosting.

This way you keep your options open and can easily move from one cloud to another or back to self hosted if needed.

PaulHoule
Elastic Compute is not cheaper than co-location or self hosting if you run a service for 24 hours a day. It's arguable if it is "simpler", but probably is if spinning up a new server means buying a new server or talking to sales people at a hosting provider who will surely garble your order.

For some things serverless and cloud-native is crazy cost effective. I have a system that handles the annoying things about running email blasts such as double opt-in, bounce cleaning, etc. A system like that might go practically unused for a few months and then have a fierce burst of activity. I don't have to pay for a server to do nothing for long times and then have it run out of capacity when I need it.

jqpabc123
This may be a function of utilization factor but the modestly loaded 24/7 EC2 instances I have been running for the last 5-6 years are more reliable and about half the cost of co-location --- before even considering the cost of hardware. I can easily move back to co-location if needed but thus far, I have no reason to do so.
PaulHoule
Expensive certifications were a thing long before the cloud. Look at the Microsoft certifications, Oracle certifications, Red Hat certifications, etc.

My current cloud-native side project is based in AWS but I don't see any fundamental problem migrating it to Azure or Cloudflare. I can think of hypothetical reasons why I would want to, but practically making it portable and running multiple instances of it is the last priority compared to all the other work it needs.

throwaway894345
Personally a lot of the “cloud native” things like Kubernetes are just easier to wrangle than manually, imperatively configuring a bunch of hosts.
Nextgrid
Maybe once you learn it, yes, but it has a huge learning curve that needs to be taken into account. Furthermore, how many extra moving parts does it involve? If all you need is a handful of hosts, those moving parts may be a liability - AWS us-east-1 is down, and I'm pretty sure it's due to the extra complexity rather than hardware failure.
throwaway894345
> Maybe once you learn it, yes, but it has a huge learning curve that needs to be taken into account

Agreed, but so does the alternative. You need to understand and configure software for process management, SSH, logging exfiltration, host monitoring, reverse proxying, load balancing, infrastructure as code, configuration management, DNS, service discovery, firewall rules, certificate management, etc etc. All of these software are built by different parties with different conventions and inter-compatibilities, and very often they are configured by managing configuration files (each with their own distinct format) such that the configs that pertain to a given application are distributed across your systems in dozens of configuration files (as opposed to Kubernetes where you can keep all of your application's configuration in a single manifest or directory of manifests as you prefer).

So yes, Kubernetes has a steep learning curve, but I posit that it's much less than figuring out how to cobble together your own platform by trying to identify and learn the best combinations of software from each category. With Kubernetes, you get a lot of standardization--you're on a happy path with lots of other people who are on the same path and thus benefit from an abundance of information, experience, and tooling which aren't going to be available for your bespoke system. Moreover, Kubernetes is relatively young and maturing quickly--it's getting progressively easier to work with all the time.

Nextgrid
The principles are sane and good, however they indeed only really apply for world-scale problems, and in my opinion very few problems actually are world-scale.

VC-bankrolled garbage that wants to take over the world from day 1 would fit, however most legitimate business problems require nowhere near this scale and at that point "cloud native" development may be a downside in the form of unnecessary complexity.

For legitimate business problems (where conquering the world from day 1 isn't a priority), don't underestimate how powerful one or two bare-metal machines can be, and you can get those for less than 100 bucks a month from Hetzner or OVH, with unlimited bandwidth to boot.

Reliability may be a concern, but modern hardware is pretty reliable and cloud-native development involves tons of moving parts that come with their own downsides. I've seen more outages caused by all that extra complexity and operator error than hardware failure. AWS us-east-1 happens to be down right now for example, but my old-school bare-metal machines and network hardware are all still running.

It is however "uncool" which means you'll have more trouble acquiring talent. You don't have the option to have resume-driven people queue up to work for you for low salaries because you work with the new shiny, you actually have to pay good money and make efforts to retain these people.