Hacker News new | comments | show | ask | jobs | submit login

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.

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 ;)

That's pretty spot on. I once made an abbreviated flowchart of the above for my microservices article:


I urge everyone to use it to decide whether they really need microservices or not.

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.

ha this is a great flowchart!

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.

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.

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

Well said, thanks!

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.

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

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/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.

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.

Sounds like a great product.

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

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact