Modular software creates agility — and complexity

With its 11 sprawling theme parks, 47 resorts, 13 vacation properties and four luxury cruise liners, The Walt Disney Company isn’t exactly known for thinking small. But the multinational entertainment juggernaut is making an exception when it comes to application design.

Disney is one of an increasing number of companies to embrace microservices as an innovative approach to application development. Essentially, microservices involves designing software applications as small packages of independently deployable services. By building these self-contained components, CIOs can get innovative services to market more quickly, easily and affordably.

“Microservices is about building higher-quality, complex systems and evolving them faster and more cost-effectively,” says Al Hilwa, an IDC analyst. “The key principle is to [break down] the system into functional components that are small enough to be worked on by small teams.”

IDC

Al Hilwa

But while modular software design is a hot trend, many observers question whether microservices have much practical real-world utility. After all, breaking down systems into tiny, modular pieces can add layers of complexity to an IT environment. Some question the impact that microservices’ moving pieces can have on an IT team’s productivity, while others caution that making microservices work requires organizational and cultural adjustments.

“We’re seeing too many people jump on the bandwagon before getting ahold of some of the core concepts and capabilities that you need before moving to full-on microservices,” warns Molly Bartlett Dishman, a senior consultant at ThoughtWorks, a global IT software consultancy.

IT complexities and cultural adjustments haven’t dissuaded Disney from testing a microservices architecture. The company’s first modular project is dubbed Public Cloud Manager. Launched in September, Public Cloud Manager is an auditing tool that allows users to determine if their services and applications are in compliance with Disney’s public cloud security policies.

Developed with the assistance of IT management consultancy Clutch, Public Cloud Manager represents a significant departure from Disney’s traditionally monolithic approach to building tightly coupled services.

“Microservices is about isolating parts of the products, and pieces of code, so that changing one piece of the architecture does not require us to re-release all of it,” says Clay Garrard, senior manager of cloud services and architecture at Disney. As a result, he says, a microservices approach not only “frees up release processes,” but it also eliminates “giant integration tasks at the end of every month.” Instead, he explains “we can move to weekly releases, even subweekly releases for pieces of the system.”

In the past, traditional software development techniques made adding new features to an application a “very slow and cumbersome” process, says Owen Garrett, head of products at Nginx, a provider of Web acceleration and delivery technologies. As a result, he says, “Organizations used to do big-bang releases only every four weeks or every three months.”

The sum of the parts

Microservices is changing all that by breaking down systems to a more granular level so that companies like Disney can churn out releases and updates with greater speed and agility.

“If you want to push updates from applications out quickly in a safe and managed way, you need to break that application up into little separate components that each run independently and perform a particular task,” says Garrett. “Then you can update each of these components individually without having to update the entire application in one go.”

Considering the fact that large applications may undergo tens or hundreds of updates in a single day, the ability to update components individually is good news for companies like Wix, a Tel Aviv-based provider of a cloud-based development platform for building websites and applications, with 70 million users worldwide.

Wix began with a monolithic architecture, but it wasn’t long before the company’s developers began asking to work on different parts of code for various services. To accommodate that divide-and-conquer approach to app development, Wix turned to microservices.

Wix

Gregory Man

“If you have one team working on one application and everybody knows the code, it’s OK,” says Gregory Man, a manager on Wix’s systems team. “But when you grow as a company, and your code base grows, it’s a good time to consider microservices so that each team can develop parts independently.”

This strategy of continual delivery allows Wix developers to easily deploy new services themselves. It also minimizes the amount of troubleshooting required to deal with bad code or technical glitches.

“The smaller the change you make in production, the less the chance of massive damage,” says Dimitri Krassovski, Wix’s systems team leader. “If you have releases once per week, you have a whole week of code that could be causing the problem. However, if you release daily, you only have changes from one day to blame.”

Collaboration is key

While a microservices architecture may yield speedy deployments, reduced maintenance and greater productivity, it’s hardly a magic bullet for system design. “There are a lot of core capabilities that are necessary before you can consider whether microservices is even good for your company,” warns Dishman, explaining that your team must be ready to constantly monitor and test systems, ensure continuous delivery of applications and understand how applications work in various environments.

Thoughtworks

Molly Bartlett Dishman

In addition to technical competencies, organizational adjustments are often necessary when moving to a microservices approach. After all, breaking apps and systems into small components, and assigning disparate teams to the various segments, requires developers and operations teams to work together to manage the moving parts.

