notes-computer-programming-microservices

What's the difference between microservices and SOA (service-oriented architecture)?

In theory they seem to be the same but Fowler argues that although some see microservices as just "SOA done right" and a term attempting to distance itself from misunderstandings of SOA, because SOA means different things to different people, it's valuable to have a new term [1].

In my opinion, the denotation of the terms seem to be identical in theory, but it seems to be a practical fact that 'SOA' has acquired 'enterprise integration' connotations whereas 'microservices' has acquired a connotation of simplicity and decoupling and use in highly available customer-facing production systems.

Potential actual differences of the 'microservices' approach:

Links:

Should i use microservices on a new project?

Many say probably not:

" Almost all the successful microservice stories have started with a monolith that got too big and was broken up Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. . " -- Martin Fowler

Some say yes:

" wellpast 2 hours ago

> 1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up.

This is pure survivor bias. The majority -- by far -- of 'failure stories' I know of in the software industry are ones in which a company tried to take their monolithic code base and modularize or microservice-ize it.

> 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This is not because microservices-first is inherently flawed. This is purely a skill set issue. Microservices demand a greater skill set. A 'monolithic' approach puts much less of a demand on the engineer's skill set.

For a simplistic but illuminative example, if all you know how to do is build systems that operate on global mutable state (most newbie programmers), then of course you will run a lot further in a monolith than if you are trying to do this in a microservices pardigm.

This is a simplistic example because effective use of microservices requires much more of a skill set than not using global variables. The truth is that effective use of microservices (knowing how to build architecturally sound software) is way beyond the reach of MOST smart, senior level engineers that I've met in my career. If this sounds arrogant, it's not; there's a definitive architectural skill set that CAN BE LEARNED but that is missing from most software practitioners. (Our industry/academies need to learn how to teach it.)

This is the elephant in the room in our industry--and why we spin so many wheels talking about everything else. All of the energy we spend talking about patterns, processes, languages, etc etc do so much less for our industry than if we trained our practitioners in how to construct architecturally sound software systems.

reply " -- wellpast

Some say probably not, but maybe. [3] notes some factors that argue against microservices when they are present:

another factor mentioned by a friend arguing against microservices is:

note: even if, if the organization is considered a unitary entity, MonolithFirst? might be optimal, this might not be optimal from the POV of the careers of those in the engineering team; management might not allow sufficient time to reimplement in terms of microservices, and then might fire the initial engineering team when scaling problems are hit, instead assuming that those guys were too inexperienced and hiring a new, more experienced engineering team; i've heard this may have happened at etsy.

How to keep the microservice option open in a non-microservices architecture

Both of the above sources cited saying 'probably not' for using microservices at the beginning suggest that perhaps a good compromise would be splitting the initial app into a small number of coarse-grained parts. Newman speaks further on the challenge of keeping these parts sufficiently decoupled:

" The team are going to look at is how to make it easy to split the ruby application at a later date. When deciding later on to make an in-process module a separate microservice, you face two challenges. The first is separating the code cleanly, and creating a coarse-grained API that makes sense to be used over a network rather than the fine-grained method calls we may permit inside a single process. The other challenge though is pulling apart any shared persistent data storage to ensure our two newly separated services don't integrate on the same database. This last point is typically the biggest stumbling block. Keeping DB schemas separate for different modules

To deal with this, one of our internal development teams inside ThoughWorks? decided that it made sense to map modules which they felt could at some point in the future become services in their own right to their own data schemas, as seen above. This obviously has a cost. But by paying this cost they kept their options open - pulling the service apart at a later date becomes easier as a result. The Asterix team are going to consider using the same approach within their ruby application.

The Asterix team will need to keep a close eye on the module boundaries within the main application code base. In my experience it is easy for what starts off as clear modular boundaries to become so intermingled that future decomposition into services is very costly. But by keeping the data models completely separate in the application tier and avoiding referential integrity in the database, then separation further down the line shouldn't be hugely challenging. " -- [4]

Other things to note:

" Refactoring across the call stack is orders of magnitude easier than refactoring across a socket.

Sacrificial or not, you can still write the Monolith as "Service Oriented", just that boundary is the call stack. Especially if you're comfortable with IoC? and DI.

Building on the latter I've had success with that. Stubbing out hardcoded concepts that I know will come from a as-yet-unwritten service in the future. Then you start pushing those hardcoded things "down and out"; e.g. it was hardcoded in App A, but now App A requests it from App B, but App B just has the hardcoded thing. " -- https://news.ycombinator.com/item?id=9653693

" > Refactoring across the call stack is orders of magnitude easier than refactoring across a socket.

Yes.

> Sacrificial or not, you can still write the Monolith as "Service Oriented", just that boundary is the call stack.

Or just "modular". Obviously you should always make things as modular as you can, but at some point there are irreducible logical dependencies where increased modularity decreases cohesion more than it helps anything else.

Certainly it's a good to strive for the ideal, but at the end of the day a "service-oriented" monolith is not going to enforce the architecture the way a true SoA? will. It's sort of like Haskell's purity guarantee—you can write functional code in a lot of languages, but the benefits you reap from having a compiler's guarantee of a certain code's purity is an order of magnitude more useful than browbeating a team of cats to always follow the style guide, because no matter how good your training your "guarantee" is always subject to human error. " -- https://news.ycombinator.com/item?id=9652893

"One decision that give us confidence we will be able to split the system back out again was to use the stuartsierra/component library. By using DI we can be fairly confident we don't build dependencies we aren't aware of. We simply substitute a client that talks over the network in for the one that does the calculation locally." -- https://news.ycombinator.com/item?id=9654892

make sure "your monolithic app is stateless and using a separate persistence layer" -- https://news.ycombinator.com/item?id=9654191

---

8 Principles Of Microservices (Newman)

8 Principles Of Microservices:

some notes on some of these:

Hide Implementation Details":

decentralize all the things:

deploy independently:

consumer first:

isolate failure:

highly observable (logs, monitoring): i didn't understood this section much but:

How to do architecture across microservices

Gilt used to have an 'architecture team', but now has each team do its own architecture, and has an 'architecture board' which is a small group of engineers "whose broad purpose is to ensure the sharing of best practices, and to identify the very few standards we need to govern- mainly where technology crosses team boundaries (e.g. how software built by one team talks with software built by another team)." -- http://tech.gilt.com/post/102628539834/making-architecture-work-in-microservice

here's their governance system for the Architecture Board paraphrased from [6]:

composition:

tasks:

the Chair:

voting:

notes from Yegge's Platforms rant

" 1) All teams will henceforth expose their data and functionality through service interfaces.

2) Teams must communicate with each other through these interfaces.

3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.

4) It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.

....

A teeny tiny sampling of these discoveries included:

That's just a very small sample. There are dozens, maybe hundreds of individual learnings like these that Amazon had to discover organically. There were a lot of wacky ones around externalizing services, but not as many as you might think. Organizing into services taught teams not to trust each other in most of the same ways they're not supposed to trust external developers.

...

The Golden Rule of platforms is that you Eat Your Own Dogfood... "Start with a Platform, and Then Use it for Everything." You can't just bolt it on later.

" -- Steve Yegge

How to split an existing monolithic app into microservices

"...use a proxy to break the traffic off to a different deployment endpoint and split the code up later. This assumes your monolithic app is stateless and using a separate persistence layer, but that's just basic software design. " -- https://news.ycombinator.com/item?id=9654191

"Code velocity is the driving force for the splitting. Certain components are well understood and fairly robust other still young and poorly understood. We want to limit our ability to accidentally screw up something we have already gotten right. So the components that haven't changed in a while get spun out." -- https://news.ycombinator.com/item?id=9654892

maybe use a single repo and lockstep versioning?

" ecoffey 2 hours ago

> because each component was released and versioned separately.

For SOA a mono-repo with synchronized releases is a huge help.

In one commit you can refactor a shared module and update all apps that depend on it. And you know when you deploy to staging or prod that all machines got the latest code

reply

davexunit 2 minutes ago

Agreed. Keeping things in the same source tree is an advantage that a lot of people don't consider. It's worked very well for Linux and other large projects that have many separate components that benefit from being maintained in a single place. " -- https://news.ycombinator.com/item?id=9654232

connections to Erlang

" derefr 2 hours ago

Alternately: design your application as a bunch of Service objects with clear APIs that make (the moral equivalent of) RPC requests to one-another. Do this all in the same process. Whenever a Service turns out to need separate scaling, hoist the code for it out (no need to change it) and replace the "null modem" RPC layer between it and the rest of your code with a real socket-based gateway.

Hey! You've just invented Erlang!

reply " -- https://news.ycombinator.com/item?id=9653777

Links

possibly related software tools?:

api server frameworks?:

deployment frameworks?: