Hacker News Reader

Pretty sure microservices will be remembered as a horribly convoluted stop gap once we have better language modularization.

They encourage modular patterns which is usually good, but all that plumbing will eventually become unnecessary. I can’t help but remember building 6 versions of each class in the old ejb days whenever I hear microservices hype.

OSGi was supposed to solve this problem. You could start by running all bundles together in the same JVM, then split them across a cluster later if required. But it never quite took off beyond an implementation detail of various application servers.

OSGi was a horrible dev experience. Lots of quirks and legacy. Nobody wants to maintain that code anymore.

> horrible dev experience

That's an understatement. It was soul destroying awfulness.

Even with language modularisation you lose the ability to provision modules independently if they are bundled together in a single service.

Microservices and monoliths are opposing extremes on a scale. There is a range somewhere in the middle which is entirely sensible.

I feel like I've found my greatest success with my service abstractions by separating things out based on resource and availability needs of the functionality.

If you maintain the same interface (same classes, methods, types, etc) it seems to me a module ought to be hot-reloadable within the same process. This is already possible with a loosely-coupled plugin architecture and I could see it being an integrated part of a language.

Example of better language modularization? Who is working on this?

PHP, hear me out, each file is basically an independent hot swappable 'service'.

I wish more languages/compilers/runtimes had a similar capability.

Could you explain this more??

> PHP, hear me out, each file is basically an independent hot swappable 'service'.

I think that what the OP is referring to is the fact that you can map URLs to PHP files pretty easily and therefore changing what an endpoint does can be as simple as just swapping out a single file for another one.

However, that tends to fall apart with most modern frameworks, like Symfony, Laravel, Lumen and Slim, where you will typically invoke a main application file which deals with all of the bootstrapping first (reading configuration, DB connections, logging etc.) and then will hand off control over to a router, which will usually map to a controller of some sort, which may have the actual business/view logic spread over other referenced files, the way as other similar technologies like (Ruby on Rails) do it.

Of course, that's not a bad thing, especially since it allows you to follow some of the RESTful conventions, like having path variables without doing rewrites at the web server level, such as /users/12345/photos versus /users/photos.php?id=12345

That said, the whole "mostly single file, maybe with a few common imports" approach can also work fine, as long as your endpoints are kept relatively small. I haven't seen it scale up to large projects that well, at least most of the time.

Thanks for the reply!

Perhaps some idea and abstractions from Erlang could be interesting to explore in more mainstream languages?

Yeah erlang is great

Currently at my day job, we have a monolithic code base with multiple entry points. If you update a library, you have to update the client or keep the changes backwards compatible. I really prefer this over multiple micro services.

I’ve done monoliths and microservices. Having a monolithic codebase with many entry points is my preferred.

What exactly do you mean by multiple entry points? Do you have multiple processes which run independently but are co-located in the same repository or are you talking about something else?

You can have more than one Main function, just pick which one to use when you compile. In our case it’s PHP, so the API entry point uses a different index than jobs, for example. They can be deployed differently and scaled differently, but operationally it’s just deploying the same code/configuration everywhere and the only difference is routing. When you are writing code, you very, very rarely have to worry about which context you are writing for.

I have done this several times, with various small variations, and find it works well. I don't have a good name for it.

I think it's a variety of cookie-cutter scaling:

https://paulhammant.com/2011/11/29/cookie-cutter-scaling/

But there's nothing in that about using different entrypoints or routing.

FWIW, variations on the theme:

1. A single binary with a single entrypoint, which can play multiple roles simultaneously (UI, API, scheduled jobs), but where different kinds of request are routed to different pools of instances

2. A single binary with multiple embedded configurations, selecting via command line arguments etc, each for a single different role (UI, admin console, data ingestion)

3. A single (Java) binary with multiple entrypoints (main methods), each playing a different role (live calculations, batch calculations, data recording)

4. A single (C++) codebase building multiple binaries (via CMake add_executable), each playing a different role (calculating prices for potatoes, calculating prices for oranges)

5. A single repository with multiple completely separate applications, with some shared submodules, each built separately, playing a different role (receiving transactions, validating transactions, reporting transactions)

That last one is probably not an example of what you are talking about, but it's closer to the one before than to the first in the list. There is a sort of "ring species" [1] shape to this variation.

[1] https://en.wikipedia.org/wiki/Ring_species

Isn't 5 just... microservices in a monorepo?

Yes!

We've been doing this too for some "logical" services. For example, we might have a service which has a REST API and but also needs to do long running processing in response to requests via said REST API. The code for both lives in one repo and can share code, data structure definitions, databases etc. One container is made but we deploy it twice with different args. One is set to run the REST API,and the other runs the processing. Both are closely related, but in the cloud we can scale and monitor them separately. It gives a lot of the benefits of "standard" microservices with much less of the code and repo level screwing around. It relaxes the general microservices approach that: one service == one git repo == one database == one container == one deployment in GCP/etc.

