Live data from Hacker News

Starting with microservices

arnoldgalovics.com

111–120 of 139 posts

Re: Starting with microservices

#111
post #106

Earlier quoted context omitted.

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 wh…

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!

No post body was provided.

Re: Starting with microservices

#112

Do you know what kind of software has an absurd level of horizontal scalability by default? Web servers. The idea of splitting your web servers into multi-tiered web servers for scalability is, well, weird. Yet, somehow it's the main reason people keep pushing it. Even this article repeats this. There's nothing on microservices that adds scalability. They make it convenient to deal with data partitioning, but it's an…

It seems over time some nuance has been lost in translation on this. Microservices weren't 'more scalable' than monoliths, they were 'more appropriately scalable'. In other words, you could scale parts independently and shape your infrastructure more effectively for your workload. e.g. If your bottleneck is logins, you scale the LoginService and don't need extra copies of the AppointmentService running to keep up.

Even this premise is fundamentally mistaken. If you have a monolith, and the LoginModule is overloaded, you add more hardware, and it's the LoginModule which makes use of the additional resources. The AppointmentModule isn't going to suddenly start using more resources just because they're available.

Re: Starting with microservices

#113
post #101

Earlier quoted context omitted.

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.

Re: Starting with microservices

#114
I have a different view of what microserves are and how they can be used without the overhead everyone is right to point out and hate.

In my project we do utilise microserve architecture through the serverless paradigm (i.e. bunch of lambdas) but those services are exposed directly to the client via API gateways (many of them). In essence there is very little service-to-service communication. Each service has its own data storage (s3, dynomo, etc), its own queues and topics and there is very little service inter-dependencies of any sort.

Each "micro Service" is kind of its own "micro API" if you like.

The reason I believe this is a good approach for pretty much any problem is because each component is 100% swapable, it builds on its own and frankly has little to do with the rest of the system and such erros do not have a cascading effect. These services can be moved and reused in other systems too. The responsability for using these services in some sort or orchestrated manner lies with the client and yes the client/s is heavy.

Now it is true that I cannot simply union select bunch of data. You need to except that each "micro service/API" is much like all other 3rd-party APIs and so you need to come up with your own way of pulling analytics, data consistency checks, etc. The fact that service-to-service comms are sort of banned have forced us to come up with interesting algorithms that rely heavily on solid computer science (math) principles.

Just saying

Re: Starting with microservices

#115
post #80

Earlier quoted context omitted.

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.

Re: Starting with microservices

#116
post #23

Earlier quoted context omitted.

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.

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.

Re: Starting with microservices

#117
post #42

Earlier quoted context omitted.

> Once an app reaches a certain size and anything can depend on anything else, reasoning about the whole can become difficult. I have experienced this pain so many times and in so many different varieties. Often, you cannot meaningfully subdivide the problem space without ruining the logical semantics per the business (i.e. bowl of spaghetti). An alternative is to embrace the reality that circular dependencies are ac…

I think I agree with you as well. Although it is hard for me to picture exactly how you've structured your dependency graph. In any case, extracting the business logic into some sort of static method / class has definitely been one of the only useful things I can carry across projects that works in nearly all use cases. It also makes unit testing the actual business logic extremely easy. That said, you can end up wit…

> That said, you can end up with a static method that takes 20 parameters, which is always fun.

I used to get upset about this, but now I embrace it. If a business method requires certain things to operate, then modeling those things as arguments to the method is totally reasonable. Some business is complicated and messy so we would expect more arguments to be involved. Trying to sweep reality under the rug just makes things 10x harder elsewhere.

Re: Starting with microservices

#118
post #109

Earlier quoted context omitted.

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 wh…

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 simultaneousl…

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

Re: Starting with microservices

#119
post #114

I have a different view of what microserves are and how they can be used without the overhead everyone is right to point out and hate. In my project we do utilise microserve architecture through the serverless paradigm (i.e. bunch of lambdas) but those services are exposed directly to the client via API gateways (many of them). In essence there is very little service-to-service communication. Each service has its own…

> The reason I believe this is a good approach for pretty much any problem is because each component is 100% swapable

In reality, how often will a client actually want to perform a straight swap like this, though? And that's assuming there is such a thing as a straight swap, which there almost never is.

It's a nice idea in theory but in practice it's worth very, very little.

Re: Starting with microservices

#120
post #116

Earlier quoted context omitted.

>> single language/build system Imagine designing your entire architecture around your build system.

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.

Post reply on HN