5 ms·

You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not ju

You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not just code, but whole build+test+package+promote for every service * Can define upstream/downstream/compile-time/runtime dependencies clearly for each service * Know how to build, expose and maintain good APIs and contracts * Ready to honor b/w and f/w compatibility, even if you're the same person consuming this service on the other side * Good unit testing skills and readiness to do more (as you add more microservices it gets harder to bring everything up, hence more unit/contract/api test driven and lesser e2e driven) * Aware of [micro] service vs modules vs libraries, distributed monolith, coordinated releases, database-driven integration, etc * Know infrastructure automation (you'll need more of it) * Have working CI/CD infrastructure * Have or ready to invest in development tooling, shared libraries, internal artifact registries, etc * Have engineering methodologies and process-tools to split down features and develop/track/release them across multiple services (xp, pivotal, scrum, etc) * A lot more that doesn't come to mind immediately Thing is - these are all generally good engineering practices. But with monoliths, you can get away without having to do them. There is the "login to server, clone, run some commands, start a stupid nohup daemon and run ps/top/tail to monitor" way. But with microservices, your average engineering standards have to be really high. Its not enough if you have good developers. You need great engineers.

StabbyCutyou 10y ago
Well said, thanks!
im_down_w_otp 10y ago
I dunno. Given the fuzzy definition of "microservice" I tend to think of "OTP Applications" as logical microservices... ones you can even build a monolith (or distributed monolith) out of if you want.
dwmtm 10y ago
This is a great list. When micro services work, it's because they made it easy to verify each of these [obvious] bullet points. For some jobs, file this under premature contemplation. When other methods work... My top two are "clarity of focus" and "[relative] lots of unnecessary labour". "Lifecycle" takes a coalition third.
StavrosK 10y ago
That's pretty spot on. I once made an abbreviated flowchart of the above for my microservices article: https://www.stavros.io/posts/microservices-cargo-cult/ https://www.stavros.io/posts/microservices-cargo-cult/ I urge everyone to use it to decide whether they really need microservices or not.
- mr337 10y ago
  ha this is a great flowchart!
- cmdkeen 10y ago
  I know it is a bit tongue in cheek but if you're working somewhere where Data Segregation can be solved by "a simple cascading delete" you aren't operating anywhere close to where any service architecture is relevant.
michaelcampbell 10y ago
This looks like almost a direct copy of one of Matt Stine's popular talks.
- rdsubhas 10y ago
  I'm sorry I'm not aware of the person, but would be interested in reading/seeing it. A quick google search yielded https://blog.pivotal.io/pivotal-perspectives/features/revisiting-microservices-with-matt-stine https://blog.pivotal.io/pivotal-perspectives/features/revisi... - Is this the one you referred? Btw - the list is not an invention worth copying. All items in that are not novel or unique, they are general practices that every good engineer would have their own version of. I'd like to see the talk and try to add a few more items to this.
contingencies 10y ago
That is a good list. At an even simpler level, perhaps we can summarize: Microservices necessitate the application of a more rigorous set of engineering practices to all service infrastructure components and therefore carry a greater overhead than traditional development methodologies - rigorous engineering does not come free. Whether that trade-off makes sense for any given project is a question of resources and requirements. I feel two salient points were not mentioned: (1) Popular microservice orchestration/infrastructure management approaches are not universally applicable; their limitations should be recognized before assuming applicability. (2) The webhost is currently down; perhaps the author should have used a scalable or distributed cluster of microservices ;)
est 10y ago
In my experience, once microservice, it's very hard to run the whole system in local environment. It's nearly impossible to overview the system anymore.
tkyjonathan 10y ago
You can add to your list all the sysadmin, devops complexity to the power of two, new single-point-of-failure issues, SLAs, backups, retention of backups.... Basically, you are multiplying the complexity of the ops people.
- appelza1 10y ago
  Microservices done right won't have a single point of failure, though. Agreed us ops guys have a lot more work cut out for us, at least initially.
crdoconnor 10y ago
They're nearly always a major violation of KISS, in other words.
- deleted 10y ago
  [deleted]
berta 10y ago
Awesome inventory. I'd add service discovery and distributed key/value store for configuration data
blazespin 10y ago
Sounds like a great product.
deleted 10y ago
[deleted]
enginerding1337 10y ago
I didn't realize pivotal and XP were different things - anonymous pivotal labs pivot, clutching his stained copy of XP explained

StabbyCutyou 10y ago

Well said, thanks!

im_down_w_otp 10y ago

I dunno. Given the fuzzy definition of "microservice" I tend to think of "OTP Applications" as logical microservices... ones you can even build a monolith (or distributed monolith) out of if you want.

dwmtm 10y ago

This is a great list. When micro services work, it's because they made it easy to verify each of these [obvious] bullet points. For some jobs, file this under premature contemplation. When other methods work... My top two are "clarity of focus" and "[relative] lots of unnecessary labour". "Lifecycle" takes a coalition third.

StavrosK 10y ago

That's pretty spot on. I once made an abbreviated flowchart of the above for my microservices article: https://www.stavros.io/posts/microservices-cargo-cult/ https://www.stavros.io/posts/microservices-cargo-cult/ I urge everyone to use it to decide whether they really need microservices or not.

mr337 10y ago
ha this is a great flowchart!
cmdkeen 10y ago
I know it is a bit tongue in cheek but if you're working somewhere where Data Segregation can be solved by "a simple cascading delete" you aren't operating anywhere close to where any service architecture is relevant.

michaelcampbell 10y ago

This looks like almost a direct copy of one of Matt Stine's popular talks.

rdsubhas 10y ago
I'm sorry I'm not aware of the person, but would be interested in reading/seeing it. A quick google search yielded https://blog.pivotal.io/pivotal-perspectives/features/revisiting-microservices-with-matt-stine https://blog.pivotal.io/pivotal-perspectives/features/revisi... - Is this the one you referred? Btw - the list is not an invention worth copying. All items in that are not novel or unique, they are general practices that every good engineer would have their own version of. I'd like to see the talk and try to add a few more items to this.

contingencies 10y ago

That is a good list. At an even simpler level, perhaps we can summarize: Microservices necessitate the application of a more rigorous set of engineering practices to all service infrastructure components and therefore carry a greater overhead than traditional development methodologies - rigorous engineering does not come free. Whether that trade-off makes sense for any given project is a question of resources and requirements. I feel two salient points were not mentioned: (1) Popular microservice orchestration/infrastructure management approaches are not universally applicable; their limitations should be recognized before assuming applicability. (2) The webhost is currently down; perhaps the author should have used a scalable or distributed cluster of microservices ;)

est 10y ago

In my experience, once microservice, it's very hard to run the whole system in local environment. It's nearly impossible to overview the system anymore.

tkyjonathan 10y ago

You can add to your list all the sysadmin, devops complexity to the power of two, new single-point-of-failure issues, SLAs, backups, retention of backups.... Basically, you are multiplying the complexity of the ops people.

appelza1 10y ago
Microservices done right won't have a single point of failure, though. Agreed us ops guys have a lot more work cut out for us, at least initially.

crdoconnor 10y ago

They're nearly always a major violation of KISS, in other words.

deleted 10y ago
[deleted]

berta 10y ago

Awesome inventory. I'd add service discovery and distributed key/value store for configuration data

blazespin 10y ago

Sounds like a great product.

deleted 10y ago

[deleted]

enginerding1337 10y ago

I didn't realize pivotal and XP were different things - anonymous pivotal labs pivot, clutching his stained copy of XP explained