Yet another article that misses a huge aspect of microservices: Reusability. (I'm going to borrow from an older comment [1] here.)
Almost all of the swathe of microservices we've developed internally are general-purpose. We've built a dozen or more user-facing apps on top of them. If I wanted to build a new app today, I would typically sit down and write a Node + React app, configure some backends, and I'd be done. I don't need to write a new back end because I can just call our existing services.
If you look at what a modern web app is, most apps these days are actually stupidly similar. They typically need things like:
* User accounts
* Authorization with existing OAuth providers (e.g. Facebook)
* Some kind of database to store and search structured content
* Notifications (email, text, push)
* Storing images or video
* Syncing data from external sources
* Analytics
We have generalized, reusable microservices that do all of this.
Let's say I want to build a HN-type link aggregator with comments. I will use our document store to store the links and the comments in a nice hierarchical structure. I will use our login microservice that mediates between an identity data model and an OAuth account registry. I can use our tiny microservice devoted to recording up-/downvotes. I can use our analytics backend to record high-level events on every UI interaction.
I can write this without a single new line of backend code.
This ability to "pick and mix" functionality you need is the real, largely undiscovered beauty of microservices, in my opinion. It's the same idea that makes AWS attractive to many people; you're building on the foundation of thousands and thousands of work and reusing it.
We just whipped up a new site recently where 95% of the work was purely on the UI, since all the backend parts already existed. The remaining 5% was just code to get data to the system from a third-party source, plus some configuration.
Reusability requires that you plan every microservices to be flexible and multitenant from day one. It's a challenge, but not actually a big one.
Is it possible to do this monolithically? Sure. I would be afraid of touching such a beast. We have very few issues with code devolving into "legacy", for example; the strict shared-nothing APIs ensure that half-baked, client-specific hacks don't sneak into the codebase. If anything messy happens, it happens in the client app, and that's where it should happen. Eventually you'll throw the app away, but the backends remain.
Almost all of the swathe of microservices we've developed internally are general-purpose. We've built a dozen or more user-facing apps on top of them. If I wanted to build a new app today, I would typically sit down and write a Node + React app, configure some backends, and I'd be done. I don't need to write a new back end because I can just call our existing services.
If you look at what a modern web app is, most apps these days are actually stupidly similar. They typically need things like:
* User accounts
* Authorization with existing OAuth providers (e.g. Facebook)
* Some kind of database to store and search structured content
* Notifications (email, text, push)
* Storing images or video
* Syncing data from external sources
* Analytics
We have generalized, reusable microservices that do all of this.
Let's say I want to build a HN-type link aggregator with comments. I will use our document store to store the links and the comments in a nice hierarchical structure. I will use our login microservice that mediates between an identity data model and an OAuth account registry. I can use our tiny microservice devoted to recording up-/downvotes. I can use our analytics backend to record high-level events on every UI interaction.
I can write this without a single new line of backend code.
This ability to "pick and mix" functionality you need is the real, largely undiscovered beauty of microservices, in my opinion. It's the same idea that makes AWS attractive to many people; you're building on the foundation of thousands and thousands of work and reusing it.
We just whipped up a new site recently where 95% of the work was purely on the UI, since all the backend parts already existed. The remaining 5% was just code to get data to the system from a third-party source, plus some configuration.
Reusability requires that you plan every microservices to be flexible and multitenant from day one. It's a challenge, but not actually a big one.
Is it possible to do this monolithically? Sure. I would be afraid of touching such a beast. We have very few issues with code devolving into "legacy", for example; the strict shared-nothing APIs ensure that half-baked, client-specific hacks don't sneak into the codebase. If anything messy happens, it happens in the client app, and that's where it should happen. Eventually you'll throw the app away, but the backends remain.