
Avoiding the Distributed Monolith - jetheredge
https://www.simplethread.com/youre-not-actually-building-microservices/
======
dkoston
Not sure why a contract development shop is putting stuff like this on their
blog. Perhaps they have small clients asking for microservices when
unnecessary?

Agree that this headline is presumptive and so is the article. Not every piece
of engineering is a "slap it together in 3 weeks" build and many systems are
designed with independent parts that use different technologies and scale at
different rates.

I think what the author was trying to say is: "If you don't have enough
experience to derive an architecture that isn't just some battle of buzz words
or copying off blogs posts, you're in for a crude awakening when you have to
maintain, scale, and refactor your work. Also, creating and maintaining a
continuous delivery architecture with tons of moving parts is a lot of work".

At large companies (and small) devops, engineers, architects, CTOs, and many
other players collaborate to develop an architecture which evolves over time
and includes legacy systems, greenfield projects, duct tape, off-the-shelf
bits, vendor-specific bits, open source bits, and other concerns that all have
to work together. These organizations already have massive teams (or small and
really good teams) taking care of making sure everything works together.

If you have a small team, little funding, and/or little experience you are
probably getting in over your head trying to architect and orchestrate tons of
moving pieces. It really depends on what you are building, your budget, and
your team as to how you should build. Some industries and products require
complexity, scale, and proper function from the beginning while others are
accepting of bugs, scaling issues, and long delays.

TLDR: There's not a simple playbook that defines how everything should be
engineered. Also, don't read some poorly written blog post which provides zero
insight on the complexities of approaching an engineering challenge and decide
to choose X or Y approach.

~~~
zer00eyz
> Not sure why a contract development shop is putting stuff like this on their
> blog.

Content marketing - it is a thing and this is how it is done. If were reading
it so is some decision maker. It only has to "look right" to someone with a
minimal set of information in order for it to make the publisher look like an
"expiator"

~~~
bigiain
Another possibility - many startup/product companies self-fund by doing
contract dev work. It could easily be learnings from their in-house product
dev rather than just brazen content marketing...

~~~
nikanj
I wonder how many of the consulting giants got started accidentally. "We did a
contract, then another, then we had built up a team and reputation and really
didn't see a point in doing our product anymore"

------
toss1
TFA has some excellent lists to test whether you're just building a
distributed monolith or actual separate microservices.

The key that was not mentioned was the interfaces. In my experience, the key
is to carefully define the functions and scope of each separate component,
then do a lot of up-front work building a clean interface for sending data
and/or messages between the components.

Once this is done, the team on Componnt A should be able to make, rollout,
and/or move to different hardware, and/or add/subtract hardware at will
without the team on component B even noticing. All teams should be able to
keep their paws 100% out of each others' code and data structures.

Then, you have independent components that can actually be immediately scaled
to meet unexpected load changes by throwing HW at them, thus buying time to
streamline the code. You also have a structure that you can upgrade and
maintain with much greater freedom.

Without the clean and stable interfaces, he's right, you have only a
distributed monolith.

I'd recommend starting the first version with a quick-to-build near-monolith
throw-away, get some experience with the actual data flow, then decide on the
actual components and interfaces.

~~~
Traubenfuchs
Googling "TFA microservice monolith list" leads to your post. Where are the
lists? (-;

~~~
toss1
In the original article linked above to which this is a comment("TFA" = "The
Fine Article"), first one about a page down

------
sebringj
Just noting this as I have some successful use cases of microservices as it
may help others. What I mean by successful is I have reused them in many
projects without having to modify them for each project, meaning they stood
alone with only needing some config items to add one or more clients.

1) Authentication - JWT and OAuth provider related, can be used with multiple
clients or installed per client 2) Pre signing of S3 uploads (very tiny file
to do this one) 3) Ecommerce api w / shipping using fedex and stripe 4)
Plugable CMS with JS dropped on a page used for UI and auth and S3 used as
content store with an API sitting in between

I guess some of them could be considered just an API? But if you can reuse it
generally and the scope is fairly narrow, that is more of what a microservice
should be. There is also the tradeoff where you may be thinking if this is so
tiny, why even do it?...which is probably a good thing to consider before
adding more complexity.

~~~
dkoston
Yes, others also include:

\- Proxies that upload/retrieve assets to multiple cloud providers (i.e.
upload files to / retrieve from GCS and S3 in case one is down)

\- A service that screens/transforms attachments/uploads for security before
allowing them to reach other services

\- An API for sending mail/SMS/other contacts via multiple providers to deal
with outages to one or more providers.

Often, these are before built as libraries and imported into multiple projects
which is the wrong approach. Offering up an API for these instead can help
decouple.

However, the author probably doesn't understand versioning and deprecates or
makes breaking changes to APIs and then has to update a bunch of consumers. If
you want a decoupled system, you have to not break the system. This is why
legacy stuff exists at older companies. Once API v1 of the mail sending
service is done and working, there's no reason you need to break it, or add
new features, or take it down. Keep it running and also run v2 so that people
can use the new features. The author is probably running v1 and v2 out of the
same codebase and overwriting the v1 history so they can't maintain it, that's
just bad software project management.

Maybe the title should switch to: "coordinating a complex architecture is
hard, I only build easy stuff"

~~~
sebringj
Yah funny you say that about versioning and breaking changes. The side effect
of the CMS one for example is its been around for 7 years now and I want to
kill it off but there are clients depending on it. I don't even update the
code anymore so I guess its ok but from that lesson learned, making the other
"microservices" as I've defined them you should build a microservice so it can
also be used individually for a client as well as multiple clients where the
work of doing one or many is the same so you could easily walk away from the
responsibility of hosting it if you wanted.

~~~
dkoston
It’s good that you want to update it and make it better. However, it it works
fine for the clients and they are happy, you should be too.

We all look back on our previous work and see room for improvement, that’s a
good thing. However, spending too many cycles trying to achieve perfection
where it’s not desired will prevent you from moving on with your life to
bigger and better pursuits.

Be really happy that you have a software project which survived for 7 years.
Many fail in far shorter time and provide no value.

------
Clubber
But Microservices means I'm good because Agile in the Cloud.

~~~
jrs95
But do you have Containerized Multicloud Agility?

~~~
rzzzt
Microservice-as-a-service.

~~~
mcphage
Too bulky. I switched to Microservices-as-a-Microservice (MA’AM) and have
never been happier.

------
blackflame7000
The growth of microservices is the result of the growth of working remotely.
If you have a large organization in one place most days out of the week its
easy to coordinate proprietary interfaces. With the growth of Agile
development and the ability to have independent groups working on manageable
subtasks is natural. Microservices are simply an application of Divide and
Conqure at the macroscopic level.

------
ukulele
No, truly I am.

~~~
d0lph
I too am frustrated with presumptive headlines.

------
KyleGalvin
The quote at the end “don’t even consider microservices unless you have a
system that’s too complex to manage as a monolith.” causes me to laugh.

I have never fundamentally disagreed with a well-known domain expert as much
as I have with Martin Fowler, and I have had a fairly successful career
despite my attitude of "do things the way M.F. wouldn't".

On one hand I find it frustrating how people take his ideas as gospel. On the
other hand I'm humbled to think there isn't necessarily "one right way" and
other schools of thought can find success.

~~~
guelo
This comment would be more interesting if instead of laughing you would state
what your other way of doing it.