I've done this before, it felt like a bit of a hack tbh, but I'm glad to hear someone else is doing it!

"What part of microservices says things must be separated by way of an arbitrary wire protocol?"

That's not a requirement, cf. Erlang/OTP.

But to qualify as a microservice, you need it decoupled enough that you can independently deploy and/or restart individual services. Pretty sure that's a minimum to call yourself microservice-based, and hard to do by just using classes in C++ or something.

Arguably you should also have quite a bit of control over dependencies and their versions. If your service isn't ready for python3, it can keep using python2, or whatever. Taking this to the extreme would generally mean a black box that serializes everything over a network, so that any service can be implemented on any stack. I'm not sure that's fundamental to the idea of microservices, though.

You could even have a mono-repo that holds services which run as separate processes, if you need that. That way you still get the benefits of sharing code, types, version numbers, build processes, etc, which seem like the main headaches with the usual approach.

We passed right by this mode of operation while migrating from microservices=>monolith. Everything is a separate process but running on the same box. Ran that way for quite some time. We pulled services into the main process one-by-one. It went about as smoothly as one could have hoped for.

I've inherited a project like this - lots of common code in a shared library that gets used by multiple services. Doesn't work too badly but things have been split out more than they need to be.

Farming out libraries or subprojects to separate teams is an ok way to go as long as you don't mind a single language/build system. Its not as flexible but you maybe get some perf out of it.

You don't get the convenience of a single datastore with simple transactions but it sounds like you prefer the flexibility of services owning their own data.

As it turns out there's no silver bullet. Do what works for you.

>> single language/build system

Imagine designing your entire architecture around your build system.

If you're a startup, I think it's actually a pretty good design constraint. You're going to end up with a single system to optimize (inevitably in your 110% time because there's no platform team) and a leg-up in shipping with fast and well-tested infra (or at least better tested because it's what you're using everywhere else). Dropping-in and tweaking stuff across many parts of the system is way easier if it's consistent, easily testable wherever you are, and you know that tests for every dependency are being run on each PR.

On the opposite extreme you're talking multiple PRs, languages, test suites and deploys for every new feature. I've watched startups do this and die before finding something people want to buy.

It's not as stupid as you make it sound. It is after all how normal manufacturing works. What you build is constrained by your assembly line. If you want to build something new, start off with redesigning your assembly line. It's time well-invested that pays back in heaps later on.

> If you want to build something new, start off with redesigning your assembly line. It's time well-invested that pays back in heaps later on.

We applied this ideology to our software project. Our build/deploy toolchain is 100% in-house code. Turns out, there's actually not a lot of it required because you can build a monster .net project into a single exe distribution with 1 simple command line operation. This applies to most other ecosystems as well. Everything else is basic file operations and moving shit between computers. No reason to vendor either of these problems out.

The benefits of having bespoke CI tooling are difficult to overstate. We've got automated processes where a project manager can multiselect 20 different customers, select a commit hash, and schedule an email containing a link to a zip of the resulting build that will be delivered to each customer's configured IT contact upon completion - all with a single button press. This process also entails injection of customer-specific configuration that is pulled at runtime from another system into each customer's distribution. The email templates are configured on a per customer basis and email delivery is delayed based upon project parameters.

I can't imagine wiring something like this up in Jenkins or GH Actions.

Sounds like the only hard part is a nice interface to select the customer IDs. You can just pass along that data to select build configs or what have you.

How is the rest of the process not applicable to GH or Jenkins?

That's exactly what i'm doing for my ( almost fulltime) side-project.

