Introduction
Microservices were once an alternative to monolithic application architecture. They presented a new mode of development with its own set of risks and rewards. Now, we are reaching a tipping point where it’s no longer a question of whether to migrate, but when to migrate. However, migrating is a challenging process that can pose problems if executed poorly. This post will cover why microservices are necessary, the challenges of migrating to microservices, and how to devise a plan for migration.
Reasons to Migrate
Much of the conventional wisdom around microservices has suggested starting with a monolithic application and migrating to microservices once the application has grown to an unmanageable size. However, the larger a monolithic application becomes, the harder it is to decompose it. As such, companies should consider planning early on to ensure that they are prepared for both their own growth and changes to mobile infrastructure.
Your company’s growth
Microservices are particularly important as applications grow and scale. For monolithic applications, scaling can be extremely costly, requiring a one-size-fits-all approach that cannot address specific bottlenecks without accruing underused resources. In addition, changes to a monolithic application require a new build to deploy. This can stymie innovation by limiting the new features introduced and make it harder to fix bugs, resulting in downtime and cutting corners that result in technical debt.
An article from TechBeacon interviewed executives from Wix.com, Best Buy, and Cloud Elements, whose reasons for migrating to microservices included:
- Difficulty scaling
- Lengthy deployment of new features
- Technical debt
- Downtime
- Large dependencies
In addition, as 5G mobile networks become increasingly pervasive, a microservice model will be not only advantageous, but crucial for companies of every size.
5G readiness
5G adoption is already accelerating worldwide, with mobile service providers not only upgrading LTE networks with 5G New Radio technologies, but creating new infrastructure deployments with 5G core architecture. 5G core improves upon LTE by leveraging architectural principles that demand the use of microservices, including control and user plane separation (CUPS) and network slicing.
These principles require modular design for the most agile delivery possible. Network slicing creates multiple virtual networks grouped by SLAs in order to prioritize mission-critical services and ensure a wide variety of performance metrics. Network slicing is aided by CUPS, which allows the control and user plane to be housed in different locations and scaled independently. In order to meet 5G’s architectural demands and efficiency, however, Oracle VP John Lenns noted in an interview that “operators are now asking for microservice-based deployments” where “only those microservices that are needed for that particular offering at that particular time will need to be turned up.”
Challenges of Migrating
Despite the benefits of migrating to a microservice structure, it does pose some business and technical challenges. During a company’s transition, there may be some overlap, creating headaches as they figure out how to run monolithic applications in parallel with microservices. In addition, issues may occur with changing company culture, finding a platform, and addressing specific technical issues like breaking up databases.
Company culture
A longstanding principle known as Conway’s Law notes that applications tend to take on the organization of the company that built them. This means that changing the organization of your application from a monolith to one organized around specific business functions will require changing your company’s organization as well. In addition, the technical diversity of microservices may make it more efficient for teams to use different programming languages or database solutions. Kristen Womack, former senior product manager at Best Buy, spoke to the difficulty of this change in her interview with TechBeacon, stating, “Cultural resistance to how software is built and deployed is to be expected,” and noting it’s “especially challenging when it changes how people do their jobs.”
Finding a platform
Microservices provide companies with greater flexibility in which technology they use to deploy different modules, but this can present its own difficulties. Although many companies look to Kubernetes for orchestrating container-based solutions, a February 2020 Forrester report noted that Kubernetes is not a cohesive platform. Instead, it is more like “a growing box of Lego blocks to build whatever application platform core you need.” As a result, many companies may ultimately use multiple platforms tailored to the needs of specific microservices, which may evolve over time as different services are added, changed, or replaced.
Technical challenges
In addition to the business considerations inherent in transitioning to microservices, certain technical challenges present themselves. Breaking up a monolithic application generally means breaking up a monolithic database so there is one database per microservice. A recent article from IBM notes that this is a difficult task because monolithic databases do not have clear boundaries where different objects map to different functionalities. In addition, breaking up a database involves tackling distributed transactions and complications with reporting across services.
Because of the challenges inherent in migration, it’s important that companies take stock of their resources and needs so they can devise a strategy for migration. This strategy should not only include long and short-term plans for modernization, but choosing a partner that can assist them on this journey.
Devising a Plan for Migration
Long term
An October 2020 report on application modernization from Forrester provides a good summary of long-term changes that will need to be made to a company as a result of application modernization. In addition to changing the company culture and restructuring teams around different microservice products, the report suggested that modernizing may require acquiring new talent, using new metrics to assess business value, adopting new processes like CI/CD, and embracing new technology for infrastructure automation.
The enormity of this task makes it all the more necessary to avoid refactoring all at once. A recent InfoQ article on migration listed this as one of the key takeaways, noting that positioning modernization as a project with a set start and end date is dangerous, as it can grind new development to a halt. Instead, it recommended that businesses “Find out where your hotspots are, your biggest bottlenecks or other challenges, and peel those out first, one by one.”
Short term
While it’s widely accepted that migration should be an incremental process, advice on where to begin varies widely, as it largely depends on the specific application. However, certain factors can influence this decision, such as the company’s user base, code, and resources.
Evaluating your application
One of the most important considerations for which service to begin with is figuring out which would be easiest to undertake. Since teams will not only be changing their code, but adjusting to changes in company culture and organizational structure, starting with an easy process may be beneficial. Services can be more easily separated from the monolith if they:
- Have few dependencies
- Cleanly separate from the database
- Can be easily tested
- Are not mission-critical
Evaluating your users
A March 2020 Forrester report on microservice reference architecture neatly summarized the necessity of considering not only an application’s code, but its users in determining how best to decompose an application. It notes that, “not only do individual microservices vary in design, but also specific combinations of quality-of-service characteristics, usage patterns, and business considerations may be unique to individual business domains.” As a result, companies may need to make design tradeoffs in terms of QoS, security, availability, and scalability, and should consider the following:
- What are your industry’s security requirements?
- How much downtime flexibility do you have?
- What are your app’s usage patterns?
- What quality of service do your users expect?
Answering these questions can also help you determine which services would add the most value to your application, ensuring that the time you invest provides the best possible return on investment.
Evaluating your resources
Two resources that are needed to transition to microservices are money and talent. In terms of cost, companies must be prepared to shoulder not only the cost of new tools and monitoring software, but the hours developers will need to spend learning how to use those tools, as well as the time they spend on the migration itself. The more hours spent on the migration, the less time there will be for developing new features and functionality. In addition, new team members may need to be hired to fill in gaps in expertise. As such, businesses can evaluate what resources they have available for their microservices journey by considering:
- What are your developers’ skill levels and areas of expertise?
- What new skills will need to be learned?
- What new tools will you need to acquire?
- What are the total costs in terms of developer hours, tools, and hiring new talent?
Companies should take these expenses into account to avoid being blindsided by costs partway into a project. In addition, considering the full cost of developing new microservices can help companies in choosing a partner to help with migration.
Finding a Partner
While open-source tools abound for helping with microservices, assembling a platform (or multiple platforms) from these individual elements may prove highly costly due to the time and skill needed to implement them. Finding the right partner to assist with transitioning can help companies to overcome challenges and ensure that microservices add as much value as possible to their application.
Azion’s Edge Functions simplifies the migration process through a serverless approach that reduces operational complexities; as a serverless provider, we take care of server-side security, scaling, and infrastructure management, allowing you to focus on front-end development. Clients pay only for the time their functions run, reducing upfront costs and wasted resources. The next post in this series will look at app modernization through a wider lens, examining the various strategies for modernization, from minimally invasive methods like “lift and shift” rehosting to more intensive methods such as rebuilding and replacing.
