Live data from Hacker News

Running Istio In Production

engineering.hellofresh.com

21–30 of 47 posts

Re: Running Istio In Production

#21
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.

Re: Running Istio In Production

#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 can also be taken as a shallow dismissal of the shallow dismissals

Re: Running Istio In Production

#23
Surprisingly, it is possible to build a profitable business in this space. I looked them up and they're (very slightly) profitable. They also operate in multiple countries, which likely adds complication to their infrastructure, so it's not as ridiculous as it sounds.

Re: Running Istio In Production

#24
post #3

>> At HelloFresh we run hundreds of microservices that do everything from supply chain management and handling payments to saving customer preferences. Running microservices at scale is not without its own challenges and many companies are beginning to experience the pain of complexity. Lets solve this problem by introducing another level of indirection and not solving the root cause(?). At this point i really believ…

Indeed, it is another level of indirection, and I’m all for it (having introduced a custom service mesh based on envoy into the company I work for having ~100 microservices, though it took more like 2-3 months of me working solo). It’s a great way to get a uniform metrics and troubleshooting experience. Most important though, especially if you have strategically compiled binaries as microservices, a service mesh lets…

>> Other than that, envoy can usually withstand much more traffic than the service it overlays

services-to-service peer-to-peer communication creates problems on its own. and i dont even know what are the benefits. it does not guarantee you anything per-se. all the redundancy and bandwith improvements need to be... coded... like with any other approach.

Re: Running Istio In Production

#25

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…

[deleted]

Re: Running Istio In Production

#26

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…

>> 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 any sort of constructive feedback.

Re: Running Istio In Production

#27

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.

Re: Running Istio In Production

#28
post #6

This is one of those posts that brings out comments about things being over architected for the business. My mind definitely went there. But, at some point, companies that want to keep talented tech people need to let them go build what they want to build. Maybe those things are over-architected for what the company needs right now, but it's tough to say if that's a bigger risk than losing talented tech people.

No, that’s definitely the kind of talent you don’t want to have. Engineers too naive to realize they’ve over-engineered something are a cancer in an org. You end up with home-grown complex solutions to problems that nobody but the original team can grok.

Re: Running Istio In Production

#29
post #26

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…

>> 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 was about getting help on a linux mailing list by saying something cannot be done).

Re: Running Istio In Production

#30
I would like to read more about this, but the Part I that was linked is very, very thin on information. It's essentially just an introduction about the cloud tech in use, not anything substantial about the actual topic "running Istio in production".

Looking forward to upcoming parts!

Post reply on HN