Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running Istio In Production

engineering.hellofresh.com

Post reply on HN
Print view View original

31–40 of 47 posts

Re: Running Istio In Production

#31

Post by rurounijones »

kortilla wrote: post #27
rurounijones wrote: post #22

Lots of shallow dismissals in the comments for this and it seems to be a trend every time microservices come up. "N Microservices for $BUSINESS_DOMAIN ? Crazy!" Can't we just taka it on good faith that the engineers who do these blog posts have at least a modicum of competence and therefore their solution has _some_ merit (that is worth discussing) rather than just "Micro-services bad" dismissals? Yes I realise this…

No, it’s a blog post about running a cutting edge technology in production. Whether or not fundamental decisions were made correctly is vey much in play.

The blog post is about "Running Istio in production". Not "Why we chose to run istio in production" so I don't think "they shouldn't be running istio in production" it is in scope.

_However_ if you want to have a constructive discussion about if isio is even the right choice here then have at it if you think there is enough info to go into that. (Personally I don't think there is enough info in the blog post to have that discussion... since that is not the point of the blog).

Again, my comment was mainly aimed at the shallow 1-sentence dismissal comments that crop up on these posts.

Re: Running Istio In Production

#32

Post by [deleted] »

rurounijones wrote: post #29
altmind wrote: post #26

Earlier quoted context omitted.

>> Can't we just taka it on good faith that the engineers who do these blog posts have at least a modicum of competence and therefore their solution has some merit On a technical resource, no. In a technical article, technical points need to be explained. Decisions need to be checked. Unless your argument is "it cannot be bad because it must have been checked by many people", we are totally in the position to provide…

If you want to give constructive feedback then have at it. My comments were aimed at the shallow dismissals at the level to which I gave an example (and examples of which can be found in the comments on this post). If a response to these articles is along the lines of "OMG they are using microservices, BAD!" then that is not constructive or useful unless you are trying to invoke Cunningham's Law (Or whatever the one…

[deleted]

Re: Running Istio In Production

#34

Post by hunta2097 »

geuis wrote: post #10

Having struggled with setting up kubernetes over the last month on my own, I’ve come to realize the absolute value of simplicity. In the end Helm just introduced more problems than it solved. Rather than applying configs haphazardly and relying on 3rd party services, it was ultimately much simpler to just download the configs for whatever service was needed (nginx ingress controller for me) and committing them to sou…

Istio solves lots of problems (pod-to-pod encryption, telemetry, etc).

It also enables lots of functionality when it comes to CD. It enables things like canary releases, testing, rollback etc etc in a simpler way by keeping it in the Kubernetes space (and not relying on slow external LBs).

You probably won't know why you need Istio till you need it.

Re: Running Istio In Production

#35

Post by TeMPOraL »

elbear wrote: post #33
core-questions wrote: post #2

Delivering pre-packaged meals to people requires _hundreds of microservices_. That is truly astounding.

If you turn every function into a microservice, then you can have hundreds of microservices. I still don't see the benefits though.

Given where this is going, couldn't we just skip a couple iterations of the hype cycle, and simply port BEAM runtime to work directly on machine clusters instead of machine code? This way we'll jump straight to one actor = one microservice = one VM.

Re: Running Istio In Production

#36

Post by TeMPOraL »

theK wrote: post #21
geuis wrote: post #10

Having struggled with setting up kubernetes over the last month on my own, I’ve come to realize the absolute value of simplicity. In the end Helm just introduced more problems than it solved. Rather than applying configs haphazardly and relying on 3rd party services, it was ultimately much simpler to just download the configs for whatever service was needed (nginx ingress controller for me) and committing them to sou…

This is actually the advice I’m giving every new systems engineer that joins our organization. Learning how Kubernetes works is much easier if you first get a firm grasp of the basics and then start bolting stuff on like istio knative and all the other cool stickers “modern architects” wet dream about.

Here's a worrying trend: software architects seem to talk in brand names instead of concept these days.

Re: Running Istio In Production

#38

Post by roytries »

core-questions wrote: post #2

Delivering pre-packaged meals to people requires _hundreds of microservices_. That is truly astounding.

I work for a large webshop. I was amazed by how many engineers work here. But now, after two years, I understand why we need them. Handling millions of customers, sending millions of parcels, logistics, storage, customer support, etc... requires a lot of systems. It is definitely more complex that you would image at first glance.

All of those systems need each other's information. The shop needs to know if a product is available, and what price it is. Customer Service needs to know how it was sent and the tracking code etc,...

We've built hundreds of microservices to manage this. This is definitely not something that is easy in a monolith. (We came from a monolithic architecture, we're really happy we're now using microservices).

We're now also rolling out Istio on GKE. So who knows, they might be on to something at Hello Fresh.

Re: Running Istio In Production

#39

Post by BossingAround »

I recently started investigating Istio, and though it will probably be an unpopular opinion here on HN, I honestly don't understand why it's not a core part of Kubernetes.

It's amazingly simple to configure, the docs are pretty OK, and the benefits seems huge. Mutual TLS within minutes? BAM, done. Don't worry about cert rotation, Citatel does that for you.

Block all egress, and whitelist what you need? Like, that's a killer feature! Also, the inability to do 90-10 canary releases with plain K8s baffles me. With Istio? Simple...

I don't know, I'm sure I'll find the pains of Istio in the coming months, but in my dev cluster, it looks amazing.

Re: Running Istio In Production

#40

Post by tmpz22 »

BossingAround wrote: post #39

I recently started investigating Istio, and though it will probably be an unpopular opinion here on HN, I honestly don't understand why it's not a core part of Kubernetes. It's amazingly simple to configure, the docs are pretty OK, and the benefits seems huge. Mutual TLS within minutes? BAM, done. Don't worry about cert rotation, Citatel does that for you. Block all egress, and whitelist what you need? Like, that's a…

I have a hunch various cloud providers have been aware of TLS related frustrations for some time and are working on proprietary turn key products to add to their own offerings at relatively high prices.

This quietly disincentivized them to lean into any OSS stacks that will take away from this future revenue stream.

Post reply on HN