Kill “Microservices” Before Its Too Late by Chad Fowler

Kill “Microservices” Before Its Too Late by Chad Fowler
youtube.com

(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.

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.

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"

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.