3 years ago

Category: Software, Data, Kubernetes, Docker, Infrastructure, Architecture, automation, yaml

However, there are still high chances that you end up working in an organization or project where monolithic architecture is still dominant, for a variety of reasons: We will go through the initial analysis and preparation for a microservices transition, provide tips and best practices related to the process of splitting your monolithic applications into microservices, and comment about the adoption of some technologies and processes that will help future-proof your solution in a world of constant changes.

If you are dealing with a large existing monolithic application developed over the years, the monolith typically will contain lots and lots of functionality which, although necessary for the business, probably there is no point in making the effort to replicate it in the form of microservices.

For example, you may need to choose a combination of technologies like: Of course, these technologies should be the ones you need for your application, but the point is that there is no reason to develop the business logic (microservices) in Node.js, Java, PHP, Scala, and Groovy just for the sake of doing it and exploring the technology.

You need to solve all these problems, and perhaps some more depending on your technology choices: A consequence of choosing specific technologies for each purpose in your microservices stack is that you will end up with families of containers with similar purposes.