Why would anyone define microservices as an architecture choice?
If you're already familiar to microservices, then the answer to the question above might seem quite obvious. But if you aren't, like me, then you might learn some new concept today.
So, I've recently got his book titled "Building Microservices: Designing Fine-Grained Systems" by Sam Newman and I'm going to write some content as I read, and understand, it :).
Microservices are technology agnostic; they are independently deployable; they embrace the concept of information hidding.
Here is a statement I really like and find extremely important within the confines of... software?, system? development. Whatever.
“Information that is hidden from external parties can be changed freely as long as the networked interfaces the microservice exposes don't change in a backward-incompatible fashion.”
Sam Newman
That makes the whole system modular and reliable.
But what kind of system could it be? Are we talking about a standalone software consisting of various microservices? Perhaps, a bigger picture of a system consisting of a few softwares, each of them working over microservices at the same time?
Well, let's get through this by describing a few illustrative examples!
MAVLink microservices
|
| MAVLink Command Protocol |
Here's how I see this particular case: MAVLink is an interface-level library usually integrated as a git submodule in bigger software repositories (QGroundControl, ArduPilot, etc.). "Most services use the client-server pattern, such that the GCS (client) initiates a request and the vehicle (server) responds with data".
For instance, the
MAVLink Command Protocol
exposes a public interface (you send a
COMMAND_LONG, you receive a
COMMAND_ACK) allowing various bigger softwares
like PX4 or ArduPilot to internally handle it their own way without affecting
each other. Then we can say the
Command Protocol microservice is abstracting both client and server from
their own implementations.
Google Sign-In microservice
“Google Sign-In manages the OAuth 2.0 flow and token lifecycle, simplifying your integration with Google APIs.”
Google for Developers
Think about the last time you clicked "Sign in with Google" on some application. Spotify, Airbnb, ..., it doesn't matter. That button is basically saying: "hey Google, deal with this, I don't want to handle this guy's sh*tt* password!".
From that point, the app has no idea what happens next. Let's say Google asked the user for a fingerprint, or a captcha, maybe it flagged the login as suspicious. The app just sits there waiting for a token. That's the advantage of using microservices for this purpose.
Google can completely gut and rebuild their authentication internals tomorrow and Spotify won't be affected at all!
The exposed interface, OAuth 2.0, stayed the same, so everything just keeps working.
E-Commerce-ish microservices
Imagine you're building an online store. You've got a "Buy now" button and behind that button, a whole lot of things need to, and will, happen: check if there's stock, charge the card, send a confirmation email, bla, bla.
You could write all of that in one giant block of code (and may the force be with you brother).
And it would probably work!
Until the day you want to swap your payment provider, and suddenly you're digging through thousands of lines trying to figure out what to do. Not sooo ideal I'd say.
Instead, you split things up.
An Order Service, an Inventory Service, a Payment Service, a Notification Service... Each one of them minding its own business. The Order Service doesn't need to know how payments work. It doesn't know if you're using Stripe, PayPal, or something else.
When you decide to switch payment providers? You just swap out that one service.
So, why would anyone define microservices as an architecture choice?
Payment providers, authentication systems, communication protocols... Nothing stays the same forever. And when you encapsulate your internals behind a stable interface, change stops being a nightmare.
Defining microservices as an architecture choice is essentially betting on that idea. You're deliberately designing your system around boundaries: small, independent, replaceable pieces.
I'm still early in the book so there's surely a lot more nuance to unpack. But so far, I'd say the concept sells itself.
PD: I'm very lazy when it comes to reading books. Don't be surprised if this is the first and last chapter ;).
No hay comentarios:
Publicar un comentario