3 ms·

The original goal for moving from a monolith to a microservices architecture was loosely stated as “its hard for us to work on the app together and ship feature

The original goal for moving from a monolith to a microservices architecture was loosely stated as “its hard for us to work on the app together and ship features”. Something that isnt addressed in the results or suggestions. How much did the team improve shipping features for customers? Is the app more reliable? Does the engineering team spend way more time on CI/CD and all the other “overhead”? Most teams will never need this type of solution, even though theyre tons of fun to build and operate. I just wish we had a better way of sharing the non-engineering results of these types of efforts.

pc86 8y ago
Any CI/CD overhead should not be unique to microservices though. I've worked on monoliths with fully automated CI/CD pipelines, tests, etc. I haven't noticed any difference in the amount of overhead/ALM work required between monoliths and microservices other than the number of tests, scale/time of deployment, etc.
matwood 8y ago
> Does the engineering team spend way more time on CI/CD and all the other “overhead”? CI/CD is required regardless of microservice or monolith. Once you have it working for one deployment, it should be trivial for 1+N.
- thinkingkong 8y ago
  Id welcome a good discussion on triviality in this case. Wiring up jenkins or something to just deploy when you press the button can be easy. Wiring it up so distributed services being augmented, deployed, migrated, etc all without downtime - to me at least - is complex enough to not be trivial.
  - matwood 8y ago
    IMO, CI/CD already means zero downtime deploys. After a team has done the CI work on commits and zero downtime CD, it doesn't matter if it's for a monolith or microservices. The initial work is not trivial, but once it is done you just copy it for each service. Maybe you are thinking about how do you deploy inter-service dependencies? In that case, you don't. I'm not joking. When you move to microservices you have to treat other internal services like they are something you do not control. This means maintaining backwards compatibility, versioned APIs, etc... At first it seems like it is harder, but once you get in the mindset that this always must run and serve existing clients it is rather freeing. Plus, being able to treat each service on its own makes it easy to focus and do large changes - thus move faster. Compare this to friends who tell me about logging in at 11PM to deploy because they have to take the system down. Completely taking down the system to deploy should almost never happen today.

pc86 8y ago

Any CI/CD overhead should not be unique to microservices though. I've worked on monoliths with fully automated CI/CD pipelines, tests, etc. I haven't noticed any difference in the amount of overhead/ALM work required between monoliths and microservices other than the number of tests, scale/time of deployment, etc.

matwood 8y ago

> Does the engineering team spend way more time on CI/CD and all the other “overhead”? CI/CD is required regardless of microservice or monolith. Once you have it working for one deployment, it should be trivial for 1+N.

thinkingkong 8y ago
Id welcome a good discussion on triviality in this case. Wiring up jenkins or something to just deploy when you press the button can be easy. Wiring it up so distributed services being augmented, deployed, migrated, etc all without downtime - to me at least - is complex enough to not be trivial.
- matwood 8y ago
  IMO, CI/CD already means zero downtime deploys. After a team has done the CI work on commits and zero downtime CD, it doesn't matter if it's for a monolith or microservices. The initial work is not trivial, but once it is done you just copy it for each service. Maybe you are thinking about how do you deploy inter-service dependencies? In that case, you don't. I'm not joking. When you move to microservices you have to treat other internal services like they are something you do not control. This means maintaining backwards compatibility, versioned APIs, etc... At first it seems like it is harder, but once you get in the mindset that this always must run and serve existing clients it is rather freeing. Plus, being able to treat each service on its own makes it easy to focus and do large changes - thus move faster. Compare this to friends who tell me about logging in at 11PM to deploy because they have to take the system down. Completely taking down the system to deploy should almost never happen today.