Goodbye Microservices: From 100s of problem children to 1 superstar • Hacker News Board

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#141

Post by rifung » Tue, Jul 10, 2018, 6:21 PM UTC

dualogy wrote: post #62

golergka wrote: post #48

Earlier quoted context omitted.

> Too many smart folks that I've worked with, for some reason, just stop thinking critically when it comes to certain ideas. Because doing something new is much more fun that doing something effective. And most software developers don't really get into this job out of doing things effectively - we're get into it out of the sheer fun of it, altough we would never admit it to our bosses and often even to ourselves.

> Because doing something new is much more fun that doing something effective Trouble is, "fun" for the enthusiast / self-perceived-non-workdrone does align with "productive". =)

Why do you say that?

My initial reaction is that it should be the opposite: people who are enthusiasts would want to learn something new because they enjoy using and learning technology, whereas a "workdrone" would focus on being productive because they are focused on work.

I'm not saying you're wrong or that there's anything wrong with either mentality, I just don't find your statement self explanatory. Please do elaborate =]

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#142

Post by scarface74 » Tue, Jul 10, 2018, 6:22 PM UTC

ivan_gammel wrote: post #137

scarface74 wrote: post #81

Earlier quoted context omitted.

Mocking modules for unit testing has been a solved problem for decades in almost every language.

Mocking modules for unit testing - yes. Testing the specific build artifact with a module replaced by a mock - no, it is not.

A dependency injection framework where you use flags at the composition root to determine whether the “real” implementation class or the mock class is used based on the environment.

IOrderService -> OrderService in production.

IOrderService ->FakeOrderService when testing.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#143

Post by VBprogrammer » Tue, Jul 10, 2018, 6:22 PM UTC

kolpa wrote: post #113

thermodynthrway wrote: post #98

Earlier quoted context omitted.

With web apps the main concern is data consistency between relations. On the OS level you have these same concerns with memory and disk, and there's database-like systems in the kernel and drivers to handle it. Essentially all these utilities are running within the same "database" which is disk and memory management handled by the kernel. Usually microservices have their own databases, which is where consistency hell…

> Usually microservices have their own databases That's news to me, and seems insane. Unless you mean "their own database tables", not "database servers". But that's just the same as having multiple directories and files in a Unix filesystem.

That architecture is commonly known as a distributed monolith. If you put two services on the same DB you can guarantee that someone will be joining onto a table they shouldn't have before the week is out.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#144

Post by dbt00 » Tue, Jul 10, 2018, 6:23 PM UTC

Reading this post-mortem was very useful, and I appreciate the segment engineering team sharing it.

It seems like the primary problem causes were flaky/unreliable tests, and difficulty making coordinated changes across many small repositories.

Having worked on similar projects before (and currently), with a small team driving microservices oriented projects, I would probably recommend:

1) single repository to allow easy coordinated changes.

2) a build system that only runs tests that are downstream of the change you made (Bazel is my favorite here, but others exist). This means all services use the HEAD version of libraries, and you find out if a library change broke one of the services you didn't think about. This also allows for faster performance.

3) Emphasis on making tests reliable. Mock out external services, or if you must reach out to dependencies use conditional test execution, like golang's Skip or junit's Assume if you can't verify a working connection.

If you still can't build a reliable service with those choices, then it's time to think about changing the architecture.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#145

Post by ivan_gammel » Tue, Jul 10, 2018, 6:23 PM UTC

jrs95 wrote: post #91

scarface74 wrote: post #81

Earlier quoted context omitted.

Mocking modules for unit testing has been a solved problem for decades in almost every language.

And running an integration test on a single modular application is easy . Doing it for a distributed system is very hard .

Running E2E blackbox test is equally simple for all kinds of architectures, especially today, when it's so easy to create a clean test environment with multiple containers even on developer's machine. It may be harder to automate this process for a distributed system, but, frankly speaking, I don't see a big difference between a docker-compose file or a launch script for monolith - I've been writing such tests for distributed systems casually for several years and from my personal experience it's much easier to process the test output and debug the microservices than monolithic applications.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#146

