Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modules, not microservices

blogs.newardassociates.com

Post reply on HN
Print view View original

451–460 of 671 posts

Re: Modules, not microservices

#451

Post by osigurdson »

hbrn wrote: post #287
osigurdson wrote: post #118

Earlier quoted context omitted.

The right answer is 20 files with 500 lines in each - i.e. few pages of clean/ readable/logical/well-factored code. Obviously it depends on the code itself - it's is fine to have longer files if highly correlated. Stateful classes should be kept short however as the cognitive load is very high. I also find that updating code to take advantage of new/better language features / coding styles, etc. is impossible to do o…

The right answer is that there is no right answer. You shouldn't divide your code based on arbitrary metric like size, you should divide it based on concepts/domains. If a particular domain gets big enough it probably means it contains sub-domains and can benefit from being divided too. But you cannot make that decision based on size alone.

Sure but no problem domain is not going to lead you to 10,000 single line files. Similarly it will likely lead to very few 10K line files. There will likely be a way to factor things into reasonable sized chunks. File sizes are not going to be that highly coupled to problem domain as there are multiple ways to solve the same problem.

Re: Modules, not microservices

#452

Post by danielovichdk »

I have done a lot of service development for what would be called microservices.

The article gets it right in ny opinion.

1. It has a lot to do with organisational constraints.

2. It has a lot to do with service boundaries. If services are chatty they should be coupled.

3. What a service does must be specified in regards to which data it takes in and what data it outputs. This data can and should be events.

4. Services should rely and work together based on messaging in terms of queues, topics, streams etc.

5. Services are often data enrichment services where one service enrich some data based on an event/data.

6. You never test more than one service at a time.

7. Services should not share code which is vibrant or short lived in terms of being updated frequently.

8. Conquer and divide. Start by developing a small monolith for what you expect could be multiple service. Then divide the code. And divide it so each coming service own its own implementation as per not sharing code between them.

9. IaaS is important. You should be able to push deploy and a service is setup with all of its infrastructure dependencies.

10. Domain boundaries are important. Structure teams around them based in a certain capability. E.g. Customers, Bookings, Invoicing. Each team owns a capability and its underlying services.

11. Make it possible for other teams to read all your data. They might need it for something they are solving.

12. Don't use kubernetes or any other orchestra unless you can't it what you want with cloud provider paas. Kubernetes is a beast and will put you to the test.

13. Services will not solve your problems if you do not understand how things communicate, fail and recovers.

14. Everything is eventually consistent. The mindset around that will take time to cope with.

A lot more...

Re: Modules, not microservices

#453

Post by jerf »

zbobet2012 wrote: post #402
jerf wrote: post #202

Earlier quoted context omitted.

"This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components." Conway's Law is basically "You don't have a choice." You will cement the design of your app around your organizational design. (At least, beyond a certain org size. If you have only 4 engineers you don't really have the sort of structure in question here at all.) je42 n…

I mentioned this elsewhere, but I think it's a good idea to read the actual text of conways law: > Any organization that designs a system (defined broadly) will produce _a design whose structure is a copy of the organization's communication structure_. Organization is the primary method by which we organize communication (indeed, that's its only point). That's why architecture follows organization. It is possible to…

This is the "reverse Conway's law" that some others are referring to, and I alluded to. I've had success doing it in small places here and there. I'm yet to convince a management organization to do a really large-scale reorg because of some major pathology, though. Though I haven't tried often, either. Really just once. The costs are automatically so high for such a proposal that it is difficult for mere engineering needs to get to net-positive because it's hard to prove the benefits.

Re: Modules, not microservices

#454

Post by ladyattis »

I think microservices are fine for businesses which have a general idea of how 'big' things could get with respect to their platforms. But if you're more in a company that has many one-off programs, scripts, and the like then maybe microservices aren't a thing that you need. Better organization is good, but that shouldn't be just a microservices thing, everyone benefits when you've organized not just individual projects and their source code but also just organizing what does what with external documents that can be updated to explain their purpose is useful. There's nothing worse than looking at source code or an program by name only to ask, "what is this thing?"

Re: Modules, not microservices

#455

Post by omginternets »

c-fe wrote: post #73

I am working on a project that uses a microservice architecture to make the individual components scalable and separate the concerns. However one of the unexpected consequences is that we are now doing a lot of network calls between these microservices, and this has actually become the main speed bottleneck for our program, especially since some of these services are not even in the same data center. We are now attem…

Unexpected?!

Either way, one of my biggest pet peeves is the near-ubiquitous use of HTTP & JSON in microservice architectures. There's always going to be overhead in networked servies, but this is a place where binary protocols (especially ones like Cap'n Proto) really shine.

Re: Modules, not microservices

#456

Post by NorwegianDude »

Xeoncross wrote: post #412
locutous wrote: post #404

Earlier quoted context omitted.

