High level discussion: is there a higher goal behind the micro-services bullet?

[julz]

By far the bullet I'm least happy with is the second (Monoliths over micro-services ).

The fundamental idea I think it's trying to get at is - as cloud native programmers - we want to avoid spending our lives managing infrastructure, and prefer programming languages for introducing modularity, rather than micro-services.

Microservices have a clear role when you start scaling teams up past the point where one team can own the whole code base. But when you're a 2-pizza team, splitting down further than a single micro-service is likely to add overhead (resistance to change, managing versioning, debug complexity etc) that isn't clearly warranted.

At the back of my head is the suspicion that a lot of what we're trying to achieve with micro-services is actually papering over problems with current source control and current programming languages. What's the programming language analogue of the infrastructure/deployment concept of a micro-service?

[chbrinker]

Seems to be a fair point. I remember producing some microservices just because some task was easier to do in some other language than the rest of the code. And what we were getting in the long run was new team members had to learn another/both languages. That did not made the decision bad at that time. But it came with consequences. And in the real long run was beneficial when we decided to throw away and recode that Microservice without touching the other one...

I may have a funny metaphor: Sometimes you need a hammer, sometimes you need a screwdriver. But if you collect to much tools, you end up needing a Toolbox or even a whole tool chest. A Monolith would be something like a Swiss army knife. Not really doing what you want, but helps in most situations.

Back to your language question. Maybe the analogue is frameworks and libraries. So if you use libraries you are managing the control flow directly (Monoliths). If you use a framework the control flow driven by the framework (aka the microservice network and platform your app/code lives in). You only implement the framework's interfaces (aka the APIs of the other microservices). But in difference to the framework the microservice network may not that well documented and suitable for your use case. So you end up discussing with the people implementing the interfaces. Sounds a little bit weird.

[chbrinker]

I think I produced a tl;dr 😅.

Maybe the key here is simply:

Don't overcomplicate things. Only introduce modularity where really needed. Prefer modularity in code over in infrastructure as it's easier to change and maintain.

[chbrinker]

On my way to work, I think I got it. What is adding to much Microservices in the first place? It is introducing complexity early on in a development process instead of introducing it where needed by refactoring. So maybe it is all about something like

Refactoring over early complexity

[danielbryantuk]

This bullet point caught my eye, too, and although it may currently be (linguistically) a little rough around the edges, I'm fairly sure I share the sentiment.

For me a lot of this comes down to building "right-sized applications rather than small-sized applications". I personally think that monoliths, coarse-grained services (SOA), fine-grained services (microservices), and functions (FaaS functions) all have their place, but there is a current tendency to think small is best. In reality it depends what you are optimising for: understandability, developer velocity, performance, evolvability/replacability etc, etc,

A lot of my thinking gels with what Matthew Skelton and Manuel Pais have recently written about -- a lot of higher-level architectural choices are fundamentally about managing cognitive load for engineers: https://techbeacon.com/app-dev-testing/forget-monoliths-vs-microservices-cognitive-load-what-matters (the "thinnest viable platform" idea is also super-useful, IMO)

[stevepeak]

As the founder of Storyscript, I'm coming from the position that we need a new level of abstraction for programming that utilizes the power of the cloud resources, distributed computing, serverless and microservices but in a "monolith" view.

We dub this top-level programming because super-high or ultra is sily 😉. Also, top gives you a view from the top, which is the goal of Storyscript. Abstract away the serialization and protocoling between services and empower developers to be fully polyglot with zero-devops deployments.

I strongly believe monoliths are the right way to go. But we should be asking why the industry (generally) thinks monolith and microservices are competing concepts? Storyscript is a monolith that is powered by microservices and serverless functions. Best of both worlds? Perhaps, perhaps not. But certainly worth developing and sharing our vision of the future of cloud-native programming.

[julz]

Thanks @stevepeak @danielbryantuk @chbrinker these are all really useful comments.

Trying to net some of it out: I think we suspect a lot of usage of Microservices right now is largely working around missing features in current programming languages and current source control tools, or has trade-offs that aren't always noticed. But with a high enough level language (Storyscript, dark, FaaS environments etc) such that I as a developer don't end up managing a whole set of Microservices myself I think the concern about "Microservices" might well disappear.

Tldr the problem right now may be we're solving modularity with infrastructure rather than code and therefore we're ending up doing Ops when we'd like to be able to focus on Dev. I totally buy that with the right programming language / source control tools the differentiation disappears so maybe the real value is "Code over infrastructure management" or "Programming languages over infrastructure management" or something 🤔

[stevepeak]

I believe the problem is simply observability in data-flow and focusing on what matters most business-logic.

@kelseyhightower said it flawlessly here

When you leave the monolith you loose the precious visibility in your data-flow and every business is looking to build quickly, iterate fast and deploy with ease... monolith is the way to start and adjust to microservice once you have a need. This is why these new languages could work well and click, simply because they fit both startup (prototype), scale-up (iterate/grow) and enterprise (scale) needs (generally speaking).