321–330 of 356 posts
Earlier quoted context omitted.
Running costs or development costs? If you have a low-request / high complexity persistent application you may want to optimize for maintainability. Having all the code in one place _can_ make things easier to figure out in the long term.
> maintainability Sir this is HN, half of the people here will quit their team well before maintainability is even uttered.
Earlier quoted context omitted.
> Monoliths can also scale horizontally At a (potentially much) bigger cost.
Could just as well be at no additional cost. If your monolith separates services somewhat cleanly then you can run them on every node and not even touch the part of the codebase that's not related to the current task.
For big companies it might me a miniscule difference, but for smaller companies it can be a deal-breaker.
I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…
Earlier quoted context omitted.
> Monoliths can also scale horizontally At a (potentially much) bigger cost.
Running costs or development costs? If you have a low-request / high complexity persistent application you may want to optimize for maintainability. Having all the code in one place _can_ make things easier to figure out in the long term.
Running costs.
> Having all the code in one place _can_ make things easier to figure out in the long term.
My experience is the exact opposite. A huge monolith makes it harder for developers - especially new ones - to get a grasp of how everything is connected. A separation of concern into micro services is sometimes a good solution.
Earlier quoted context omitted.
> Monoliths can also scale horizontally At a (potentially much) bigger cost.
You mean the few extra megabytes of RAM for some extra compiled code on each node? If you refer to databases: Splitting one service into two services can at most give you a 2x scale-up potential (usually a lot less), and the effect diminishes for 3th, 4th service. Mathematically and logically. Splitting services = vertical scaling. If you want 100x, 1000x scaling you need to invest in true horizontal scaling anyway,…
Few extra?
Have you not considered applications where you need to spin up/down _extremely_ resource intensive instances?
A year++ ago I worked on a health-related application which used a system for processing X-ray images. During typical work hour (6 am-6 pm) it required a _huge_ amount of CPU and RAM instances. By shifting those specific services out to specialised instanced, we saw a $50K/month saving.
The rest of the application is a lot more lightweight, but of course has to run 24/7, but being able to spin up/down required instances, and just pay for what you use, is a huge benefit for a lot of companies and organisations.
Earlier quoted context omitted.
> It is not true that you can incrementally modify that architecture to handle more users and traffic. One must carefully judge such things before committing to either the costs of a distributed system or the limitations of a monolithic system. I'm a little confused by this, microservices or monoliths can both be distributed systems. A monolithic architecture (eg a Rails app) still usually has a separate database. Yo…
Well, if you use a scalable SaaS like Cloud Spanner, do you then comfort yourself with the idea that you avoided microservices? Because that seems a little hard to defend on the facts.
https://en.wikipedia.org/wiki/Microservices
> A microservice architecture – a variant of the service-oriented architecture structural style – is an architectural pattern that arranges an application as a collection of loosely-coupled, fine-grained services, communicating through lightweight protocols
> A microservice is not a layer within a monolithic application (example, the web controller, or the backend-for-frontend).[8] Rather, it is a self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture. From a strategical perspective, microservice architecture essentially follows the Unix philosophy of "Do one thing and do it well".[9] Martin Fowler describes a microservices-based architecture as having the following properties:[2]
A typical monolith would use Cloud Spanner as a layer, not as a microservice.
Most people's criticism of microservices isn't about never having independently deployable services, but rather the service boundary being based on business domain decomposition, rather than essential technical characteristics. In other words, different types of storage (due to their technical characteristics, i.e. blob storage for photos vs relational database for transactional entities) being served by different services for technical reasons is eminently sensible and not something most people would have issues with and has been around for much longer than microservices. The problem is more around people deciding that for a hypothetical financial website backend that "bonds" and "stocks" should be two separate microservices, rather than just two endpoints served by the same monolith, even though they differ merely in terms of business logic and do not require any special handling from a technical perspective.
Earlier quoted context omitted.
The industry of which we speak is not in the sciences. Maybe engineering. The earliest recognition of software engineering seems to only go back to the 1980s, but there is a lot of debate as to whether it is even that. It's probably closer to gardening. Unfortunately, the industry is too new to have yet fully recognized what it is.
If software engineering is gardening for you, I think we can stop the discussion right here.
I mean, what is it about haphazardly trying out an approach you read about on a random blog written by someone who has a different problem to solve than you says engineering? In my world engineering implies rigour, adherence to the data, etc.
There can be engineering in software. There can be science in software. But I'm not sure that means software work is categorically either engineering or science. I expect you will find that there is a lot of fad chasing and leaps of faith in hopes of stumbling upon something that will yield.
To the specific topic of conversation, where do you find the science or engineering, and not just people throwing shit in their plot and seeing what grows?
Earlier quoted context omitted.
This happens a lot. Otoh, sometimes you come across cases where you wonder if you accidentally landed on a different planet. Mid sized project, 500 microservices, 800 repositories...
And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. But you know that can still happen to you, right? Even if you’re careful? The sales team promised a massive contract; the system design has to be able to hit x TPS to make it; we need to pull out the stops and build to scale for that and to allow for all this future expandability. Six months later, that sales…
The problem has always been about people deciding that different parts of the app that differ mostly in terms of business logic somehow need to be independently deployable. It's like deciding that instead of having a single database cluster and having multiple databases and tables, you need a separate, independently scalable cluster for each database table, because of some bogus reasons like some tables are queries more than others and different teams work on different tables and we can't let people join tables because it breaks boundaries or something.
Use the best tool for the job. It's stupid to think of monoliths vs microservices. You can use both if the problem requires it. For example I'm currently working on an audio hosting service. The main app is a monolith where 90% of the code resides but there are a couple of ancillary services. Audio encoding (which is heavily CPU bound) is a serverless microservice that can scale up and down as needed. Users don't upl…
Earlier quoted context omitted.
> It may be the sloppiest, crappiest definition every, with dynamic types Funny you said that since a microservice API is always dynamically typed and its usage cannot be checked by compiler. And the more microservices you use the more dynamically typed the whole project gets overall. While you can opt into a free for all everything importing everything, all languages do also support creating modules which define API…
> Funny you said that since a microservice API is always dynamically typed and its usage cannot be checked by compiler. And the more microservices you use the more dynamically typed the whole project gets overall. I mean this is just not true in the general sense. I've setup plenty of microservices with various typed APIs. Protobufs are an example of an extremely easy to implement, strongly typed, API tool. I don't t…
Thus, proto definitions become an "only add, never modify or remove" thing. Not ideal.