> Servers can only get so big. If your monolith needs more resources than a single server can provide, then you can chop it up into microservices 200 threads, 12TB of RAM, with a pipe upwards of 200GB/s. This isn't even as big as you can go, this is a reasonable off the shelf item. If your service doesn't need more than this, maybe don't break it up. :) I believe that this level of service can no longer accurately be…

Helps to have a language that natively uses more CPU cores and/or training for the devs. Ruby, Python, PHP and Node.js startups have to figure out how to use the cores while C++, Rust, Erlang and Go have no issues running a single process that maxes out all 64 CPU cores.

Doesn't really matter that much if a language is using all cores from one process or if there is multiple processes.

Re: Modules, not microservices

#457

Post by game_the0ry »

I am a front end dev, so microservice architecture is not something I am super familiar with my day-to-day, but I occasionally do work in our back end project, which is a service-oriented java project. The project is broken down into different services, but they are aggregated in "parent" projects, where the parent declares the modules in the pom.xml (in the "modules" xml declaration).

I like that architecture - the services are abstracted with clearly defined boundaries and they are easy to navigate / discover. Not sure if Java modules satisfy the concerns of the author or other HN users, but I liked it.

Re: Modules, not microservices

#458

Post by jerf »

lightbendover wrote: post #231
jerf wrote: post #202

Earlier quoted context omitted.

"This has been my major criticism of them; you cement the design of the app by creating an organizational structure around your software components." Conway's Law is basically "You don't have a choice." You will cement the design of your app around your organizational design. (At least, beyond a certain org size. If you have only 4 engineers you don't really have the sort of structure in question here at all.) je42 n…

Part of the issue is that not everyone understands the trade-offs or perhaps believes the trade-offs so you get teams/leaders haphazardly ignoring expert guidance and crafting careless micro-services around team boundaries that do not line up with value.

I find the responsibility & authority angle is very helpful in these conversations. It doesn't take a lot of convincing (in a reasonably healthy organization) to say that these should be broadly aligned, and that if you can show people a place where they are either currently grossly out of sync, or are going to be out of sync if we move forward with some particular iteration of the plan, they start thinking more about how to bring them in sync.

The good news is, pretty much everyone has been on at least one side of that balance being broken (that is, having responsibility without authority, or being subject to someone else's authority without responsibility), and a lot of people have been on both, and once you bring it to their attention that they're creating another one there is a certain amount of motivation to avoid it, even if it is a bit more work for a them. You can actually use people's experiences with bad organization to convince them to not create another one, if you are careful and thoughtful.

Re: Modules, not microservices

#459

Post by mirekrusin »

cogman10 wrote: post #381
dahfizz wrote: post #366

Earlier quoted context omitted.

Microservices are less efficient , but are still more scalable . Servers can only get so big. If your monolith needs more resources than a single server can provide, then you can chop it up into microservices and each microservice can get its own beefy server. Then you can put a load balancer in front of a microservice and run it on N beefy servers. But this only matters at Facebook scale. I think most devs would be…

You know, I don't really think microservices are fundamentally more scalable. Rather, they expose scaling issues more readily. When you have a giant monolith with the "load the world" endpoint, it can be tricky to pinpoint the the "load the world" endpoint (or, as is often the case, endpoint*s*) is what's causing issues. Instead, everyone just tends to think of it as "the x app having problems." When you bust the mon…

It sounds like creating problem, then spending time=money on fixing it and calling it a win?

There is a point when it all starts to make sense. But that point is when you go into billions worth business, hundreds of devs etc. And going there has large cost, especially for small/medium systems. And that cost is not one off - it's a day-to-day cost of introducing changes. It's orders of magnitude chaper and faster (head cound wise) to do changes in ie. single versioned monorepo where everything is deployed at once, as single working, tested, migrated version than doing progressive releases for each piece keeping it all backward compatible at micro level. Again - it does make sense at scale (hundreds of devs kind of scale), but saying your 5 devs team moves faster because they can work on 120 micoservices independently is complete nonsense.

In other words micoservices make sense when you don't really have other options, you have to do it, it's not good start-with default at all; and frankly Sam Newman says it in "Building Microservices" and so do people who know what they're talking about. For some reason juniors want to start there and look at anything non-microservice as legacy.

Re: Modules, not microservices

#460

Post by whiplash451 »

therealdrag0 wrote: post #342
gunnarmorling wrote: post #169

I really like modular designs, but this article is missing some key limitations of monolithic applications, also if they are really well modularized (this is written mostly from the perspective of a Java developer): * they force alignment on one language or at least runtime * they force alignment of dependencies and their versions (yes, you can have different versions e.g. via Java classloaders, but that's getting tr…

I used to be monolith-curious, but what sold me on micro-services is the distribution of risk. When you work for a company where uptime matters having a regression that takes down everything is not acceptable. Simply using separate services greatly reduces the chances of a full outage and justifies all other overhead.

Why would using microservices reduce the chance of outages? If you break a microservice that is vital for the system, you are as screwed as with a monolyth.
Post reply on HN