In the lead up to Nearshore Americas’s special webinar presentation on April 3rd at 2pm EDT Mike Hahn, one of the webinar panel members, is exploring what you need to know about microservices and getting it right for your organization in this special series for Nearshore Americas. This weeks he looks at what you need to truly create a successful microservices environment. You can register for the webinar here.
Making a success of microservices is not just about the coding and architecture effort required to transform a monolithic application; it also relies on a reorganization—at least virtually—in the make-up of your IT teams.
Many businesses that buy into the benefits of microservices make the mistake of using their current IT-team structure and focusing only on building the microservices and writing new code. The problem is they then run into issues when trying to move the microservices into production. They also need to develop and automate new processes for data integration and interfaces, test that the new microservices are working properly and have the necessary security posture, and make sure they can be deployed rapidly – and that means a restricting of the team.
Other keys to success include proficiency in Agile development, Lean principles, and continuous integration and continuous deployment. IT teams that already use these principles within a DevOps environment are well-suited for migrating monolithic applications to a microservices architecture.
In addition, new collaboration tools are needed to enable team members with vastly different job functions to communicate effectively and to automate the software development lifecycle. Only then is it possible to quickly roll out new functionality to end users—one of the key business value offerings of microservices.
Business Requirements and Reorganizing Your Teams
To successfully complete the microservices journey within the expected time frame set by the business, start with the requirements. You need to determine: Which application services need to be provisioned to end users from a microservices architecture?
The answer to this question is usually dictated by how often services change, the end-user workload on the services, and the criticality of the services in the day-to-day functioning of the business. When the business needs are the driver, there’s momentum behind the effort to transform to microservices across the entire organization.
Another key factor is your organizational structure. Traditionally, IT teams are broken into separate silos of sub-teams, responsible for individual functions, such as development, application interfaces, data integration, testing, security and business logic.
Under historical organization models, each team does its own thing and then hands off the application to another team. When problems occur, this arrangement can lead to a lot of finger pointing as everyone tries to determine who is responsible and prove they are not the culprits.
Conversely, microservices uses a new organizational paradigm, where cross-functional teams consisting of resources from each of these functional areas come together and are matched to each microservice that the monolith has been divided into. It’s also important to add someone to the team from the business side—a manager and/or a process analyst who can work with the team to prioritize business needs.
Depending on the availability of internal resources and the number of microservices, you may decide to hire additional people. But you can also consider establishing virtual teams where some resources are part of multiple teams.
The small size and independence of microservices allow you to eliminate dependencies on the knowledge and influence of key individuals. You can also avoid the bottlenecks that result when key people leave or change roles by bringing enablement and intelligence to teams of people who collaborate in a goal-driven, shared-values process.
Evaluate your team-formulation strategy carefully. It’s not just a matter of development; you also want to consider how you will test, add security controls, and move into production. After you identify the roles you require and if you need additional resources, you will also want to train the staff on the tools to use in order to function within a DevOps environment.
Ownership and Responsibility are Team Functions
The cross-functional structure of microservices teams emphasizes ownership and responsibility of each microservice—across an entire team that spans all IT roles. With teams operating autonomously and using distributed leadership and decentralized decision-making, they can function more nimbly.
If there’s a problem in production, for example, it’s not the Ops team that tries to diagnose the issue, nor the Developer team determining if it made a coding mistake. Instead, the entire team assigned to that microservice will collaborate at once to solve the issue.
In the most successful microservices practices, team members are fully-dedicated to specific subsystems of related microservices. They are not contributing on multiple teams at the same time, which has often been tried and almost always proves to be very inefficient.
Several companies have also created full-stack domain teams instead of disparate front-end and back-end teams. Doing so requires some reorganization of resources but results in greater efficiencies as the software team delivers functionality and minimizes complicating dependencies.
Culturally, it helps to encourage proactive ownership and accountability on the software team. In the Agile spirit of continuous improvement, it’s also best to provide meaningful metrics along with constructive, regular performance reviews for individuals and teams.
Facilitating efficient communications among team contributors is important as well. Succeeding in these efforts may mean deploying chat or other tools that allow people to connect and communicate at any time from any location.
The Right Tools Make for Success
After creating teams and assigning them to part(s) of a monolithic application, create the processes to migrate to microservices incrementally—in iterative sprints, one service at a time—while also making sure each iteration delivers value. Start by picking a single business function that you can build as a small microservice, and then plug it back into the monolith via an API gateway. Quickly experiencing initial success will allow all teams to learn the best way of collaborating.
To facilitate collaboration, the teams need to be supported by tools that automate the hand-off of each microservice and streamline communication so that each person on the team can work self-sufficiently. The tools you choose may be driven by the cloud platform you are using, but there are also many tools that work across cloud platforms.
As you build your toolset, be sure to involve resources from all the IT functions and the business. This creates a holistic approach driven by business requirements as to choosing tools that enable teams to deliver the necessary functionality, speed of deployment, and the processes to enable continuous improvements. Tools that facilitate clear and smooth communication on the information that the team needs to share are also a must.
Transforming to Microservices: A Checklist
The checklist below will help guide in you considering the cultural and organizational changes that need to be made to adopt the microservices application architecture approach:
- Based on the functional requirements of the business, determine the microservices that the monolithic application will be broken into.
- Create teams responsible for each microservice; members should cover every function of the software development lifecycle—business logic, development, application interfaces, data integration, security, testing, deployment, monitoring, and support.
- Assign an appropriate business unit manager and/or analyst to every team based on which business unit each microservice pertains to.
- If not already in place, create the necessary processes and provide tools to enable each team to adopt Agile, CI/CD, and Lean principles and methodologies.
- Establish a DevOps environment in which each team can communicate efficiently and hand-off tasks to each other automatically.
Each time a team is tasked with creating or updating a microservice, clear goals should be established as to the new functionality that’s required, the roles of each team member, and the timeline of when the business must have the new functionality. As the team progresses through a microservice project, emphasize the importance of accountability, team autonomy, distributed leadership and decentralized decision-making.
The application design and technologies that are in play—and the processes to be followed to bring the change from design to production—should be transparent for the entire team, and progress updates should be communicated frequently. With the entire team assuming accountability for success, the team will be able to work together more effectively.
For more on how to get your microservices deployment right, register for our webinar on April 3 at 2pm EDT.
Add comment