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

611–620 of 671 posts

Re: Modules, not microservices

#611

Post by vinay_ys »

FpUser wrote: post #503
Xeoncross wrote: post #412

Earlier quoted context omitted.

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.

This is exactly what I do. When it comes to your regular backend business server I write stateful multithreaded monolith in C++ sitting on the same computer as the database hosted on some multicore server with gobbles of RAM (those are cheap now). Performance is insane and is enough to serve any normal business for years or decades to come. So it does not work for FAANG companies but what do I care. I have the rest o…

Even for non-FAANG, less-than-a-million-user business applications, there are two problems: 1. Your feature/function scope is not all fully defined at the start and is not static till the end of life. Software has to evolve with business. In this case, it is easier to build a loosely coupled shared nothing architecture that can scale easily than to build a shared-everything-all-in-one-binary monolith architecture. 2. Your customer base isn't one size fits all. You usually different growing businesses that need solution at different scale points but still with very high unit economics. This means you need a incremental scaling solution – this is where old-school big-chassis systems build blade scalable server architectures. But because of custom/proprietary backplane design they become unmanageably complex and buggy.

Instead, if you build an architecture that can scale the number of corporate users by adding cheap $2k pizza box 1u servers as the company grows, that's much more attractive. Also, you can keep your systems design flexible enough to recompile and take advantage of advancements in hardware tech every 18 months – this gives you better operating margins as your own business starts to grow.

Re: Modules, not microservices

#612

Post by tail_exchange »

Sohcahtoa82 wrote: post #413
tail_exchange wrote: post #358

I don't think microservices are the answer to everything, but I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. Monoliths are way slower to deploy than microservices, and when you have hundreds or thousands of changes going out every day, this means lots of changes being bundled together in the same deployment, and as a consequence, lots of bugs. Havin…

> I don't see how monoliths can keep up with developer velocity when an organization reaches thousands of developers. Are those thousands of developers working on a single product? If so, then I'd argue that you have way too many developers. At that point, you'd need so many layers of management that the overall vision of what the product is gets lost.

Not necessarily. But if the solution in this case is to start breaking up the monolith into smaller services owned by specific product teams, then you are moving towards microservices.

Re: Modules, not microservices

#613

Post by hutzlibu »

cogman10 wrote: post #492
mirekrusin wrote: post #459

