Here are some of the common mistakes when moving to microservices that are discussed in this presentation, with provided solutions for:* No realistic architecture process (architecture decisions too rigid, or not taken; infra vs domain; architecture guild vs no cooperation, knowledge sharing ); * QA thinks testing end-to-end is possible; Management wants to control deployment; …
Ruby on Rails applications tend to turn into giant monoliths software architecture. Keeping the codebase maintainable usually requires architectural changes. Microservices? A distributed monolith is still a monolith. What about breaking the code into pieces and rebuild a monolithic puzzle out of them?
Despite the benefits of microservices, this software architecture has introduced some security challenges. This talk focuses on the confidentiality issues associated with this architecture. The main point is that microservices architecture could introduce major insider threats to data confidentiality.
Conversations about architecture can now be summarized in simple words – you start a project, do microservices. The question is, is this a good approach? Is each problem to be solved using the ‘cloud application in microservice architecture’? Of course not! So why are we doing this? Is there a different approach to the problem? …
This talk covers basic concepts in domain-driven design (DDD), and we discuss why and how DDD can help create microservices with better autonomy, scalability, and reliability. Using examples, we navigate from a domain model to the design of both synchronous (REST-based) and asynchronous (reactive) microservices.