Black Friday and Cyber Monday are a shoppers’ delight and many retailers’ busiest time of the year. For Hudson’s Bay Company (HBC), which owns and operates Lord & Taylor, Saks 5th Avenue and several other brands, last year’s holiday rush turned out to be the perfect time to try out new web site features.
HBC uses a fairly typical Oracle WebLogic application server and an ecommerce platform named Blue Martini from RedPrairie. Basically the stack has been developed and refined over the years. It worked but it was “hard to deploy to, hard to change and … hard to upgrade,” said Matthew Pick, who manages an infrastructure engineering team at HBC and spoke about the company’s digital transformation at a conference hosted by cloud vendor Joyent earlier this year.
So HBC engineers started to explore how they could address these issues. Microservices and containers turned out to be the answer.
Pick and the engineering team chose the Product Detail Page (PDP) as a first place to start their replatforming project. The PDP is a piece of the ecommerce app that houses product descriptions and images. Instead of the PDP being embedded in the app, HBC developers broke it up into 12 separate microservices, each one hosted in application containers (one loads the image, another serves the text, etc.).
Pick saw a number of advantages to switching to a microservices-based design: upgrades would be easier to develop and push, and troubleshooting problems would be more streamlined. For example, with microservices, if the price reporting feature goes down, the problem is (theoretically) contained to that one service and the team responsible can fix it. Embracing containers and microservices is also part of a broader strategy to support mobile viewing and responsive design.
When it came to launch the new PDP during Black Friday/Cyber Monday last year, HBC did a dark launch, meaning only a portion of the company’s traffic was sent to the PDP microservices. If there was a problem with the new approach it could be shut off and all traffic would be handled in the traditional fashion. “We didn’t set the whole site on fire,” said Pick, who recalled working the entire Friday through Monday after Thanksgiving last year monitoring the launch. “At some point with new technology you just have to say, ‘let’s try it.’”
Pick and HBC are one of a growing number of organizations that are experimenting with applications based on microservices architectures. It’s a trend that’s gained significant steam in the past two years, driven by a desire of application developers to write and deploy new code faster and more easily manage complex apps. But like any new technology, microservices come with their own set of challenges.
What are microservices?
There are many ways experts describe microservices, but no single agreed upon definition. Basically, it’s the idea that instead of building monolithic applications, developers build a series of components that make up the app. IDC analyst Al Hilwa describes microservices as “a more granular software architecture in which application components are designed and evolved independently.” The components are stitched together using common APIs. Basically, an app or service is broken up into many different components and glued together with APIs.
Sound familiar? Microservices harken back to a buzzword of yesteryear: Service Oriented Architecture (SOA), which is the idea of building components of an application separately.
“Enterprise interest in microservices is driven by looking for a next generation approach to service oriented architecture, as well as the use of microservices with containers,” says David Linthicum, senior vice president at consultancy Cloud Technology Partners.
While they’re similar, most experts say SOA is typically more limited to a single programming language and development environment using more traditional infrastructure components. Microservices represent a comparatively more agile methodology of developing complex applications made up of small, independent processes. Microservices that make up an application can be written in different languages, communicating with each other using standardized APIs and hosted on next-generation infrastructure, such as in virtualized or public cloud environments while using application containers.
Advantages
The microservice approach offers a number of advantages:
- Agility: By decoupling the components of an application, each individual part can be developed independently. “You no longer have to move your entire dev team in lock-step,” says Sid Sijbrandij, CEO of startup GitLab, which is a code repository that competes with GitHub. Instead of having a 100 people working on a single app, you could have 10 teams of 10 people each developing components of the app and deploying new features when they are ready. Instead of having scheduled updates and waiting for the entire app to launch, new features are launched as soon as they’re ready.
-Graceful degradation: If one component of the app fails it doesn't take down the entire app. “The goal is to minimize the blast radius of fails,” explains 451 Research analyst Donnie Berkholz. For example, if a bank’s site is built using a microservices approach, if the transfer money feature is broken, customers would still be able to check their balances. When services are independently built and deployed, then – theoretically -- if one service goes down it will not impact the others.
-Reduced synchronization across development teams. In a microservices architecture development teams create the pieces that make up an application independently of other teams. Each of those sections writes to a common API that all the components integrate with. Having development teams focus on just a single part promotes good coding practices, Sijbrandij says; single function teams become experts in that function.
However, actually building microservices-based applications may be easier said than done.
Challenges
Berkholz, the 451 Research analyst, says teams that have embraced an agile or devops mindset are more likely to succeed in building microservices applications. Devops is the practice of uniting developer and operations functions – literally or in some team-based fashion.
In these environments, code is written quickly, tested and deployed rapidly. Many devops shops have embraced an automated, self-service infrastructure, such as a highly virtualized or cloud environment for test and development or production-grade apps. 451 Research studies show that two-thirds of organizations have adopted agile methodologies for application development and about 40% use devops. Those are the organizations that Berkholz says are the most likely to succeed with microservices. Organizations that have not adopted these next-generation application development trends may find a transition to microservices more difficult.
Typically in these agile and devops shops, application containers are being used. For Pick at HBC, he said containers and microservices are symbiotic. When you break up a monolithic application into components, running those services in containers allows application developers and the infrastructure operations team to be on the same page. Developers know to package the app in a container and the operations teams prepare the infrastructure to run containers.
There are other infrastructure implications too for microservices. Forrester analyst Dave Bartoletti says the role of IT infrastructure inherently changes when developers in their organization begin embracing these trends.
“Developers who build microservices will not go to IT and file a ticket for new VMs,” he explains. Agile developers have an expectation that infrastructure resources are available on demand, via an API and elastically scalable.
There are, of course, plenty of tools available to support that type of infrastructure environment. Private cloud software from VMware or OpenStack can be used to build an internal cloud. And public cloud platforms from Amazon, Microsoft, Google and others are available if IT doesn’t want to build out the infrastructure themselves. A PaaS platform from Cloud Foundry or Red Hat can be used to automate infrastructure control. So-called ‘serverless’ computing platforms are ideal for event-driven applications, such as those in Internet of Things use cases. Fundamentally with each of these platform changes the role of IT shifts from provisioning infrastructure to setting up the environment that developers can deploy microservices on to themselves.
What microservices are best for
Not all apps will benefit from a microservices architecture. The app has to be complex enough that it can be broken into a number of different components, Berkholz says. If it’s a straightforward app that does a single function (think of a marketing campaign with a single website that will only be live for a number of weeks), then there’s likely no need for microservices. A complicated app with many components, such as one built to handle streaming Internet of Things data, could benefit from being developed and managed as individual components.
For Pick and HBC, the transition to microservices has been successful, but it’s a slow process. For the foreseeable future, Pick plans to manage a combination of applications built using containers and microservices and other systems, such as certain databases and other legacy platforms, that will take longer to transition. “Now that the PDP has been successful, we’re building everything out to microservices,” he says. “But that takes time.”
It’s important to consider which functions of an application will be broken down into components. Ahmar Abbas, vice president of global services at consultancy DISYS says it’s helpful to have the various microservices components operate relatively independently of one another. Components that need to share data or transfer data can actually slow down an app made in a microservices style.
“If inter-component communication is longer than the actual processing time of the components, then your app will lose a lot of efficiency,” he says. It’s best to design the components of the system so that no single component is completely reliant on the other to run. This will help improve efficiency and allow each function to scale up and down independently.
Berkholz says that’s one reason why microservices are typically used to build out new applications or new components of a service. “There can be a very high cost of transitioning existing apps,” he says. “It can be a lot easier to buy into the benefits when you don’t have a switching cost.”