Hacker News Reader

Comment by outside1234 | Hacker News Reader

You probably don't need the cloud either, but everyone recognizes that it is a productivity gain. To me, this is the analogous case for K8s, you can probably do the same with VMs, but everything is a lot more productive with containers and K8s.

View on HN

I worked at a place that was deploying K8s as I was leaving and my experience was that K8s was complicated and no one knew exactly how to use it or why we should use it, other than it seemed to be what everyone else was doing. I didn't notice any operational improvements over our prior system (which was largely ad hoc), but the kinks may have been worked out by now.

If you read the Innovators Dillemma, there is a very clear chapter about how new technologies don't really deliver their promises immediately; but as they're adopted and operators/users learn how to work with it, that's when productivity changes are very much visible. It took quite some time for AWS to be mainstream and then to be adopted and operated in a way that delivered high productivity gains, and it seems to be the same for k8s right now.

I really wonder about the causality of that, is it changing things to adapt the new technology makes you clean up / refresh / fix known issues along the way or is it the new technology itself causes less issues down the track

That doesn't really make sense. If you're moving to a new technology, even if you clean up/refresh/ fix known issues along the way, you are likely to accumulate similar such issues in the new technology as well, which would lead to a decrease in productivity. But that has never really been observed.

While I agree that the cleanup can inevitably lead to productivity gains, I believe they are overshadowed by the productivity gains from the actual change that is being made.

That only makes sense when seen as an obstacle to initial adoption from an innovators and sales point of view and could be said just about every innovation. But obviously not every IT innovation makes it.

It depends on how frequently you need to spin up new containers.

As someone on Azure, I think the solution for small-ish guys like me (who still need like 8 VMs in production to run our site due to special requirements) is a greatly simplified container management system. Something that fulfills the basic Kubernetes features, but isn't such a steep learning curve.

I think Microsoft is doing this with Azure Container Instances, but I haven't tried it yet. (No doubt AWS is doing something about it as well.)

Or they're going to take care of all the k8 configuration crap through some neat Visual Studio Tools. In a VS preview I saw a "deploy to Kubernetes" button. I just want something that will give me more web API instances when my server is getting slammed.

AWS ElasticBeanstalk or Google App Engine flex or something from Heroku is what you are talking about. Container management but simplified for the common use case. You can implement the same thing with k8s, but why bother for small stuff. The real value in k8s is large, company-wide installations where everyone shares each others hardware. Even then, I've heard anecdotes that kubernetes doesn't scale to the point Borg or whatever other proprietary system does. Then again, those are niche use cases to begin with.

Unless they've reduced the price, Azure Container Instances is mainly for one-off/bursty tasks. If you need a service running 24/7, it's prohibitively expensive.

I think once their managed kubernetes (AKS) hits GA, the learning curve will be slightly lower.

Right, container instances isn't equivalent to deploying a vm with coreos like gcp offers.

We've been running off aks for a bit, the only negative is how slow spinning up new clusters can take.

Did you mean this? https://azure.microsoft.com/en-us/resources/videos/connect-2...

> You probably don't need the cloud either, but everyone recognizes that it is a productivity gain.

Care to quantify that? Because we don't use the cloud (in fact, in my current role, we don't even make use of virtualisation for production infrastructure) and we have no issues with productivity. Or rather, let's be a little more honest, we have no issues with productivity that would be solved by a move to AWS/Azure/$_some_other_cloud_provider.

Just because you "have no issues with productivity", doesn't necessarily mean that you couldn't be more productive. In my experience it takes a move to the cloud to actually see where those gains lie.

Disclaimer: I have no idea about your actual real-life situation. This is vague and hand wavy on purpose.

> In my experience it takes a move to the cloud to actually see where those gains lie.

Whilst I realise you were being vague on purpose, the above statement represents no kind of business justification.

Indeed it is not meant to be any kind of business justification - I clearly cannot comment your business and its needs :)

In my experience of moving applications to the cloud, there are always folks who don't believe there is any gain to be made. These folks have always been wrong (so far!)

I suppose I'm only commenting because I hate to see someone snub the potential of cloud. But hey I'm just some guy on HN.

The thing is, in previous positions we've used the cloud plenty, and it's been fine. But for what I'm doing now? No way. Just not the right fit. I therefore become extremely sceptical when people cite $unspecified_but_awesome_gains from switching.

That's awesome. Can you elaborate more on your setup, and why cloud doesn't make sense? I'm really interested in cases like this.

You forgot about all the folks managing / maintaining / cabling / air conditioning all your servers. That is the productivity gain you are missing.

I doubt they are running their own data center. Probably just renting dedicated boxes.

> Probably just renting dedicated boxes.

Absolutely correct.

I don't have much practical experience with Kubernetes but I think one argument is that there are other alternatives to it that might give equal or better productivity gains for a lot of people.

For example Azure App Service or equivalent from the other vendors. You don't have to manage a VM.

App service is alright but I'd recommend Heroku over app service any day. However, there is some visible work being done to improve app service like supporting docker compose files to run multiple containers but the basics are still very painful.

Most notably, swapping servers (slots) always caused downtime, accessing logs was flaky and slow, azure interface is just plain slow, continuous deploy was flaky (or it just didn't kick in until 20 min later?) and I had to manually restart servers many times

Reply on news.ycombinator.com