While we do Microservices at work ( distrubited team and Conway's law does make sense: https://ardalis.com/conways-law-ddd-and-microservices/ )

It doesn't make sense for me personally. So I applied all DDD logic and implemented it in my app.

In dotnet there is a useful feature where functionality from referenced projects is included in your main WebApp. Which makes everything pretty clean.

I use application logic over 2 "gateways". Where a gateway is a dummy solution that contains Swagger, global things for that project ( eg. auth verification) and uses the controllers/logic from the referenced projects.

- SPA - Angular that contains a Ocelot gateway on the same domain ( = no cors issues)

- ApiGateway - Contains all the backend api logic and custom integrations with partners.

- ShopGateway - Is included in the Frontend.

- Frontend - the shop itselve. Currently in the process of making this db-less ( everything over API / messages or using the gateway. The gateway is currently a referenced project ( see up), so everything is pretty fast)

In the meantime, i can make "reasonable" quick adjustments and the logic is really flexible.

Overview of the solution: https://ibb.co/k5wn07x

Note: Db migration from "1 project" to this is not complete yet :( . But it's one of the bigger shifts and i'm already 90% finished before i can start the actual shift to MartenDb from EF / Dapper )

If you want a quick summary on the logic behind, DDD would be the answer.

Yeah, the biggest problem that people get into with microservices is that they allow the communication structure to dictate the app structure. A monolith gives you some refactorability because you can run what would have been "integration" tests locally, as you massage your module boundaries to match the problem that you're solving. So a monolith can become a clean monolith, and then a clean monolith can maybe become microservices if you need the scale attributes.

The basic problem is that before you know where the module boundary is, you cannot have a clear module boundary. So three popular approaches emerge:

(a) DDD "milliservices". Basically define the different sorts of users, come up with a clustering of the different sorts of people that you think will be using your app. People are considered to be in the same cluster if they use the same jargon to refer to things, or different clusters if they both use some word but they both mean subtly different things by it.

(b) Gut-feeling microservices that become feature microservices. I should probably have an "auth service," I don't know what it does but I'm going to be doing auth so that's probably a service. I need to import a git library to contact GitHub, probably there should be a "git service" that handles all communication to GitHub or other git repos. Each of these things exposes some swagger/openAPI docs, maybe we should have a docs service? -- that sort of thing. The danger is that the things that are easy to break off are usually not the core competency of the product, and so there emerges some sort of "core services," one or two big honkers that basically are monoliths. People are aware that they aren't supposed to keep adding to the core services and so new services emerge named after feature requests, hello "sharing service," hello "wallet service." Except the core usually is tightly coupled to these new feature services and they all kind of connect to each other. The idea of splitting the core services into other services to fit the newfound module boundaries becomes complicated by all these ties to nearby features, you are not actually loosely coupled because you do RPCs and you probably code in the expectation of success into these RPCs like method calls.

(c) Every noun becomes a "nanoservice". This is a service that watches just one or two tables (or NoSQL document types or what have you) and exposes a CRUD API for that noun, plus a couple auxiliary verbs to do actual business needs with those nouns. So if you were implementing Git there would be a file service, a tree service, a branch service, a commit service, probably a working tree service... But you just have to "know" that logs and rebases and cherrypicks live in CommitService while diffing for some reason lives in TreeService and adding a file to your working tree requires first creating it in FileService and then handing that link off to the WorkingTreeService which will make needed calls to TreeService, creating your own tree is exposed via TreeService's CRUD but the developers tell you that down that road There Be Dragons and you should not have been messing with that.

Any of these three can be successful but only insofar as you can create new module boundaries and move module boundaries and test to make sure that your users will not notice any performance regressions. Of them I would only recommend option (a), because it gives a really nice place for these tests to live and an intuition that each test should document a user journey for the system.

A company I worked at went all in on option c - there was a random number service (that just wrapped a random number generation library), and sending an email was split across multiple services - one to pull the email request from the database, one to generate the email from the template, one to actually send the email and one to save the templated email to the database.

I’m imagining that whomever is running that company prefers to heat his home by throwing cash directly into his fireplace instead of burning wood.

How did it work out? Very curious, as such granularity of deployable units seems absurd unless it's deployed into a single runtime...

In reality it worked - each service only talked to the next so in that sense it was okay. But each service was its own binary running in its own container (someone went to a conference and heard that S3 was made up of 500 microservices, to they decided we needed as many microservices as possible). The bit where it didn't work so well was making changes and testing those changes - the original developers hacked it together then didn't want to touch it after that, so there was no dev environment (just staging environments to hijack) and no functional/e2e tests.

> Gut-feeling microservices

I'm in this comment and i don't like it.

My current team has this pattern. I think we've ended up with two core services, with a fairly thin channel between them, but a constellation of tightly-coupled peripheral services around each core.

To be honest, it works pretty well. It wasn't intentional, and it grew in exactly the haphazard way you describe. But it's not a disaster, or at least doesn't feel like one.

Maybe we should rebrand this as "natural microservices"?

"Gut-feeling microservices" is a fantastic definition, thanks for that.

> simple path of direct method invocation

Does it mean calling a method of a class?

Pretty clearly the pros and cons come down to the application and necessary stability. Need ultra stable? More and smaller microservices usually better. Need fairly stable? Bigger services is fine. Need it to work generally? Build it however you can.

> Need ultra stable? More and smaller microservices usually better.

I don't think I agree with this statement. "More and smaller" also means potentially more routing and communication paths, thus increased latency and complexity.

More smaller microservices bring along a combinatorial explosion of failure scenarios.