I recently completed a "next generation" architecture prototype for a client using microservices (that part was specified by them).
I developed a dozen microservices to mimic aspects of their existing applications and used Kafka as a message bus. The services rarely spoke directly to each other, but instead listened to events fired into the message bus and updated accordingly.
My biggest takeaway - the client should not use microservices, but could learn some other lessons from the prototype. Microservices make many things harder and the only benefit to them, in my opinion, is they can scale well. But if you're not working at Netflix scale, they're more trouble than they're worth.
What I did recommend:
- Build new applications API-first. By that, I mean your front end UI (assuming you have one) communicates to your backend via an API that can be exposed to the world. And assume it WILL be exposed to the world.
- Avoid bloat in your applications. Stop adding every possible feature to your existing app, and pay attention to when it's getting too big. This is mostly a gut/intuition feel, but you can tell it's a problem when your developers start to look like a deer in headlights when you discuss a new feature.
- (optional) Do create an enterprise message bus, and each application can fire events into the bus. This will help future-proof your organization, as new applications can be built to listen for events without having to understand the other systems.
I developed a dozen microservices to mimic aspects of their existing applications and used Kafka as a message bus. The services rarely spoke directly to each other, but instead listened to events fired into the message bus and updated accordingly.
My biggest takeaway - the client should not use microservices, but could learn some other lessons from the prototype. Microservices make many things harder and the only benefit to them, in my opinion, is they can scale well. But if you're not working at Netflix scale, they're more trouble than they're worth.
What I did recommend: - Build new applications API-first. By that, I mean your front end UI (assuming you have one) communicates to your backend via an API that can be exposed to the world. And assume it WILL be exposed to the world.
- Avoid bloat in your applications. Stop adding every possible feature to your existing app, and pay attention to when it's getting too big. This is mostly a gut/intuition feel, but you can tell it's a problem when your developers start to look like a deer in headlights when you discuss a new feature.
- (optional) Do create an enterprise message bus, and each application can fire events into the bus. This will help future-proof your organization, as new applications can be built to listen for events without having to understand the other systems.