Lots of shallow dismissals in the comments for this and it seems to be a trend every time microservices come up.<p>"N Microservices for $BUSINESS_DOMAIN ? Crazy!"<p>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?<p><sideshow bob>Yes I realise this can also be taken as a shallow dismissal of the shallow dismissals</sideshow bob>
>> 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.<p>Lets solve this problem by introducing another level of indirection and not solving the root cause(?).<p>At this point i really believe that software architects who don't code, don't belong to this industry. If the implementers and operators are suffering, there should be a feedback channel.
Having struggled with setting up kubernetes over the last month on my own, I’ve come to realize the absolute value of simplicity.<p>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 source control.<p>My biggest take away from the k8s community is that lots of people write terrible documentation and other people write blog posts and SO answers without actually understanding how kubernetes works under the hood.<p>There is still an ocean of depth in regards to k8s I don’t know yet, but I feel a lot stronger about getting the intermediate basics. I’m at a point where I’m being productive again.
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".<p>Looking forward to upcoming parts!
This is one of those posts that brings out comments about things being over architected for the business. My mind definitely went there.<p>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.
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.<p>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.<p>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...<p>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.
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.
“Now, with our new service mesh—that only took a few months to roll out—a failure in our hello-fresh-left-pad microservice can be withstood with only a few hours of downtime” /s - Don’t go work for HelloFresh unless you hate your nights and weekends.