Microservices Management
Loosely coupled. This term appears frequently when describing microservices architecture, but is it a term that can be applied with equal gusto to management? And should it? Our answer is yes, both within IT operations and the Executive. There is a distinct need for clear, proactive end-to-end ownership of the sprawl that accompanies this new production environment; one that is different from what came before in the monolithic model. Microservices requires teams to work on their individual pieces of the puzzle in a polyglot and modular environment, and yet someone must still be able to see the entire picture and direct things accordingly.
As numerous online case histories will show, there is great practicality in embracing microservices as a technology. It uses loosely coupled independent elements in place of the tightly coupled structure of its predecessor, and this corresponds extremely well with today’s high-speed customer focused marketplace.
Microsoft Azure, in a multi-authored article posted in February 2017, describes the benefits of microservices this way:
Each one typically encapsulates simpler business functionality, which you scale up or down, test, deploy, and manage independently. One important benefit of a microservice approach is that teams are driven more by business scenarios than by technology, which the tiered approach encourages. In practice, smaller teams develop a microservice based on a customer scenario and use any technologies they choose.
From a project management and strategic executive perspective, this represents a significant change over the tiered technologies of the monolithic era in which customers/users were expected to adapt to the end product. The marketplace now demands instantaneous personalized response to self-initiated actions like searches, orders, and transactions, occurring through apps of all types, within both B2B and B2C marketplaces. Agility is now the name of the game. Business scenarios and customer scenarios now take priority.
However, Microsoft goes on to describe how “lots of chatty, granular services are a recipe for a performance nightmare. Without tools to help view these dependencies, it is hard to “see” the whole system.” This clearly identifies the need for an end-to-end management perspective and corresponding communications loop.
Take the retail and fashion industries as one of many possible examples. Jamie Anderson, Senior Vice President and Chief Marketing Officer of SAP Hybris, states:
We need to ensure those companies keep up with their customers’ demands. Fashion trends change fast and people want to buy things they can wear immediately…Traditionally, if you would want to add this kind of functionality, companies would need to engage their IT departments to build or integrate with a delivery process, which could take months to complete. But microservices are self-contained and have everything they need within them so you can add them to the app without messing around with the existing code.
Fashion and retail are not alone in suffering from a management mindset that is a few years behind the times, even when they try not to be. Today’s retailer must enhance the shopping experience through personalized CX. This must extend well beyond mobile-friendly websites to factor in customized payment and delivery options, native mobile apps, and a keen awareness of the value of collecting data at every step of the customer journey, including returns and refunds. This requires both a highly versatile compartmentalized platform and an end-to-end mindset that keeps one eye on the customer and another on the code.
Amazon, the eternal innovator, offers a key insight into end-to-end management, through its history of building its own brand of microservices since the early 2000s.
Rob Brigham, Amazon’s AWS Senior Manager for Product Management described, at a 2015 conference, the challenges they discovered as they broke down the monolith that was the Amazon retail website. They oversaw hundreds of development teams, whose individual single purpose functions had to blend into the development lifecycle.
We measured the amount of time it took a code change to make its way through [the] deployment lifecycle, across a number of teams. When we added up that data, and looked at the results, and saw the average time it took, we were frankly embarrassed. It was on the order of weeks. …Breaking down those actions helped engineers to realize that the sequence and arrangement of segments in this pipeline was leading to “dead time” — intervals where nothing was happening. This especially occurred in-between manual handoffs between departments — handoffs whose personalization was supposed to introduce process integrity, but which actually resulted, he said, in inefficiencies, wasted space, and long, long queues.
The purpose of an end-to-end management structure, both in IT-Ops as well as within the executive is to scope out those bottlenecks from a higher vantage point, without becoming a bottleneck itself. EBay, for example, describes its ecosystem of services model which seeks to “encode the knowledge of the smart experienced people in the review board and put it into something that’s reusable by individual teams.”
Mike D. Kail, CTO of Security-as-a-Service firm Cybric.io, adds a cautionary note: “Loosely coupled leadership and management is really only successful if there remains a high degree of alignment to ensure that everyone is progressing towards the common goal, which is typically revenue. I feel that too often ‘loosely coupled’ is incorrectly interpreted as “everyone can do whatever they want”, which certainly isn’t aligned.”
As such, it is essential that managers from IT-ops and from the C-suite implement a plan of action that oversees the full process from end-to-end and ensures that nothing drifts from the stated goal, paradoxically making full use of the relative independence of teams under their review.
By Steve Prentice
Sponsored series by Sumo Logic.
