6 ms·

Avoiding the Distributed Monolith

132 points by jetheredge 8y ago

ukulele 8y ago
No, truly I am.
- d0lph 8y ago
  I too am frustrated with presumptive headlines.
- jrs95 8y ago
  I actually am too! And I'm surprised that I'm "doing it right", to be honest.
Clubber 8y ago
But Microservices means I'm good because Agile in the Cloud.
- jrs95 8y ago
  But do you have Containerized Multicloud Agility?
  - rzzzt 8y ago
    Microservice-as-a-service.
    - mcphage 8y ago
      Too bulky. I switched to Microservices-as-a-Microservice (MA’AM) and have never been happier.
sebringj 8y ago
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 8y ago
  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 8y ago
    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 8y ago
      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.
dkoston 8y ago
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 8y ago
  > 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 8y ago
    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...
KyleGalvin 8y ago
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 8y ago
  This comment would be more interesting if instead of laughing you would state what your other way of doing it.
toss1 8y ago
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.
- SmirkingRevenge 8y ago
  Great observations. In my experience, microservices get perilous when you have a few junior level devs seduced by the mistaken idea that they only need to think hard about a single component of a complex system, and the rest can just sort of take care of itself later.
- Traubenfuchs 8y ago
  Googling "TFA microservice monolith list" leads to your post. Where are the lists? (-;
  - toss1 8y ago
    In the original article linked above to which this is a comment("TFA" = "The Fine Article"), first one about a page down
blackflame7000 8y ago
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.

132 points by jetheredge 8y ago

ukulele 8y ago

No, truly I am.

d0lph 8y ago
I too am frustrated with presumptive headlines.
jrs95 8y ago
I actually am too! And I'm surprised that I'm "doing it right", to be honest.

Clubber 8y ago

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

jrs95 8y ago
But do you have Containerized Multicloud Agility?
- rzzzt 8y ago
  Microservice-as-a-service.
  - mcphage 8y ago
    Too bulky. I switched to Microservices-as-a-Microservice (MA’AM) and have never been happier.

sebringj 8y ago

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 8y ago
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 8y ago
  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 8y ago
    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.

dkoston 8y ago

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 8y ago
> 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 8y ago
  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...

KyleGalvin 8y ago

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 8y ago
This comment would be more interesting if instead of laughing you would state what your other way of doing it.

toss1 8y ago

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.

SmirkingRevenge 8y ago
Great observations. In my experience, microservices get perilous when you have a few junior level devs seduced by the mistaken idea that they only need to think hard about a single component of a complex system, and the rest can just sort of take care of itself later.
Traubenfuchs 8y ago
Googling "TFA microservice monolith list" leads to your post. Where are the lists? (-;
- toss1 8y ago
  In the original article linked above to which this is a comment("TFA" = "The Fine Article"), first one about a page down

blackflame7000 8y ago

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.