HN Theater @HNTheaterMonth

My favorite answer to this question: https://youtu.be/-UKEPd2ipEk

Good code follows some base set of standards, works, and can be updated/replaced/rewriten easily (simple to understand scope).

I highly recommend this topic: https://www.youtube.com/watch?v=-UKEPd2ipEk

Some reasons may be:

1. Multiple languages/tech stacks. Have something like protobufs and now any language can "import" your library instead of it just being things that can handle cffi.

2. State management. For example, redis couldn't be an in-process library. There are in-process kv stores but that's not the idea of redis.

3. Transparent monitoring for all languages. I can passively detect all retries, latencies, request counts, etc since there is a protocol.

4. Centralized fixes. Similarly to dynamic linking I can now update a single component and "fix the world" rather than redeploying every binary.

5. Canaries: I can deploy version N+1 to a mirror of production traffic and make sure it doesn't explode. Then I can route 1%, 10%, 50%, 100% of traffic and check those metrics as well.

6. If something goes horribly wrong I can rewrite the entire service for performance or maintenance or whatever within a tightly bounded amount of time. Discord has many blog posts about doing this for some of their services.

Great talk: https://www.youtube.com/watch?v=-UKEPd2ipEk

⬐ erik_seaberg

> Multiple languages/tech stacks.

This is what I'm excited about--enabling a team to use the most powerful tools that address their own problems, rather than whichever Blub is approachable enough for the entire staff.

⬐ throwawaaarrgh

But this is a problem at large scale. Each language and stack carries a variety of overhead. The more of them you have, the higher the overhead is.

Say you run a factory, and everyone needs a hammer. When there's only two teams, two kinds of hammer is fine. But fast forward to 10 teams. Can you always get all of those hammers when you need them? What if team #3 needs extra support? You need to find a new engineer who knows hammer #3, or take an engineer off of team #6 and train them on how to use hammer #3. And if all the hammers need a slight modification specific to that company, you need to make 10 different modifications. And how will all the teams benefit from shared hammer tips-n-tricks if they all use different hammers? There's a lot more overhead than you think at first.

⬐ erik_seaberg

I don’t care what brand of chainsaw I may use, but we’re going to have trouble hiring and retaining chainsaw experts if our staff is only allowed steak knives (which is what other teams are familiar with).

⬐ adjkant

It's a problem if you assume that your infrastructure needs won't scale. For many of the positives listed upthread, it can be a worthwhile trade to heavily invest in infrastructure. It just needs to be a conscious choice, and it also does more or less eliminate any small or even medium sized companies from making microservives work best. Unless you can afford to have an infra team bigger than multiple of your product feature teams, you're not at the point of needing microservices probably.

⬐ sp527

Going to play devil's advocate here and suggest that the concept of a microservice has never been that difficult to grasp.

It's a self-contained service presenting a set of related functionalities in a system having a clearly defined, documented, published interface that then becomes a dependency of other services in your system (and may itself depend on services; in the long run you end up with a DAG). It could be viewed as the most natural alternative to monolithic development and makes more sense nowadays, in a world that has better tech/standards around containerization and DevOps.

It's particularly suited to large organizations that allow for organizing teams around specific services. This also means that different teams can choose different tech stacks, depending on what's suitable and what the team has (or wants) experience using.

It's also very well-suited to async/eventually consistent functionality in evented systems. Most complex systems these days present a lot of requirements suited to this paradigm. You often see AMQs show up in relation to microservices for this reason.

You do have to worry about cascading failure when you need strong consistency and low latency responses (so make sure you build systems with sensible fallbacks and constantly test failure scenarios).

Load testing and SLAs are also good ideas with microservices. Another cool ancillary benefit to service-orientation is the ability to scale services up or down depending on load. In a monolithic system, you might end up with more waste because functionality is highly coupled. When you break things out, it becomes easier to identify where more resources are required and resources are correspondingly allocated more efficiently.

That's the high level overview imo.

⬐ matthewowen

A problem I've been thinking about recently is how you ensure that you have a DAG. Given a set of microservices that don't have a strict set of "tiering" rules, you don't necessarily know what services your dependency calls, and hence whether there is somewhere a dependency on you.

There are ways to minimize this, and certainly ways to instrument such that DAGs are detected, but I'm genuinely interested to know about how people are avoiding cyclic dependencies in their services. I think it's important, because if you're using containers, there's a good chance you're using (eg) readiness probes to determine if your containerized service can reach it's dependencies. If you have a cyclic dependency and something breaks, all of a sudden you can't bring up any containers in the cycle: A can't come up until B comes up, but B can't come up until A does.

⬐ falcolas

I'm going to disagree with one particular point - microservices are not better than monoliths. They introduce whole new layers of complexity, latency, and points of failure that no amount of tooling can overcome.

The primary reason microservices have the opportunity to shine is that they are easy to scale horizontally.

Having been repeatedly burned by microservice complexity and failures, I'm firmly of the opinion that you should do Monoliths until you can't do them anymore. If you compose your code thoughtfully and have well defined API boundaries from the beginning, it won't be that hard to start breaking it out into microservices if you find that you can no longer scale vertically.

⬐ sp527

I feel like I alluded to this, so my bad if I wasn't clear enough. Microservices are absolutely more (and perhaps only) appropriate for larger orgs dealing with serious traffic. I do also think there's an intermediary 'macroservice' concept that isn't quite several hundred services a la Netflix/Uber, but also isn't as primitive as a layer of (stateless, homogeneous) overburdened API servers with too much business logic.

⬐ twic

