10 Practical Tips for Making the Transition to Microservices
It’s time. You have read the articles, blogs, and navigated all of the various opinions surrounding microservices. You have looked at the pros and cons, and you have decided that microservices is a fit for the team. It isn’t going to be easy, but the end result will be an agile, more adaptive development process.
Now, where do you start?
Here are some practical tips from a management perspective that will help make the transition to microservices as smooth as possible.
Breaking Things Apart
The first thing to do is evaluate the application and determine what should be segmented off into their own services. Most applications are broken down according to a function which should be able to stand alone. For example, if building out an e-commerce site, then you may be able to segment out the checkout system from other components of the application such as products or inventory.
Tip #1: Break things off one at a time. Don’t try to componentize the whole application at once.
Tip #2: Start with a component that is already not heavily dependent on the rest of the application. The first break should be simple and a way to ease into the process.
Tip #3: Try to find components of the application that only serve one function. The simpler the service, the easier it will be to maintain.
Organizing the Team
As a result of breaking apart the application, the team will undergo some reorganization. Generally, teams are segmented and focused around each microservice. Many companies organize teams consisting of both developers and operations in order to give full autonomy and control from development to deployment.
Tip #4: Create teams around a component of the application before it gets broken off into a separate service. Once in place, they can then work towards segmentation of their component into a microservice.
Tip #5: Do daily scrum meetings, and then have a weekly scrum meeting to get updates on the major aspects of the development process. Once transitioned into microservices, the weekly meetings can be on an as needed basis.
Master the Continuous Delivery Process
Having a working continuous delivery process in place is a prerequisite to microservices. If you want to implement microservices, you’ll save yourself a ton of pain and headache by implementing continuous integration and continuous delivery first. This is because microservices multiplies the number of things to integrate, deploy, and deliver.
To learn more, you can download our whitepaper on popular Continuous Delivery Patterns for Design and Deployment.
Having had had a continuous delivery process in place for over 5 years, our transition was relatively simple. We also use Cycligent to simplify the process of deploying and managing our enterprise software applications and to save time. The tool has allowed us to assign one developer to a microservice because the integration, build, deployment, and management process is automated.
Tip #6: Automate and document the build, test, and deployment process so that it can scale with the microservices architecture with ease.
Tip #7: Invest in tools such as Cycligent that will automate or simplify things for the development team, so they can focus on application development and less about the complexity of microservices.
Develop Processes and Guidelines to Provide Consistency
Microservices gives developers a certain amount of autonomy as to how their service should be designed and developed. As a result, developers may decide to adopt a new technology, language, framework, or library in an effort to find the right tools for the job. While this can definitely be a benefit, it should not be left unchecked. In the end, integrating too many varieties of technologies could lead to an overly complex application that becomes difficult to manage.
If you already have a monolithic application in place, odds are the core technologies will stay the same. As opportunities to implement new technologies arise it is important to ensure that each decision is sound and will produce the intended benefits.
Tip #8: Create company-wide processes that require developers to talk to managers about introducing new technologies.
Tip #9: Ensure that there are multiple developers that are trained in any new technologies introduced into the application. If a developer goes on vacation, you will want to make sure someone else can quickly and effectively fix any issues that may come about.
Tip #10: Carefully evaluate uncommon or more obscure technologies. With the added complexity of a microservices architecture, the last thing to worry about is whether or not there are any hidden issues as a result of a new technology.
While this list is not comprehensive, it should serve as a good launching point when making the transition to microservices. If you have experience with making this transition, we would like to swap notes. You can leave a comment, or you can email us email@example.com.