Post by [deleted] » Tue, Jul 10, 2018, 6:25 PM UTC

blablabla123 wrote: post #106

NickBusey wrote: post #72

Earlier quoted context omitted.

Right, but the thing that makes Linux actually useful isn't really the kernel is it? I would say what makes it useful is all the various small, targeted programs (some might call them microservices) it lets you interact with to solve real world problems. If Linux tried to be an entire computing system all in one code base, (sed, vim, grep, top, etc., etc.) what do you think that would look like code base/maintainabil…

But there is a big difference. These small targeted programs are invoked in user land, usually by the user. Microservices get invoked directly by the user when debugging is going on. Otherwise they are expected to automagically talk to each other and depending on the abstraction even discovery each other automatically. Also I can pipe these tools together from the same terminal session, like tail -f foo | grep someth…

[deleted]

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#147

Post by fipple » Tue, Jul 10, 2018, 6:26 PM UTC

iamleppert wrote: post #75

Microservices are an organizational and design choice that is intended to mirror the structure of the teams or engineers, the actual human beings doing this stuff. It seems like Segment didn’t really understand this at all, and instead decided to have seemingly arbitrary and rediculous service boundaries that had no relationship to the real world. See also people who create poor abstractions in their code and other s…

Yes, this awful engineering team built an incredibly successful company/product. I wish I was as awful as them.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#148

Post by _ea1k » Tue, Jul 10, 2018, 6:26 PM UTC

kolpa wrote: post #113

thermodynthrway wrote: post #98

Earlier quoted context omitted.

With web apps the main concern is data consistency between relations. On the OS level you have these same concerns with memory and disk, and there's database-like systems in the kernel and drivers to handle it. Essentially all these utilities are running within the same "database" which is disk and memory management handled by the kernel. Usually microservices have their own databases, which is where consistency hell…

> Usually microservices have their own databases That's news to me, and seems insane. Unless you mean "their own database tables", not "database servers". But that's just the same as having multiple directories and files in a Unix filesystem.

To be blunt, its news to a lot of people, but it also isn't wrong. Microservices really shouldn't share a database, and if they do then they aren't "microservices".

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#149

Post by erik_seaberg » Tue, Jul 10, 2018, 6:26 PM UTC

kolpa wrote: post #113

thermodynthrway wrote: post #98

Earlier quoted context omitted.

With web apps the main concern is data consistency between relations. On the OS level you have these same concerns with memory and disk, and there's database-like systems in the kernel and drivers to handle it. Essentially all these utilities are running within the same "database" which is disk and memory management handled by the kernel. Usually microservices have their own databases, which is where consistency hell…

> Usually microservices have their own databases That's news to me, and seems insane. Unless you mean "their own database tables", not "database servers". But that's just the same as having multiple directories and files in a Unix filesystem.

If you're going to go microservices, you want service A to use service B's public API (MQ or RPC or whatever), not to quietly depend on the schema B happened to choose. And sharing a database server instance turns overloads into cascading failures, unless the stack is very good at enforcing resource limits on noisy neighbors.

Re: Goodbye Microservices: From 100s of problem children to 1 superstar

#150

Post by ben509 » Tue, Jul 10, 2018, 6:27 PM UTC

A number of comments touched on this, that microservices are also an organizational strategy: you have a team that manages that particular service.

My company is probably typical in that we implicitly use microservices because we have consume dozens of microservices provided by other companies.

We only have a handful of services we maintain, each with dedicated engineers.

And what becomes a service? You want to answer two questions:

1. Does it have a concrete business justification? 2. Does it have clear functional requirements?

If it has a business justification, it will get people assigned to keeping it running. If it has clear functional requirements, it will make sense to the people working on it which service does what.

That's still pretty vague, so you want to look at who has done it well, and why it worked for them.

Companies like AWS have been extremely successful in using microservices because every last one service has a business rationale, it's either directly making money (EC2, S3, SQS) or it supports the needs of customers who are using a service that makes money (VPC, Cloudformation, all their internal auth, billing, provisioning, security and such).

The caveat there is that the big B2B service providers are not a great model for companies that have a lot of business logic.