Making the shift to microservices: 8 tips

The development of new applications today is all about speed of delivery. The broad movement toward the agile environment that’s been underway for several years has fostered a sense of easy and rapid deployment of software.

One of the technology trends that’s helping accelerate application development is the rise of microservices — and IT leaders at a variety of businesses might want to consider this software development technique for their organizations, if they haven’t already.

Microservices are a variant of service-oriented architecture (SOA) that structures applications as collections of loosely coupled services. Among the benefits of breaking down applications into smaller services is that it improves modularity, making applications easier to develop and test.

“Microservices increase team empowerment and reduce coupling, allowing individual teams to innovate faster, reduce cross-team communication, and feel empowered to make their own decisions regarding architecture, language, and frameworks,” says EJ Campbell, vice president of engineering, sports and media production engineering at Verizon Media Group, a subsidiary of the communications company comprised of 50 online brands.

“We’ve seen the cycle time from commit to production reduce dramatically as teams adopt microservices,” Campbell says. “Many teams deploy microservices multiple times per day without any human intervention, relying on tests, code reviews, and sophisticated CI/CD [continuous integration/continuous delivery] pipelines to ensure safe delivery of changes.”

The company’s Yahoo Daily Fantasy Product comprises several microservices, including a core gameplay service, a sports data service, a wallet service, and several supporting internal services. “Each of these services has its own continuous deployment pipelines, isolated data stores, and individual teams responsible for its development and operation,” Campbell says.

Organizations might encounter a number of challenges when using microservices. These include determining the right boundaries between services, overcoming the difficulty of sharing code between teams in a microservices environment, and the complexity of change management because teams are releasing code independently.

The move to microservices represents a sea change, and organizations need to be prepared for such a big shift.

“Evolving to microservices is like evolving from the horse to the bicycle, or from the bicycle to the automobile,” says Jay Bercher, deputy program manager at Solutions By Design (SBD), a provider of

marketing, communications, and technology services that’s working with federal agencies as they transition to a microservices-based IT approach.

“As we go through the stages of evolution, we find even more moving pieces,” Bercher says. “Each moving piece requires its own level of maintenance, and the support and supervision of so many elements not only makes the solution more complex, but also increases associated costs. Consequently, we have to scrutinize our decisions to ensure they are not only the best technological decision, but cost effective as well.”

Another challenge is security. “We have to determine whether we want to implement a single verification solution across the entire application, or if we want each microservice to have its own verification process,” Bercher says. “This is a decision that must be made on a case-by-case basis and one that each project team needs to make on its own.”

Here are some suggested best practices to address challenges and thrive in a microservices environment.

Employ domain-driven design

Creating microservices is about making services loosely coupled and applying the single responsibility principle, Bercher says.

“While there are various methods and methodologies for development, domain-driven design and microservices appear to be a perfect match,” Bercher says. Teams at SBD use domain-driven design, a thematic approach to building an application that creates an efficient development pattern that removes most team interdependencies.

“In our work, the correlation of domain to microservices is essentially one to one,” Bercher says. “So, each development team is responsible for a domain and also responsible for developing the corresponding microservice. This creates a clear delineation of responsibilities, which in turn limits redundancies that can occur in parallel development efforts.”

Establish guidelines for code libraries

It’s much harder to share code between teams in a microservices world, Campbell says.

“Unlike a monolith, where common code is just a method call away, with a microservices architecture commonality must be factored into an independent service or the code must be packaged into a shared library,” Campbell says.

Adoption of these libraries is often slow, and making changes requires coordination between the library owner and multiple services. “Therefore, it’s important that organizations adopt a robust set of guidelines for common libraries and expectations on rollouts,” Campbell says.

Don’t share databases between microservices

“In building our decoupled services, we are allowing our development teams to build their own database that feeds our [back-end systems], which limits dependencies from other development teams,” Bercher says.

“Our development teams push their writes to the backend for everyone else to absorb, and this information is then managed by our data team,” Bercher says. “This continues with the plug-and-play concept. If you need to replace a service, you simply pull it out and plug in the new one. It’s like changing a light — just slightly more complex.”

Because microservices are modular by design, the development process is predominantly plug-and-play, making it extremely easy to troubleshoot any issues that might arise.

