This phrase, slightly paraphrased, was part of what triggered me to found my startup. "I want my monolith back." It was even a slide in our first pitch deck.
So I empathize. I do get the motivation behind microservices (or other flavors of distributed system—I tend to use the microservice term a little loosely). Too many people/teams working on the same deployable eventually becomes a bottleneck for collaboration, builds and tests can take a long time for even small changes, governance and domain-separation becomes harder, and so forth. You'll also grow to have different SLOs and tolerances for different parts of your system. For example, logins should almost never fail, but background workers might slow down or fail without major fallout. Plus different services may have completely different scale/resource requirements.
Really, the question is: When do microservices become important for you (if ever)? When is it justifiable to do it presumptively, anticipating future growth? We all need to make those bets as best we can.
That said, I strongly believe that tooling can lower the baseline cost of splitting systems into microservices. That was one of our main motivations for starting garden.io—bringing the cost, complexity and experience of developing distributed backends to that level, and hopefully improving on it. We miss being able to build, test and run our service with a single command. We miss how easy it was to navigate our code in our IDE—it was all in the same graph! Our IDE could actually reason about our whole application. You didn’t have to read a README for every damn service to figure out how to build it, test it and run it—hoping that the doc was up to date. You could actually run the thing locally in most cases, and not have minikube et al. turning your laptop into a space heater.
I don’t want to plug too much here (we’ll do the Show HN thing before long), but we’re working on something relevant to the discussion. We want to provide a simple, modular way to get from a bunch of git repos to a running system, and build on that to improve the developer experience for distributed systems. With Garden, each part of your stack describes itself, and the tooling compiles those declarations into a stack graph, which is a validated DAG of all your build, test, bootstrap and deployment steps.
The lack of this sort of structure is imo a huge part of the problem with developing distributed systems. Relationships that, in monoliths, are implicit in the code itself, instead become scattered across READMEs, bash scripts, various disconnected tools, convoluted CI pipelines—and worse—people’s heads. We already know the benefits of declarative infrastructure, IaaC etc. Now it’s just a question of applying those ideas to development workflows.
With a stack graph in hand, you can really start chipping away at the cost and frustration of developing microservices, and distributed systems in general. Garden, for example, leverages the graph to act as a sort of incremental compiler for your whole system. You get a single high-level interface, a single command to build, deploy and test (in particular integration test), and it gets easier to reason about your whole stack.
Anyway. Sorry again about the plug, but I hope you find it relevant, if only at an abstract level. Garden itself is still a young project, and we’re just starting to capture some of the future possibilities of it, but I figure this is as good an opportunity as any to talk about what we’re thinking .)
So I empathize. I do get the motivation behind microservices (or other flavors of distributed system—I tend to use the microservice term a little loosely). Too many people/teams working on the same deployable eventually becomes a bottleneck for collaboration, builds and tests can take a long time for even small changes, governance and domain-separation becomes harder, and so forth. You'll also grow to have different SLOs and tolerances for different parts of your system. For example, logins should almost never fail, but background workers might slow down or fail without major fallout. Plus different services may have completely different scale/resource requirements.
Really, the question is: When do microservices become important for you (if ever)? When is it justifiable to do it presumptively, anticipating future growth? We all need to make those bets as best we can.
That said, I strongly believe that tooling can lower the baseline cost of splitting systems into microservices. That was one of our main motivations for starting garden.io—bringing the cost, complexity and experience of developing distributed backends to that level, and hopefully improving on it. We miss being able to build, test and run our service with a single command. We miss how easy it was to navigate our code in our IDE—it was all in the same graph! Our IDE could actually reason about our whole application. You didn’t have to read a README for every damn service to figure out how to build it, test it and run it—hoping that the doc was up to date. You could actually run the thing locally in most cases, and not have minikube et al. turning your laptop into a space heater.
I don’t want to plug too much here (we’ll do the Show HN thing before long), but we’re working on something relevant to the discussion. We want to provide a simple, modular way to get from a bunch of git repos to a running system, and build on that to improve the developer experience for distributed systems. With Garden, each part of your stack describes itself, and the tooling compiles those declarations into a stack graph, which is a validated DAG of all your build, test, bootstrap and deployment steps.
The lack of this sort of structure is imo a huge part of the problem with developing distributed systems. Relationships that, in monoliths, are implicit in the code itself, instead become scattered across READMEs, bash scripts, various disconnected tools, convoluted CI pipelines—and worse—people’s heads. We already know the benefits of declarative infrastructure, IaaC etc. Now it’s just a question of applying those ideas to development workflows.
With a stack graph in hand, you can really start chipping away at the cost and frustration of developing microservices, and distributed systems in general. Garden, for example, leverages the graph to act as a sort of incremental compiler for your whole system. You get a single high-level interface, a single command to build, deploy and test (in particular integration test), and it gets easier to reason about your whole stack.
Anyway. Sorry again about the plug, but I hope you find it relevant, if only at an abstract level. Garden itself is still a young project, and we’re just starting to capture some of the future possibilities of it, but I figure this is as good an opportunity as any to talk about what we’re thinking .)