Earlier quoted context omitted.

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 (hea…

> It sounds like creating problem, then spending time=money on fixing it and calling it a win? It sort of is. It's not a perfect world. One issue with monoliths is that, organizations like to take a "if it ain't broke, don't fix it" attitude towards things. Unfortunately, that leads to spotty service and sometimes expensive deployments. Those aren't always seen as being "broken" but just temporary problems that if yo…

"It's simply hard for a manager to see those improvements as being worth it over the status quo"

That often is, because new solitions tend to come with their own problems.

Re: Modules, not microservices

#614

Post by vbezhenar »

unity1001 wrote: post #530
vbezhenar wrote: post #501

Earlier quoted context omitted.

What if I have $500/month to spend and still need high reliability and redundancy?

Go to Digitalocean or a similar provider. Launch a managed HA db. (starts at ~$120/month). Launch an autoscaling HA K8 cluster (starts from ~$80) , deploy 1-2 stateless pods. There you go.

That's what I do. But it's not IBM.

Re: Modules, not microservices

#615

Post by Pamar »

ReflectedImage wrote: post #604
Pamar wrote: post #393

Earlier quoted context omitted.

You are absolutely right: you do not know much about cruises. The things you listed are ... 4-5 different applications , mostly running directly on the ship(s) and what is conspicuously missing are the parts that are managed shoreside, like: Itinerary planning (your product is one or more cruises: therefore you need to preplan the itineraries, which ships to use, when you will enter each port and when you will leave…

"4-5 different websites" No, no, no. Those are internal APIs. You still only present one website to the end user.

Sorry, you misunderstood.

When you book a cruise, your expectation is to get everything (including hotel stays before or after the cruise, along with flights to and from it) as a single package provided by the cruise vendor (or a travel agency). So the "reservation system" must take care of all of that.

When I said "4-5 different websites" I was trying to explain the point that a 60 yo high-income guy is usually not interested in getting the cruise itself on Carnival.com, then go look for excursions on CarribeansExcursion.net and to book flights on Lufthansa.de or AirFrance.fr.

It was a remark on the way the Cruise business works, and why it is so, not about architecture.

(But, once again, I really believe that we are way off topic... personally I do not really feel like creating a "Ask HN: are microservices a good choice for the cruise industry?" but if someone feels like submitting one I will try to contribute).

Re: Modules, not microservices

#616

Post by thrwawai39f3 »

Karrot_Kream wrote: post #583
noogle wrote: post #569

Earlier quoted context omitted.

That makes sense. I am still trying to understand why does it differ between a monolith and microservices. The app in the monolith can make the call to non-critical functionalities time-limited and fault-tolerant, just like a network call has a time-out and can return nothing (in a simplified manner, it can wrap that call with a timer and an exception handler). I agree that microservices are suitable for large organi…

If your monolithic service OOMs, hits a large GC pause causing dependent requests to time out, locks a shared file descriptor, or a bunch of other things then the monolithic service as a whole can hit a fault or stall even if other threads/tasks are still executing. While classes of errors like OOMs go away when multiple processes are executing.

A monolith can also scale vertically with mechanisms to redeploy on fatal errors. If all starts failing, you may have a problem. But you can get the same problems with a microservices that is in the critical path

Networks could have unexpected delays, routing errors and other glitches. At least with a monolith you can often find a stacktrace for debugging. I have seen startups that have limited traceability and logging when using micro services.

When a small startup has to manage "scalable" K8s infrastructure in the cloud, distributed tracing and monitoring is often not prioritized when you are a team of 5 developers trying to find a product market fit.

I am not against microservices (I work with them daily) but you just trade one type of stability problem with another

Re: Modules, not microservices

#617

Post by jcmontx »

LeZuse wrote: post #601

There are so many misconceptions about what microservices are or what problems they are trying to solve. Most people don't even experience the problems (yet or ever) they are meant to solve and they go straight to micro. 5 person teams making 5 services to power their product :faceplam:. A relatively simple b2b web application without any serious traffic also does not need microservices to handle its load. People jus…

> Boring tech club ftw

As a CTO, I couldn't agree more. For our internal product, we use 100% boring technologies. The most "modern" you'll find is a React SPA.

I sigh when clients want to go the microservices route for a team of just a few developers. When you want to use NextJs for their tables&forms app. When they choose to use Kubernates instead of a couple EC2 instances.

Don't get me wrong, these technologies are great for us because we can charge more for the wasted human time developing these overengineered solutions. But I always, for my peace of mind, try to talk them out of them. Sometimes works, sometimes doesn't, at the end of the day it's their money.

Re: Modules, not microservices

#618

Post by Pet_Ant »

jacobr1 wrote: post #279
pjmlp wrote: post #235

Earlier quoted context omitted.

There is no independently in distributed systems.

But there are rules of blame. With microservices, as long as you maintain the contract with caller services, you can deploy whenever you want. If you have some kind of issue, your team is solely responsible. If the caller services do weird things, they are responsible for fixing them. If you are pushing changes to a module as part of a more monolithic, or wrapper service - if you do a deploy and break the whole big s…

Every organisation I've worked at that had microservices has had all of them released every other Thursday at the same time by the same pipeline because they are tied to the organisation scrum schedule. Also, most changes are part of epics that span multiple microservices. If you are gonna argue that properly done microservices don't have that problem you are free to practice your perfect microservices alongside perfect scrum, oop, and communism.

Re: Modules, not microservices

#619

Post by scottmas »

rlt wrote: post #590
barrkel wrote: post #72

Microservices, while often sold as solving a technical problem, usually actually solve for a human problem in scaling up an organization. There's two technical problems that microservices purport to solve: modularization (separation of concerns, hiding implementation, document interface and all that good stuff) and scalability (being able to increase the amount of compute, memory and IO to the specific modules that n…

I’d love for a language / framework that allows for an application to be composed of “modules” that can either be run in a single process, or deployed as multiple independently scalable processes, with a mostly transparent RPC system requiring minimal boilerplate. My IDE should be able to easily traverse the call graph. My development environment should be simple to setup. I’ve worked on microservices that required a…

Hey, we have a system like that at my company. Microservices are self contained and responsible for exposing their interface via SDKs created with a tRPC like library. Jump to definition works across the entire monorepo like a charm. Could you take a look and give me any feedback? https://github.com/rectech-holdings/umbrella-corp-boilerplat...

Re: Modules, not microservices

#620

Post by JAlexoid »

thayne wrote: post #572
JAlexoid wrote: post #541

Earlier quoted context omitted.

The same techniques used to restrict intrusion, can be applied to a monolith. Microservices aren't inherently more secure.

Really? How do you make it so that different modules in the same process have different IAM credentials and can't get the credentials for a different module? How do you make sure a buffer overflow in you analytics module doesn't allow an attacker to read memory from you login module? How do you make sure an RCE in your image upload code doesn't give an attacker access to credentials for your payment processor? Maybe…

Giving me an example that is created to work explicitly at system/container level isn't the "gotcha" you think it is.(IAM profiles have their own limitations)

Separate process vaults, HSMs and other techniques of offloading security credentials - are the same for microservice architecture, as "monolith".

The implication that anything other than a microservice architecture must be exclusively an uber executable doing literally everything, is naive.

Post reply on HN