“Because code isn’t propagated across the entire platform, we can quickly isolate issues to a specific source and then track them within the microservices,” Bercher says. “This makes it easy to update applications by allowing for piecemeal updates and upgrades per microservice. Can you imagine upgrading a system a piece at a time instead of a wholesale replacement? This concept alone revolutionizes system development.”

SBD has development teams in different locations across the United States that enhance the benefits of microservices. Team members in Charleston, S.C., have a greater level of development independence because they are developing their own microservice that plugs into a solution.

Address the security concerns

As with anything else related to IT, microservices have their own security issues.

Companies should scan for known vulnerabilities early and frequently in the software development lifecycle, says Ryan Douglas, CIO at Digital River, a provider of ecommerce, payments, and marketing services.

“An important mantra for any IT team operating in our fast-paced world is identifying and fixing vulnerabilities of home-grown solutions as well as third-party software,” Douglas says. “It is essential for maintaining security. It’s critical to take a big-picture approach to the software ecosystem to understand how it works together and where potential problem areas reside.”

Software patch deployment is much easier to test when using microservices, Douglas says. “And it’s not just for home-grown code,” he says. “IT engineers can test third-party software for vulnerabilities alongside their own software development. In the event that a vulnerability is found, a fix can be deployed more quickly than with previous monolithic code structures.”

Avoid entanglements

Entanglements can occur all too easily in large microservices deployments, says JP Morgenthal, CTO for application services at DXC Technology, an IT services provider that was formed following the merger of CSC and HP’s enterprise division.

“There can even be recursive data paths if organizations are not careful about ensuring that there is a system architecture” driving the use of microservices, Morgenthal says. “Between the use of independent cross-functional teams and service repositories, it’s possible to see dependencies appear that would cause the system to invalidate the tenets of microservices,” he says.

A single microservice should be able to be changed or removed without significant impact to the system as whole. A best practice is to engage enterprise architecture to validate microservices designs, Morgenthal says.

Consider building applications from scratch

Vylla.com, a direct-to-consumer mortgage platform launched by real estate services provider Carrington Mortgage Holdings, recently moved its technology architecture to microservices.

“One of the challenges we encountered when we decided to migrate to microservices was whether or not to break the application up piece-by-piece or perform a full rewrite,” says John Nicholas, Carrington Mortgage’s CTO.

“Due to some pre-set business requirements, we needed to deliver new functionality in a very short timeframe,” Nicholas says. “At first, we attempted to integrate into the monolithic architecture with successful results. However, we also knew that breaking it apart would prove to be more difficult than rewriting most of our current features.”

With this in mind, the development team decided the best path forward was to build a new application from scratch. “It was a huge task and required massive efforts from all our team members, but it has already proven its worth in the short period of time since the transition,” Nicholas says.

Because there is a significant technology investment necessary to successfully deploy microservices, it’s important to have a clearly defined business case outlining how the new technology will enhance performance or improve operating efficiencies, Nicholas says.

“The critical component here is finding the right talent,” Nicholas says. “It’s not easy to find engineering architects who have the experience to get the job done. We have been able to build a strong engineering team that understands proper architecture and a strong quality assurance team to build automation testing around the application.”

Measure performance when scaling

Monolithic applications can be scaled in their entirety to meet a spike in demand by adding servers, says Praveen Kanyadi, cofounder of SpotCues, a company that provides productivity software using artificial intelligence.

“In the case of microservices, the modular architecture enables only parts of the system to be scaled,” Kanyadi says. “However microservices require a very different approach to scalability because a typical microservice architecture deployment may consist of multiple components running on different servers and virtualizations working together.”

This adds the challenge of identifying which individual components to upscale. “This is where measuring performance becomes critical, and tools such as an application delivery controller can help measure and detect performance issues,” Kanyadi says.

Companies should also consider defining service level agreements (SLAs) for each microservice for performance and reliability, based on business priorities, Kanyadi says.

Focus on change management

Companies need to update change management and change control processes, along with supporting documentation, to benefit from the change from monolithic to microservices architecture.

“A faster development process is great, but don’t lose the benefits of microservices by leaving out change control and other important governance processes,” says Ron Hayman, chief cloud officer at Avant Communications, a provider of cloud services for the IT channel sales market.

“Ensure that you align change control and the approval process to match your agile development lifecycle,” Hayman says.