Microservices simplified: An overview
Microservices simplified: An overview

Microservices simplified: An overview

In this series of articles I'd like to share ways in which microservice based solutions can be simplified and built in a way in which team members can be productive regardless of their experience level.?

Microservice architecture is not simple at all, especially when compared with a traditional monolithic solution. However, with proper architectural decisions we can tear down the big monster into simple problems that can be solved in a way in which they will no longer contribute to the overall complexity and let us focus on the business domain rather than technical aspects.

You may wonder, why is it important to "hide" the technical aspects of a software solution, when technology is cool and developers get excited about every new solution for well known problems? Well it might not be an issue at the very beginning of a project when adding new technology to the existing stack will raise the enthusiasm of the team while implementing less exciting functional requirements, and the?team is growing in terms of technical skills.

But this “let’s try” attitude in the long run, usually leads to a couple of major problems which might not be evident at first but sooner or later will show their ugly face, especially when dealing with an already complex architectural style such as microservices.

Here are the most common issues I encountered:

  • Extending the team can become very difficult due to an overloaded technology stack and tooling, often requiring highly skilled developers while the business domain is relatively simple. And we all know senior developers with a very specific skill set are not on every corner.
  • The solution can become rigid towards changes or extension due to technical dependencies, or just because technology is mixed in many ways with the domain specifics, requiring all kinds of extensive refactoring even for simple change requests.
  • Last, but not least, technology is cool, but what's cool today, tomorrow (or in 2 to 5 years) is 'legacy' or 'deprecated'?and can become a swear-word in the mentality of a team which continuously focuses on technical aspects rather than functional ones.

If you read this article until this point, you probably?found yourself in one or more of the above situations and it's a fair expectation from you, to get a solution or some kind of guidance.

So what is the solution to have a system with a complex business domain using microservices architecture with all of its benefits but without requiring the "crème de la crème" of developers with deep technical understanding?

No alt text provided for this image

Yes, the answer is Abstraction, at least in my opinion.

Abstraction is the process of taking away or removing characteristics from something in order to reduce it to a set of essential characteristics

Applying this in a domain centric architecture model, means that technical aspects have to be taken away, in order to put in the spotlight the characteristics essential for the business domain.

But if this doesn’t make much sense to you, instead of watching?the entire Spiderman franchise looking for an explanation, let me invite you to follow me on the next couple of articles in which I’ll discuss the most common problems from an architectural perspective and demonstrate how abstraction is significantly reducing the impact of technology on the overall complexity.

I'll show examples brought from an existing microservice based solution based on .net core using serverless azure functions as host, but they apply to any distributed system, regardless of the programming language or hosting platform.

So here are the topics I'd like to cover:

  1. How to implement distributed processes
  2. How to implement inter service communication?
  3. How to implement caching
  4. How to implement configuration management
  5. How to implement logging
  6. How to implement exception handling
  7. How to improve the code quality of unit tests
  8. (Coming soon) How to handle concurrent processes using pessimistic concurrency
  9. (Coming soon)To implement integration tests that are running in fraction of seconds?

Please note! This is not a tutorial so you won't end up with a working solution, but instead it highlights how applying abstraction can reduce the technical interference with the business domain therefore, improving the productivity of the implementation team.

要查看或添加评论,请登录

Tibi Nagy的更多文章

  • Why Certifications Still Matter

    Why Certifications Still Matter

    I’m thrilled to share that I’ve just earned the Microsoft AI-102: Designing and Implementing an Azure AI Solution…

  • Unit tests simplified: how to bring order in chaos

    Unit tests simplified: how to bring order in chaos

    Despite the title of this article which is too dramatic, because probably there is no chaos in the way most of us are…

  • Microservices simplified: Exception handling

    Microservices simplified: Exception handling

    In this article I'd like to discuss how exception handling can be implemented at application level without the need of…

  • Microservices simplified: Logging

    Microservices simplified: Logging

    In this article I'd like to discuss how logging can be implemented in a generic way without polluting the domain logic…

  • Microservices simplified: Configuration management

    Microservices simplified: Configuration management

    In this article I'd like to discuss how accessing application level configuration can be simplified using a convention…

  • Microservices simplified: Caching

    Microservices simplified: Caching

    In this article I'd like to discuss how caching can be simplified by abstraction in a way in which it extends the…

  • Microservices simplified: Inter service communication

    Microservices simplified: Inter service communication

    In this article I'd like to discuss how service-to-service communication can be simplified by abstracting the…

  • Microservices simplified: Distributed processes

    Microservices simplified: Distributed processes

    In this article I'd like to discuss from a birds eye view, how business processes, distributed across multiple…

  • Thought about programing: TODO or not TODO?

    Thought about programing: TODO or not TODO?

    In this post I share my thoughts about a common phenomenon I noticed in many projects and according to the way I'm…

    3 条评论