Google admits Kubernetes container tech is so complex, it's had to roll out an Autopilot feature to do it all for you

Google has recognised that users struggle to configure Kubernetes correctly and introduced a new Autopilot service in an attempt to simplify deployment and management. Two things everyone knows about Kubernetes are: first, that it has won in the critically important container orchestration space, and second, that its …

[JacobZ]

Surprise

Deployment of workloads and dependency management are fundamentally hard. Adding more layers of abstraction doesn't make that go away.

[Claptrap314]

Re: Surprise

They are hard enough to require dedicated expertise. Point & click interfaces that can actually deliver what is needed are a very, very long ways off.

[Claptrap314]

Free tier view

AWS allows free usage indefinitely if you keep your usage low, with api fully available for the free-tier services.

GCP allows free usage for three months if you keep your usage low, and finding the api? I ended up giving up.

Google KNOWS that human error causes 80% of their own OMGs. Using the API is the only acceptable way to manage prod resources. And yet, they don't seem to want you to play at that level.

[Ben Tasker]

Re: Free tier view

> Using the API is the only acceptable way to manage prod resources

That's just Google and APIs though.

It's not just GCP, their APIs and management of access to those APIs in general are a complete mess, often relying on you knowing the exact link to get to something

Fairly recently I was adding a NEST thermo to HomeAssistant. Just look at the setup instructions - https://www.home-assistant.io/integrations/nest/#device-access-registration - and then consider that there are steps/bits missing.

Google's problem with APIs has always been one of discoverability. The APIs themselves are (generally) solid, but actually finding the API you need to enable is a nightmare. There's a similar issue with their documentation - the APIs are well documented, but to find that documentation you often need to already know the API you need.

It's a shame, because they've got some incredible minds behind those APIs, but it really is hard to recommend building any dependency on GCP if there's an option to use AWS (or even Azure) to achieve similar ends.

[tip pc]

Advertisement

That read like an advert to me.

Does sound like it adds some assurance, but deliberately removing ssh sounds like it’s appealing to those security types who have no clue as to how anything works or people do stuff but have heard about engineers ssh’ing into stuff and consider things would be safer if they couldn’t do that.

[Anonymous Coward]

Re: Advertisement

"removing ssh sounds like it’s appealing to those security types who have no clue as to how anything works or people do stuff but have heard about engineers ssh’ing into stuff and consider things would be safer if they couldn’t do that."

Yep, it also blocks mutating webhooks, so is useless for anything more than simple stateless service deployment

[sed gawk]

Re: Advertisement

I'm torn, without SSH is avoiding in place debugging.

But if your remediation is replace the image, then I'm not against it.

You do end up doing spinning up a box with ssh, doing the build and saving a snapshot post config.

So its not so much without SSH, but running a previously configured image without SSH.

[JohnSheeran]

Re: Advertisement

Remediation for these things IS to replace the running container. Using SSH to troubleshoot a running container in production is really missing the point.

Making a container a simple virtual server replacement is missing the point and asking for trouble. Fix the problem in dev and roll it to production. You shouldn't need SSH in production. It's a crutch.

[Abominator]

Sorry, but anything Google touches as a 'product' dies fairly quickly.

[Throatwarbler Mangrove]

Totally

Ads, search, email, streaming video: abandoned and dead!

/s

[Lusty]

Re: Totally

"Ads, search, email, streaming video: abandoned and dead!"

No, they aren't selling any of those as a product. They're selling your privacy, and that died almost immediately.

[A.P. Veening]

Re: Totally

In screaming agony and not immediately.

[steviebuk]

And buy into a service and notice a few months later they change it. I was about to do a video on how to get unlimited drive space for just over £100 compared to the cost of Amazon Drive, Google Drive etc. It involved a little bit of knowledge, paying for a domain name, paying for small bit of hosting then paying the business package of Gsuite. Set it up and you have unlimited drive space for one user for only £11 a month, and if you set it up you can use the email, google docs etc. Altogether works out cheaper per year than Amazon drive etc.

