I've noticed that there's another problem with microservices as well. People tend to tie microservices and multi-repo into the same strategy.

Multi-repo appears to make teams faster (builds are faster! fewer merge conflicts!) but, like micro-services, they push complexity into the ether. Things like updating service contracts, library updates, etc. all become more complicated.

I think the real sin is just cutting against the grain on your services and library boundaries.

It's not that hard to version and deploy multiple services and libraries. If you need the flexibility of that separation, it can very much be worth it.

But if you separate them and still treat them like you're in a mono whatever and you cut corners on keeping your separation clean and clear, you're going to have a bad time.

Either pattern has its advantages. It's best to remember that they're just a pattern and you should be doing one or the other for a reason.

Oddly, I would say that this often exposes complexity? Not that that is a valid reason to go all in on it. But some things, like updating service contracts, are complicated. Indeed, anything that makes it look like many services all deployed in unison is almost certainly hiding one hell of a failure case.

In my experience, while monorepo makes shared libraries between services easier, that inevitably turns into "Hey, why not just put a copy of my application inside yours?"

Having gone from multi-repo to monorepo recently, I'd say the opposite. A multi-repo lets you do those things incrementally. A monorepo forces you to do them in one go.

First thing I noticed too.

I noticed the same thing. I would have expected an Arc<Mutex<…>> or something similar for safe concurrency. Not sure what value is delivered by a single threaded, blocking web server.

This framework does thread per connection, but all requests go into a global request queue, and when you call `listen`, it enters an infinite loop which pops requests from the queue and processes them synchronously (one by one).

It sounds like this framework is susceptible to head of line blocking. In my experience, that significantly reduces the utility of any applications written choosing this framework. What’s the benefit being delivered?

No benefit, this appears to be a student's pet project. The submitter has 179k karma and they aren't this framework's author. Either the submitter is unfamiliar with Rust and mistakenly thought this is a real deal or there's some kind of karma abuse/farming going on.

This was posted by its author to /r/rust and then submitted here by someone because if a post does well over there, it often does well over here. That’s not “karma abuse”.

> This was posted by its author to /r/rust and then submitted here by someone because if a post does well over there, it often does well over here. That’s not “karma abuse”.

Except the submitter account in question is actually automating submissions from what looks like Lobsters (based on the timing and posting history). The account owner only seems to post non-automated comments to spam their product. This looks an awful lot like abuse. Or is abuse okay when you perceive it to be beneficial to Rust propaganda?

> Or is abuse okay

I just don’t care about karma that much. The first 500 is the only that matters. I find it hard to say that submitting a story that people found valuable is “abuse.”

> when you perceive it to be beneficial to Rust propaganda?

I don’t think this project has a particularly good architecture, nor do I agree with its claims about async rust. I didn’t upvote this submission.

> and then submitted here by someone

> I just don’t care about karma that much. The first 500 is the only that matters. I find it hard to say that submitting a story that people found valuable is “abuse.”

The submitting account is automated and mostly non-deterministic. Forget the fake internet points and focus on the fact that there are accounts on this site that mostly exist to spam. Isn't the value of this site that humans curate what is posted? Or is automating submissions not a form of abuse? Good to know where your ethics are.

> Isn't the value of this site that humans curate what is posted?

The value of this site is that interesting things get posted. Them being from a human is not inherently required. I do think that it's more likely to be the case when it comes from a human, but that's secondary.

Also, I would argue that upvoting is more important to curation than submission.

> Or is automating submissions not a form of abuse?

I do not believe it is inherently a form of abuse. The site guidelines do not prohibit automatic submissions, for example. If they did, then yeah, I'd say it's not a good thing to do.

Thank you for sharing this! I think your Tiltfile just showed me how to solve something that's been bugging me for a while!

I see that you also have docker-compose files -- are those for different tasks or for developer preference?

I'm also curious to understand why you have different build scripts for CI (`buildx`) vs local (regular docker build)? In our team, we use the same build processes for both.

