41–47 of 47 posts
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
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.
Edit: punctuation
Earlier quoted context omitted.
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.
Isn't that serverless, ie. AWS Lambda?
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…
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.
Obviously part of the answer is "Because I need a tech unicorn valuation". But maybe your marketing to investors shouldn't be what you're actually basing your hiring decisions on.
Earlier quoted context omitted.
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…