I was on the basic package originally as last company used it. So wanted to keep the knowledge up. Realised the above was cheaper than the drive only packages and I could use it as offline backups for all my home stuff. Noticed on my bill the name had changed, so looked it up. Found out they'd scrapped my package (although I've not been forced off it yet) and if you want unlimited storage you now have to pay for the enterprise package.

Bastards.

[JohnSheeran]

You're why we can't have nice things.

[steviebuk]

Nothing to do with that as it doesn't break the terms of service.

[Claptrap314]

So they did to you what the datacenters did to them in '99 when they invented blade servers?

Take advantage of a hole like that--expect it to be closed fairly quickly.

Not that I blame you--it's just facts.

[Warm Braw]

Enterprises are embracing Kubernetes, but then...

It sounds like "enterprises" ought to be doing a little more research and not simply following a trend. Having an application broken down into a lot of microservices raises issues of authorisation and data consistency as well as deployment and resource management. All that comes at a cost; you need to identify the compensating benefit before you start "embracing" anything.

[ecofeco]

Re: Enterprises are embracing Kubernetes, but then...

They did identify the benefits and the executives bonuses look pretty good!

Or did you mean efficiency and TCO? What does that have to do with executive bonuses?

[Greybearded old scrote]

Turtles all the way UP?

How many layers of bugs are we supposed to tolerate in this sodding baklava? Code is evil, strive to use less.

Personally I'm trying to learn Elixir/OTP. Basically a genuinely lightweight services architecture. (Nanoservices?) I'll see how that goes.

[shortfatbaldhairyman]

Re: Turtles all the way UP?

So am I! Trying to learn Elixir, that is. This is worrying.

[sed gawk]

Re: Turtles all the way UP?

Elixir, have fun when it hits beam.

There is no free lunch.

[Greybearded old scrote]

Re: Turtles all the way UP?

Not expecting free, but the existing methods are getting very expensive.

Since BEAM is the vm that runs it, isn't that like saying 'when Java hits JVM?'

[sed gawk]

Re: Turtles all the way UP?

More a shudder of remembering inscrutable messages spewed forth by the VM.

It's not so much a comment on the language itself..

[Smartypantz]

Threadmill

No matter how many layers of Virtualization, Containerization, frameworks, hyped-up cloud marketing and clueless managers you inject, you still need to program the computer to the satisfaction of your end user.

peak IT productivity was decades ago!

It's gonna blow!!!

[ecofeco]

Re: Threadmill

This. The big crash is coming. Too many layers of utter shite stacked too high.

[frankyunderwood123]

The problem is ... people like me

So, what's not to love? - the management of complex server architecture as a series of, on the surface, simple text files.

Hoorah for devops!

The problem here, is that understanding the complex architecture of networking and underlying resources of hardware, is ... quite an advanced skill set.

Sure, it can now be expressed with code, but that doesn't mean the underlying complexity is any less - it just means a n00b with hardly any knowledge of the complex architecture behind what they are doing, can construct a text file and fling it at, say, AWS, supposedly safe in the knowledge "it will just work"

More often than not, sure, it does. Layers of redundancy and hopefully some decent peer reviews will usually prevent serious P1 downtime.

But, as we all know, it's that 1% of cases that fling the shit at the fan - and the n00b coding infrastructure in a yaml file has zero understanding, really, of what has just transpired.

Devops is in it's infancy - and we absolutely need seasoned IT people who were around before these developments, to provide the understanding required to ensure the most uptime possible.

Out.

[A.P. Veening]

Re: The problem is ... people like me

Devops is in it's infancy

And security is (as always) conveniently forgotten until after the breach.

[DevOpsTimothyC]

Re: The problem is ... people like me

And security is (as always) removed for cost and productivity reasons until after the breach.

---

FTFY

[ecofeco]

You mean un-necessary complexity?

It's that the point? Job security through complex obscurity?

[Son 1]

Normal

Installation programs have been around since the inception of computers. The reason is most programs are very difficult to install, hence an .exe file that does it for you.

Nothing to see here.