Can a Monolithic team handle Microservices?

 

As monolithic structures become too big to manage, many companies are drawn to migrate to microservices. It’s a worthwhile trip, but it’s not simple. To do this well, we need to start out with a simple service and then build services based on vertical capabilities that are essential for the company and are subject to frequent changes. Such services should at first be broad and ideally not depend on the remaining monolith. We should ensure that every migration step represents an improvement on the architecture as a whole.

Migrating from a monolithic architecture to microservices is an epic journey. Those who embark on this journey have aspirations such as increasing the scale of operation, accelerating change pace and escaping the high cost of change. They want to increase their number of teams, allowing them to deliver value in parallel and independently of each other. Companies want to experiment with their core capabilities rapidly and deliver value faster. They also want to escape the high costs of changing their existing monolithic systems.

Which capacity to decouple, when and how to migrate incrementally – are some of the architectural challenges of decomposing monolith structures to microservice ecosystems. In this write-up, we discuss how a monolithic team can handle microservice applications.

Tools are Only Enablers

Teams stepping onto the right path still need to master using DevOps and CI/CD pipeline to democratize their development. Microservices enable scaling for DevOps team. DevOps enables development and deployment of Microservices application without any interference. It eliminates bottlenecks that were prevalent with the traditional approach.

Knowing how to use a tool is only a journey begun. It brings up the issue of managing the compartmentalization. Tools are enablers for its users, and they need to be put into use with right intent and purpose so that it gets to the destination faster. Developers and architects need to be experts while designing and developing the system, moreover, be capable of coordinating across multiple teams and services. Each compartment should be able to run independently and, at the same time, be prepared to shut off when running into issues with a higher level of fault tolerance in the system.

Automating continuous delivery and testing pipeline requires the right know-how to foresee challenges. Scripting your infrastructure and testing to be run on automated requests makes it easier to manage the system-level changes and better handle issues.

Cloud-Native Development

While deploying applications on cloud is more of a norm these days, so is cloud-native development, which allows to take advantage of the cloud computing model. This makes containerization & orchestration more manageable while helping detecting errors before releases. While most teams already know how to manage cloud applications, cloud-native development still needs upskilling.

Model Microservices Team

Just by changing the way of writing a mammoth-sized application into smaller manageable chunks, it doesn’t fix the issue of writing incorrect code or having poorly tested applications. Previously, where you couldn’t bring in an expert team to handle the non-core part of your application, now it can be readily developed with the use of external teams.

This also enables an accelerated approach to shift the mindset with model teams. While we expect Microservices to allow the development of various services simultaneously, we can’t have teams incrementally upskilling to handle Microservices and DevOps. Outsourcing plays an active role in maintaining your development’s velocity and momentum while raising the benchmark for your existing team. This combined approach has helped many customers see value early in their lifecycle and become flexible in handling changing circumstances.

Structuring the A-Team

A large portion of this transition to Microservices and DevOps still banks on the organization changing its way of collaborating and developing applications. New age product companies that started with Microservices ecosystem in their culture still run into problems because of this fundamental shift lacking. Most companies end up creating horizontal teams to handle services. Why? Because that’s easy to put on to the Project Management tool and look at productivity charts.

Now that we have established teams as the enablers of change, it is necessary for some reshuffling in the thought process and thus the way teams are structured:

Accountability: Having compartmentalized services also means having compartmentalized responsibility. Accountability starts with detailed specs being written and communicated to all parties involved. This makes outsourcing chunks of work to external teams easier and efficient.

Vertical Teams: Giving up the traditional horizontal team structure for APIs, Data, Front-end, and Back-end services, instead of adopting siloed and independently-run teams that take ownership of each of the services, becomes the apt practice. This leads to the rise of full-stack developers being able to manage different aspects of the services. Each service team will thus have its API members, developers, data engineers, and testers.

Communication via API: Think of running the services as a mini software and communicating with other services using APIs. Communication between services becomes crucial for compartmentalization and the only way to measure the overall application’s performance.

Rise of Integration Testing: It’s time to give some rest to the old methods of testing while giving the mantle to integration testing. As system failure gets compartmentalized, the points of failure are detected at the integration points for your team to identify issues. This also gives the commandment that each service should be written keeping in mind that the service in its entirety can be rewritten or fixed within a day.

Diversity in Technology: Due to the modular nature of Microservices, it becomes easy and obvious to choose the right technology or framework for the service instead of relying on a single technology for the development of an entire application. The technology preference of your team takes huge precedence in the selection. CTOs are often asked to choose a technology based on the team’s preference, while in a parallel world, there are those CTOs who restrict the technology giving stability an important consideration over team’s preference. This goes to say that CTOs have a huge role in foreseeing challenges even before they occur.

Distributed Governance: Similar to how testing is simplified at the service level and priority is given to integration points, governance can also be managed at the aspects of communication between services. This can be handled with well thought out planning and an effective method to handle changes. When you distribute or decentralize governance, don’t forget to impart the importance of responsibility from each team member.

Conclusion

Microservices are far-reaching, but should not be taken lightly because the greater the reward, the higher the risk. New Age Product companies made incredible strides in embracing the microservices ecosystem and Digital Enterprises chartered their 2-year roadmap to revolutionize the strategy to software development. There is still a lack of adequate talent to scale Microservices to its true potential, however. Upskilling and outsourcing should be seen as parallel courses of action instead of alternatives for an effective change in strategy.

 

This is how TVS Next helped a client implement microservices to drive innovation

 

Our client, a leading player in the education space, had a monolithic structure and was facing issues restricting the team from innovating. Scalability, inability to incorporate new business requirements swiftly and many other problems in the deployment infrastructure had to be overcome, rapidly.

After a comprehensive assessment and due diligence that encompassed all aspects of their business and technology landscape, TVS Next helped them migrate to Microservices application.

The processes of development, testing, deployment, troubleshooting, upgrading, and maintenance became more streamlined and efficient.

Robust processes governed the execution & governance structure with constant stakeholder reviews, and the transformation from legacy monolith to robust Microservices was established in 8 months.