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

Don't start with microservices – monoliths are your friend

arnoldgalovics.com

Post reply on HN
Print view View original

181–190 of 468 posts

Re: Don't start with microservices – monoliths are your friend

#181

Post by hchasestevens »

wodenokoto wrote: post #146

Having worked on some cloud native/ cloud first apps, I would love to see a language or framework a long the lines of a class being a lambda/cloud function, and when calling a method of that class (it doesn’t have to be OOP, someone smarter than me must figure that out) the language itself will sort all the http requests and deployments and junk for you and your project becomes scalable, serveless services but with c…

You'd probably be interested in Unison ( www.unisonweb.org ). It's a Haskell-style functional language, which aims to make the sort of distributed computing you're talking about easy. The central conceits are:

1. Functions are hashable

2. The codebase and runtime are deployed uniformly to every node

3. Networking these nodes allows functions to be cross-referenced and passed by their hash values

Unfortunately, while the "Haskell-style functional language" part is already implemented, it's not clear to me between https://www.unisonweb.org/docs/faq#where-can-i-learn-more-ab... and https://www.unison-lang.org/articles/distributed-datasets/ whether the "make distributed computing easy" part is.

Re: Don't start with microservices – monoliths are your friend

#182

Post by pshirshov »

All true, though monoliths themselves aren't a good alternative. The real alternative is "Roles".

Here are my old slides about our DI tool for Scala, implementing Roles: https://github.com/7mind/slides/blob/master/02-roles/roles.p...

And a couple of talks: https://www.youtube.com/watch?v=o65sKWnFyk0 , https://www.youtube.com/watch?v=CzpvjkUukAs

And another post about the same approach from another prospective (monorepo vs multirepo): https://blog.7mind.io/role-based-repositories.html

Re: Don't start with microservices – monoliths are your friend

#183

Post by YetAnotherNick »

zaptheimpaler wrote: post #101
sdevonoes wrote: post #40

Earlier quoted context omitted.

> Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice. But the 15 lines of Golang are not just 15 lines of Golang in production. You need: - auth? Who can talk to your service? Perhaps ip whitelisting? - monitoring? How do you know if you service is up and running? If it's down…

lol this is how it works at a startup - 1. auth? probably an internal service, so don't expose it to the outside network. 2. monitoring? if the service is being used anywhere at all, the client will throw some sort of exception if its unreachable. memory problem? it should take 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary. rollb…

I agree more or less with 1 and 4 mostly. But for monitoring either you would have to monitor the service calling this microservice or need to have a way to detect error.

> if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts

Who keeps on monitoring like this? How frequently would you do it? In a startup there are somewhere in the range of 5 microservice of that scale per programmer and daily monitoring of each service by doing top is not feasible.

> 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary.

Your solution literally is more complex than simple jenkins or ansible script for build then kubectl rollout restart yet is lot more fragile. Anyways the point stands that you need to have a way for deployment

Re: Don't start with microservices – monoliths are your friend

#185

Post by barrkel »

Pamar wrote: post #112
barrkel wrote: post #87

Earlier quoted context omitted.

Single writer multiple readers, ideally with permissions to enforce, is a useful hybrid. Enforce going through the front door if you want side-effects. Reporting and ad-hoc data enrichment can be painful to materialize otherwise. When you have multiple bits of code responsible for writing the same columns, maintaining global invariants becomes much harder. I can still see rationale for exceptions to the rule, e.g. st…

Caveat: I am really not qualified to discuss the nuances (because I have never used microservices so the little I know is based on reading a bit on those here and on other online forums). "Single writer multiple readers", yes, this is what I would probably use, but yet again, wasn't the "promise" of Microservices being able to work in total isolation? If I have one table (e.g. "Customer") which is written by one spec…

Database schemas are generally isomorphic with RPC data structures - usually a subset one way or the other. If you had a service which handed out Zip Codes and the structure of Zip Codes changed (maybe you used numbers and now you realize you need to use strings, which I infer from your UK example) you'd have an isomorphic problem: updating 12 consumers and 1 producer for the new type in the RPC message.

Having an RPC to migrate means you can put code on the read path to support backward compatibility while migrating. But you can do the same thing with the database - support both fields until all readers have ported to the new field - and since big database migrations are expensive, in practice large systems do migrations that way anyhow. Introduce the new field, start writing to it, back-fill it, port readers across individually (there may be many read locations even within a single service), drop the old field.

If a system evolved from a monolith, one way to partition services is to provide views to limit set of visible columns. That's another point at which you can put shims for compatibility while porting schemas.

Re: Don't start with microservices – monoliths are your friend

#186

Post by dkdk8283 »

YetAnotherNick wrote: post #183
zaptheimpaler wrote: post #101

Earlier quoted context omitted.

lol this is how it works at a startup - 1. auth? probably an internal service, so don't expose it to the outside network. 2. monitoring? if the service is being used anywhere at all, the client will throw some sort of exception if its unreachable. memory problem? it should take 3. deployment? if its a go service, literally a bash script to scp over the binary and an upstart daemon to monitor/restart the binary. rollb…

I agree more or less with 1 and 4 mostly. But for monitoring either you would have to monitor the service calling this microservice or need to have a way to detect error. > if it does have memory leaks anyways, just basic cpu/mem usage monitoring on your hosts Who keeps on monitoring like this? How frequently would you do it? In a startup there are somewhere in the range of 5 microservice of that scale per programmer…

Knowing k8s makes it a lot harder - there’s nothing wrong with apps on ec2.

Re: Don't start with microservices – monoliths are your friend

#190

Post by ianbutler »

jeremyjh wrote: post #179
andy_ppp wrote: post #126

Earlier quoted context omitted.

This is one of the things I love about Elixir and OTP+The Beam that underpin it all. It's really great that you can just slowly (as is sensible) move your system over to message passing across many VMs (and machines) before you need to move to a more bespoke service oriented architecture. With Umbrella apps this can already be setup from the start and you can break off bits of your app into new distinct message-able…

Creating a lot of actors and messaging for the business logic of your application is considered an anti-pattern in Elixir, and a typical novice mistake. Applications in Elixir are structured using functions that are in modules that call other functions in other modules. Yes you can use OTP applications to isolate dependencies but none of this is done with the intent to more easily break up your app into a bunch of mi…

Right but that's not really what they're saying, they're talking about Umbrella Apps, https://elixirschool.com/en/lessons/advanced/umbrella_projec...

Which is a distinct feature made for breaking up the logic of your applications into smaller, domain bounded libraries. Umbrella apps are for the most part like regular libraries, just internal to the project which let's you do neat things like share config and deployment across them.

They don't require interacting with OTP functionality unless you make them that way and I think the OP was crossing some wires there.

Post reply on HN