“If your organization as a whole takes more of a ‘toss it over the fence and let operations deal with production’ approach, the more services you have, the harder that becomes,” says Garrard. “So a microservices architecture really puts a lot of stress on these relationships, requiring the organization to be more integrated.”

For Disney, the answer is a DevOps culture of collaboration in which developers and their operations people work closely together, pooling resources and taking equal ownership for an app’s journey from design to deployment.

“We operate in a DevOps culture — that’s a critical part of my team’s processes,” says Garrard. “I think it would be challenging to make a microservices architecture work in a traditional operations culture simply because of the number of services.”

However, persuading developers and operations teams to embrace microservices is another story. “These conversations with operations are definitely a challenge,” says Garrard. “It requires a conversation with them and a little bit of a shift in how we do things. But ultimately, they see the value of it.”

Find the right talent

Complicating matters further is the fact that “it takes a certain personality and a certain background” for an employee to thrive in a microservices-friendly DevOps environment, according to Krassovski. Part of the problem is that “the right set of skills isn’t taught in university,” he says. “Usually, university graduates are good developers, but they don’t know the system side” of creating and updating apps — key requirements for working on a more granular, modular level. As a result, organizations like Wix often struggle to find workers with the necessary skills to manage a microservices architecture.

Wix

Dimitri Krassovski

Fortunately, it is possible to train IT staff in microservices processes and familiarize them with the DevOps culture, says Garrett, of Nginx. “Most IT staff I’ve spoken to are hungry to learn new skills, to grow their professional experience and to take more responsibility,” he says. “A DevOps route is a great career path for a smart engineer if he or she wants to take more responsibility for a key part of a business’s applications.”

Manage the chaos

Another challenge of working with self-contained components is that system parts and processes can easily run amok. At Wix, for example, the microservices architecture includes many intercommunicating processes, which generate an enormous amount of internal traffic between services. Such a setup can be prone to problems.

“The challenge you have when you deploy all these moving parts is connecting them together to create a single coherent application,” says Garrett. “One of the risks . . . is that you can end up with a fragile, fragmented application, and it can be difficult to track and manage the communications between these different components.”

To deal with those challenges, Wix uses the Nginx Plus platform, an intelligent traffic gateway tool designed to use sophisticated load-balancing methods to automatically route and distribute traffic across multiple servers. Nginx Plus makes it easier to manage Wix’s microservices environment, and the decline in management challenges leads to greater stability and improved uptime for the company’s customers.

Don’t go overboard

Another risk posed by microservices: Breaking systems and applications into components almost makes it too easy for companies to deliver new releases. Imagine an artist who never knows when it’s time to stop adding brushstrokes to a masterpiece. Overzealous developers may do the same in a microservices environment.

To minimize the risk of over­iterating, some companies limit the number of releases that are allowed per application per week. At Wix, however, Krassovski says there’s a strong “culture of A/B testing everything” to ensure that only worthwhile modifications are made.

“Every feature we add, even the smallest change we make in production, goes through a period of A/B testing,” he says. “Then we compare key performance indicators and the winning version continues. We don’t deploy features blindly, so there’s really not a big chance of overdoing it.”

In fact, Disney’s Garrard says that while a microservices environment has more parts to manage, the “surface area” of the moving pieces is actually more manageable than those of large systems. “It’s easier to monitor each of the smaller microservices and make sure that they’re all functioning as they’re designed to, as opposed to these giant monolithic systems where there are so many different inputs and outputs that it’s difficult to tell the true status of the system,” he says.

Nevertheless, not all systems are right for a microservices environment. “There are plenty of applications that are built to solve a very particular business need and don’t need to be changed,” says Garrett. “In that case, a traditional development approach will work perfectly.”

Garrett cites a standard service, like weather reports, as a prime example of a static application that’s unlikely to benefit from a modular approach. Other factors to consider when assessing a move to microservices include your organization’s technology stack and the skill set of the team responsible for designing the application.

Take it slow

It’s wise to be cautious about embracing microservices.

For example, although Disney has recently launched its first product using microservices processes, the company has no plans to retrofit its existing apps and systems.

“We need to continue to move forward technically and to stay abreast of industry changes that require real effort and investment,” says Garrard. “But you don’t decide to retrofit that investment until you’re sure that it works. So this is an attempt on our behalf to realize some gains. I fully expect that we will, but until that’s proven out, I couldn’t cost-justify retrofitting our existing system.”

Until then, more and more organizations are likely to embrace microservices architectures — and they will be discovering new ways to tackle its challenges, including cultural upheavals, added layers of complexity and the temptation to tinker.