You're facing pushback from team members on microservices integration. How can you win them over?

As a leader, my responsibility is to define a clear vision and goals for the team. Defining this vision is just the beginning. As a technical leader, I work closely with engineers to create a roadmap for solution design. I ensure they understand the bottlenecks of both existing and proposed designs and encourage active participation in finding solutions. When the team contributes, they become part of the change and solution, minimizing resistance. Importantly, outlining the benefits of microservices design is crucial. The requirements for highly available, scalable, and fault-tolerant systems can be easily achieved with a distributed and decoupled application design by implementing micoservices.

When you face pushback on using microservices, it’s key to explain the benefits clearly. Microservices can make our system more scalable and flexible. This means we can easily add new features and handle more users without major changes. With microservices, we can deploy updates faster, improving our response time to market needs. Each microservice can be developed and updated on its own, making maintenance easier. If one part of the system has a problem, it won’t crash the entire system, which improves reliability. By focusing on these points, you can help the team see how microservices can make our work smoother and more efficient, ensuring success for everyone.

talking about "benefits" means to clearly define more than technology itself, it also involves to mention monetary benefits such as not having on prem hardware, world wide connectivity, even hiring abroad personal, ROI, etc. all this is coming with a good analysis and design about where and why to set such services here and there.

Active listening is crucial for a technology leader. In scenarios where we need a team meeting or one-on-one, I’d set up quick discussions to understand the team's concerns, and maybe even establish a regular cadence for progress check-ins and resolving issues to ensure everyone is aligned. During these sessions, we’ll create a detailed plan for defining API/service boundaries, implementing API gateways, and establishing automated testing. Ensuring the microservices design is performant through monitoring and optimization is essential. Comprehensive workshops will be conducted to train on new concepts. Additionally, sharing previously implemented services as reference points will help connect the dots.

sure, people start freaking out when they are losing control of the things but contracts have to be clear such as responding any eventuality, clearly notifying that services will be up and running, at least, 99.99%, your in-shore and off-shore has to be available for any emergency, define clearly pros and cons, clear path of when, how, why, etc.

your company will become more "administrators" of processes as well as some internal development and for that training is important to understand how services works and why they are develop and that way.

To win over team members who are hesitant about microservices, create a collaborative environment. Encourage everyone to share their experiences and insights. Form cross-functional teams with both supporters and skeptics of microservices. This mix will foster dialogue and peer learning. Breaking down silos helps everyone understand how microservices can benefit the organization. Working together on solving problems is key when dealing with a new architectural style. By promoting teamwork and open communication, you can build a shared vision and help everyone see the value of microservices. This approach ensures we tackle challenges together and succeed as a team.

I’ve broken a monolith into a decoupled and highly distributed architecture. The first step is to create a proof of concept (POC) for the new architecture, ensuring the data flow functions as expected for a business service. Next, I refactor the code from the monolith application relevant to the new service, ensuring no direct dependencies on other services from the application layer point of view. Then, integrating the refactored code with the initial POC and infra-setup completes the service's functionality. Similarly, other components should be split to create separate services. Once done, integration tests should be conducted to ensure end-to-end flow. UAT and load testing are also crucial before production deployment.

yep, POC before anything. what you do when you buy? you try it first, right? so, POC is a way to learn to where are you getting into.

now a days, more companies are jumping into micro services but unfortunately lot of companies are missing vital check points such as "micro services response is in milliseconds but searching in the DB can take up to a second". comments like that is telling you to run away from that provider or architect.