I've always appreciated that Tilt chose Starlark instead of YAML. Makes things so much cleaner!

Well, now you've really got me interested. Almost every case of a YAML eDSL would be better served by Starlark instead, in my Bazel-brained opinion.

I think Tilt Extensions highlights the combined power and composability that using Starlarks brings to Tilt: https://docs.tilt.dev/extensions.html.

Want to create a Kubernetes secret? It's as simple as:

    load('ext://secret', 'secret_yaml_generic')
    k8s_yaml(secret_yaml_generic(...))

Want to create that secret from Vault instead?

    load('ext://vault_client', 'vault_read_secret', 'vault_set_env_vars')
    vault_set_env_vars('https://localhost:8200','mytoken')
    my_foo = vault_read_secret('path/myfoo', 'value')
    my_bar = vault_read_secret('path/mybar', 'foobar')

I think that's a fair point -- you're making a tradeoff. And the best part is that you don't need to choose one or the other.

In my case, I find that I prefer having higher fidelity and simpler service code by using Tilt to avoid mocks. It's also nice for frontend development because, using a Kubernetes ingress, you can avoid the need for things like frontend proxies, CORS and other development-only setup.

My understanding is that dev containers are more about configuring your development environment with the right toolchains to build and run services.

Tilt is a monitor process that builds and starts your services, with a hot-reload loop that rebuilds and restarts your services when the underlying code changes. The hot reload loop even works for statically compiled languages.

Yes, Tilt really shines when you’re testing interactions with Kubernetes, such a APIs. But also things like your services’ ingress configuration and metrics scraping.

By default, Tilt is actually intended for local development using kind, minikube or other similar tooling. It supports developing against a multi-node cluster but it requires extra configuration and slows down iteration time.

Tilt can also help validate things like:

- Service discovery

- Volume mounts

- Ingress and Certificates

- Metrics scraping and configuration

- Dashboards

It’s really quite powerful and replaces the need to mock things out with docker compose. If you’re deploying to Kubernetes, Tilt gives you the option to avoid “development-only” setups like docker compose.

Interesting to see this pop up here! I’ve been using Tilt for multiple years now but the pace of development seems to have slowed down after the Docker acquisition.

I love how Tilt enables creating a local development environment that lets my services run the same in production , test and development. Greatly simplifies my service code and improved my quality.

In particular, I’d love to see Tilt be better around handling things like CRDs (there’s no way to mark a k8s_yaml as depending on a CRD being available, a frequent source of broken tilt up invocations).

Having said that, the first thing I do, when working on any new project, is to get “tilt up” working.

Things I’ve used for testing include: eBPF-based collectors for security and observability, data pipelines, helm chart development, and Kubernetes controllers. It’s very flexible and powerful for a wide range of development.

Same, being able to depend on CRDs between resources would be very useful, since a lot of my Tilt usage is about making operators or working with operators.

Happy to see new releases of Tilt even if the pace has slowed down. It's a very useful tool.

As far as I understand, this might be is the best tool for the guy who acquires a SaaS and have no clue how to develop/tweak stuff. Again still have no clue how you enable this or do you still have tilt in production. Marketing is not a big deal for tilt as far as I understand.

You bring up an interesting question -- I think Tilt works best for those that find themselves in an environment where product is delivered using a service-oriented architecture deployed to Kubernetes. It's also easy to get started within a small team in a big company.

To your other point, Tilt is to development as ArgoCD is to deployment. Tilt enables on-demand, reproducible development environments that are sufficiently high-fidelity that you can often replace your shared and/or long-lived testing clusters.

With Tilt, I test my application using the same Kubernetes specs / Kustomizations / Helm Charts that you use to deploy into production. When it comes time to deploy my application, I supply these same specs / kustomizations / charts to ArgoCD.

Because I can reuse the specs for both testing and production, I enjoy far greater testability of my application, improving quality and time to market.