Microservice Architecture
Microserivce, a fun buzzword, an alternative for SOA, however, terms aside, one thing that I personally love thinking about is the underlying architecture regarding microservices. From looking at more primitive solutions such as just having some cluster with a bunch of services, maybe if you’re lucky having some application gateway sitting in front of the services, allowing for routing to be channelled through a single service. Or whether it’s looking at more enterprise solutions, such where the services are engineered in a reactive manner, perhaps making use of something like a JMS implementation. I should declare now that one vital point behind utilising this architectural format is to ensure resilience, availability, etc.
Anyway, while I’m still learning more & more about this subject, since I’m quite new to this subject, I thought it may be fun to share what I’ve learned with you guys! 👍

As mentioned, I’m still learning, however, the knowledge that I’ve accumulated so far appears to be of some value. I’ve been spending many hours on Pluralsight at this moment in time, half of that time has been used to search through content that could be of use, in total, at this moment in time I believe I’ve accumulated 400 hours or so worth of content. Of course, I’ve not even scratched the surface in terms of the amount of content I’ve watched & taking in, but I’m getting there, slowly but surely! 😎
Get to the point…
Okay, so to start, I’d like to talk about the tools that I’ve been tinkering with, some are obvious or no-brainers if you’re somewhat familiar with modern-day technologies & architectural decisions such as using Docker & Kubernetes.
- Kubernetes
- Docker
- Spring(Boot, Cloud, etc.)
- Zuul
- Eureka
- RabbitMQ
- Circuit Breakers
Of course there are many more options out there, a quick example being how you could utilise something such as MaaS instead of having your own JMS solution in place.
What does that mean?
Okay, so tool names aside, in this section I’ll be covering a little bit about what some of the tools that I’ve listed above does & when or where you may want to use it/them. So let’s start with some of the obvious ones, such as Spring, I personally have a deep love for Spring, I honestly think it’s the best thing since sliced bread, auto-config is just worthy of my love alone. But, it does do a lot of things for you, it makes life so easy, whether it’s connecting to some database or providing pretty epic tools, such as JPA repositories. There’s very good reason why Spring is so popular, in addition to the basic stuff, Spring Cloud offers a neat range of tools, such as a gateway.
Now if you’re not sure what a gateway is, you can think of it as a tool or technology that allows all incoming traffic to be routed through this one endpoint. This means that you can, essentially simplify the external facing URI’s, etc, it can also be used to increase security, resilience, etc, an example of how this can be awesome is by implementing rate limiting. Another substantial benefit that I find about using an API gateway is that it allows you to encapsulate some layer of complexity, whether this is the mixing of different communication protocols or what, it makes life that much better or easier.

Zuul is essentially a technology that comes from Netflix, in a nutshell it is a layer 7 API gateway service provider, so if you hear Zuul being mentioned in future, provided you’ve read this far, you at least have a basic idea of what it is.
Another tool that I mentioned above, Eureka, it’s another technology engineered by Netflix, in a nutshell, Eureka is a service registry. You may be wondering what does that mean? I’m glad you asked, a service registry is a tool or mechanism that will dispatch requests to specific microservice, an example of the general idea can be found here:

Finally, RabbitMQ, I’m going to make the assumption that you at least have a basic idea of what JMS means, if not, then maybe it may be best to start by looking at articles such as this. If anyone wants me to provide an article on JMS in future, by all means, let me know! 🙂 RabbitMQ is essentially a rather commonly used technology when implementing some message broker.
Conclusion
In a summary, I love talking about architecture these days, however, I’m not saying that you should go out & restructure your current architecture, there are many reasons & variables that one needs to consider when looking at architecture. Whether it’s purely cost, or if it’s the time & complexity that would be involved in changing from a more traditional architecture to a more modern architecture, it’s understandable if you don’t take that leap of faith. An example of where an entity or a company may not bother updating architecture is if it’s a very high risk environment, whether that’s for some bank or some government entity, who knows?
Of course there are also many other tools, technologies, techniques, etc that you can talk about when discussing microservice architecture, I’ve not even covered the do’s & don’t when looking at microservice architecture. I’ve not covered techniques around CI/CD pipelines, etc, I’ve only really skimmed the surface, just enough for you to essentially start looking into it yourself. Plus since I’m still very far from being considered an expert on the subject myself, I’m not in a position to cover all sections. Hopefully one day I can claim to be an expert on microservice architecture, but for the time being, I just need to invest more time into research & experience.
I hope you’ve enjoyed this read, stay tuned! 😊