I don't buy the scaling argument in the slightest. You can scale a monolith more easily and more efficiently. It's called cookie cutter scaling:

http://paulhammant.com/2011/11/29/cookie-cutter-scaling/

The one performance-related thing that microservices give you is isolation. Say you are a newspaper; you render articles and handle comments. If you have one article where the comments section completely blows up, then with a monolith, requests for comment handling will eat all the CPU and I/O, and articles will render slowly for everyone. If you have separate services for articles and comments, you should be able to ensure that articles continue to get enough resources to be served smoothly.

⬐ falcolas

As with all things, it's not always that easy.

A great example I've been fighting with recently - a backend which requires a very large in-memory data graph which is unique for each user. Rebuilding this graph from the backing datastores takes between 5 and 10 seconds, but if it's in memory, responses take under 100ms.

The problem is that this monolith will be deployed in a microservice environment - stateless routers between dozens of docker hosts, each hosting multiple dozens of services, and any one of which can go up or down seemingly at whim.

Even if we were not concerned with the challenge of putting stateful applications in a stateless environment, we'd still have to worry through how to ensure that servers going down doesn't cause the entire cluster to rebalance and give everyone 10 second load times, how to route secure traffic so that users are always hitting the same servers (even across sessions), how to mitigate the data flood if the servers did catastrophically rebalance, and so forth.

So yes, theoretically, monoliths may be capable of scaling horizontally in a cookie cutter pattern. But the devil is still in the details.

Oh, and to fix your article/comments problem - just segregate off the one article to dedicated servers. Not too had a problem to solve, especially since newspaper articles are nicely routable via their URLs. Back when I worked with bare metal in colocated datacenters, it was a very popular method of handling popular customers.

⬐ cdumler

Having built many, large, scalable systems, I would like to make a finer point: I agree that microservices are not better than monoliths. I also claim that monoliths are not better than microservices.

When implementing any architecture, the are a lot of confounding issues going to in the choices, including things like: what are the skills of the team, what are the SLA expectations, what hardware resources are available, what are the comfort levels for alternatives, what is the comfort level of retooling, what are the process audit requirements, what are the maintenance costs, what is the black-bus factor, so on and so forth.

Architecture is about addressing needs, not building software in the "hey, this is the current fad, so let's do it." Although, for some companies, that is actually a design feature. "Hey, react.js developers, come here!"

I've seen microservices that fail to scale because the entire thing was written with synchronous/single-queue calls. The biggest reason for writing a microservice is the guarantee I can prove that nothing has changed. If your authorization/authentication API is separate and proved out, I can deploy my application without concern for backdoors getting (accidentally or intentionally) into the code. I always remember: "No code is easier to verify for correctness than no code."

I always cringe when I hear "kill X before it kills you" or "x is considered harmful." What will kill any project is failing to understand and appreciate the implications for the design decisions.

⬐ striking

Here's YouTube's attempt at a transcript for this talk: http://sprunge.us/MSSg

(if someone would like to clean it up, that'd be great. That someone can't be me, because I'm in class right now. If you want to find a copy of this, go to the "More" option on YouTube and pick the "Transcript" option.)

One point I could pick out was:

> I've been talking to people who want to know how they can do microservices too and like they really don't understand what it means. "It's just a word I've heard, it's good you know" and they're really smart people so we've already destroyed this concept.

⬐ carsongross

Despite the title, the talk is in favor of microservices.

I'm not convinced by the arguments (some of them seem somewhat contradictory: "Small projects succeed" v "Small is not the goal") but I would be interested in seeing the talk turned into a blog post that could be studied more closely and discussed.

⬐ Terr_

> [16:35] Maybe you should just plan to throw it away.

Definitely. To reiterate something I posted on Reddit a while back:

___

The lesson I've drawn from it is this: Design for deletion. Your first priority is to design your code for the inevitable day when your successor (or perhaps you yourself) dislikes it. The less effort/risk to uncouple and remove it, the better.

Even the most elegant work will eventually stop being relevant as the business' underlying problems change. If that's not true, then what you're working on should probably be structured as an independent library anyway.

⬐ None

None

⬐ davidw

Ok, this is why I hate videos compared to reading.

The first minute is some guy chatting about how Chad gave a talk that was 'visually horrifying' which it turns out was because it looked like a McDonalds theme.

Total waste of my time; with something written down, I could have skimmed some of the headlines in that minute, started reading, or otherwise learned something.

⬐ oridecon

Sometimes I like to consume content like it's not fast-food.

⬐ davidw

That's what's great about reading - you have the freedom to do so if you want to!

This is about a specific design pattern that some of us may have exposure to. It's not a speech for the ages as far as I can tell.

"The only thing we have to fear... is fear itself! And microservices!"

"I have nothing to offer but blood, toil, tears and sweat. Oh, and microservices. If we can get the Germans to adopt those, they're totally fucked"

⬐ Terr_

From the "department of trying way too hard", I'd like to mention that you can pull subtitle information and often massage that into a transcript, either with the DOM [0] or by looking at the traffic and downloading it. [1] However, in this case those are subtitles from speech-recognition, so it's only really useful for skimming broadly.

Pasting the whole thing would probably not be useful, but here's a sample from the downloaded XML:

> if you think about it like tiny components one of the best things about say a tiny method when you look at a tiny micro service is it allows you to consider replacing it but you can change it you can understand it really quickly but even if you can't if it's small enough and it's named well enough and it's decoupled well enough microservices tend to be you can throw it away and just restart if you have to

[0] Example: https://gist.github.com/DHager/2e01f0b82e5d3f5a39e6

[1] Look for accesses of https://www.youtube.com/api/timedtext