Welcome!

@DevOpsSummit Authors: Stefana Muller, Karthick Viswanathan, Yeshim Deniz, Liz McMillan, Zakia Bouachraoui

Related Topics: @DevOpsSummit, Microservices Expo, Containers Expo Blog, @CloudExpo

@DevOpsSummit: Article

Orchestrating Microservices | @DevOpsSummit #DevOps #Microservices

What does writing music have to do with software?

Orchestrating Microservices: Who's Composing This Symphony, Anyway?
by Les Worley

Before becoming a developer, I was in the high school band. I played several brass instruments - including French horn and cornet - as well as keyboards in the jazz stage band. A musician and a nerd, what can I say?

I even dabbled in writing music for the band. Okay, mostly I wrote arrangements of pop music, so the band could keep the crowd entertained during Friday night football games. What struck me then was that, to write parts for all the instruments - brass, woodwind, percussion, even keyboards - I had to have an overall score to work from. Or at least a sketch of one. Otherwise, I'd end up with a bunch of parts that might sound great on their own, but would never fit together to make someone want to listen or dance to it.

What does writing music have to do with software? The instruments and individual parts are like today's microservices: small methods each performing a discrete function. These are each well practiced (um, tested), so that they can stand on their own. With those pieces, API consumers can construct a larger solution - hopefully a real masterpiece.

Like each instrument and its part, a microservice has to be well constructed and tuned. But until it is combined with all the others, it's just a solo act. Who puts all the pieces together, in the right context and sequence, so your customer ends up with a symphony instead of a discordant mess?

Who determines if calling your API is a hit - or a flop?

The Musician (aka The Developer)
On one hand, a developer is like a musician. A French horn player, for example, coaxes a beautiful F-sharp out of his instrument. But playing a single note won't win any awards.

The agile developer is charged with writing a microservice at a time, to accomplish a narrow, well-define task. Yes, there's usually more than one service to be written within any API. But should that developer be the one to write the test bed that puts them all together, or even build one or more macro-services from them to accomplish a more complex operation?

Many developers can and will do this, to more thoroughly test the "big picture." But given that each microservice is built independent of others, it shouldn't be the developer's place to define how the independent pieces fit together. This would be like asking a woodwind player to write a drum solo or a horn quartet. Band and orchestra members may be excellent players, but you wouldn't ask some of them to write a song.

The Composer (aka The Architect)
Enter the software architect. An architect is like a composer. He or she first has an idea for an API service - whether it is an insight or a way to meet some business requirement. The idea gets fleshed out, broken down into its components. The architect constructs various scenarios for how the components might be used, as proof of the API's and its component microservices' value to prospective customers.

Those scenarios, use cases and interaction diagrams are like a composer's symphony. The notes and chords are the service interfaces, which by themselves make only a single sound. The architect, though, conceives how to put them all together, in the right order and timing, so they flow together naturally, with a pleasing result.

While this metaphor might be wearing a bit thin, the architect is a natural choice to dictate how the individual microservices should and should not be used. After all, they came up with the idea in the first place - the intended inputs and outputs, the allowable sequences, and the expected results.

The Conductor / Arranger (aka The Tester)
A composer isn't the only one that can create music from the raw components. A younger version of myself wrote a few pieces of his own, but more often I arranged my own unique versions, inspired by but different than the works of others. The same is true for every conductor. The same piece played another band and under different direction will sound totally new. Sometimes better, other times not so good.

Conductors and arrangers aren't unlike the testers that verify the APIs before release. Even if the architect has documented examples for "recommended use," APIs need to be tested in real-world surroundings. Testing microservices in unexpected and undocumented contexts can lead to making them behave better in those situations.

Testers also have a unique opportunity to define service orchestration. They often have tools available to them that others do not. Using API virtualization toolsets, for example, a tester can quickly and easily construct use scenarios that deviate from the original "happy path" vision. Think of these scenarios as "theme and variations," as new and unique arrangements of the original.

Whether the results are pleasing or distressing, they can harden the microservice API for the real world, not to mention providing documented examples for real users.

The Audience (aka, The Consumer)
To paraphrase a cliché, beauty is in the ear of the beholder. And in case of microservices, the beholder is your consumer.

Microservices gives the consumer more control over the construction and outcome of his solutions. Yet by giving them more granular control, you can't really be sure they will use them as you envisioned.

You could simply publish the API and hope the end users find it self-explanatory. But on their own, they will surely come up with some very ‘interesting" use cases. When they end up with a frustrating mess, you end up with more support issues. So It's always better to anticipate and test for the unexpected, so you can guide users in the right direction.

In other words, you don't want your audience - your consumers - having to figure out the orchestration on their own. You want to guide them through the most effortless performance possible. After all they're paying to enjoy the show, not to perform in it.

Fine (The End)
When it comes to orchestrating the use of your microservices, almost anyone can play the role. But some players are more natural fits than others.

The software architect, like a composer, has the original idea and knows the big picture behind it. It's natural that he or she should oversee and document "acceptable usage." Many developers are used to doing this in practice, since they often create dummy test harnesses for their APIs. (There are plenty of orchestra members out there that compose the symphony as well as star in it.) But the developer should be focused on crafting a microservice that does its job well, not on orchestrating its final use.

API testers and consumers can both come up with interesting variations and arrangements, quite different from what the architects and developers originally intended. Some of these might go well - like my own arrangement of the Star Wars Theme - but some might drive your your customer to frustration. And the last thing you want is for your audience to leave early and confused.

You can't force your consumers to orchestrate their solutions as you intended, but it's best if you try to anticipate their errant uses. Advanced testing tools, such as API virtualization, put your testers in a unique position to test a variety of "interesting arrangements." When provided as part of user documentation, these scenarios can provide your end users the guidance they need to best orchestrate their own ... masterpieces.

Who usually orchestrates and documents the proper use of your microservice APIs? The developers? The testers? Tell us about your experiences in the comments section.

More Stories By SmartBear Blog

As the leader in software quality tools for the connected world, SmartBear supports more than two million software professionals and over 25,000 organizations in 90 countries that use its products to build and deliver the world’s greatest applications. With today’s applications deploying on mobile, Web, desktop, Internet of Things (IoT) or even embedded computing platforms, the connected nature of these applications through public and private APIs presents a unique set of challenges for developers, testers and operations teams. SmartBear's software quality tools assist with code review, functional and load testing, API readiness as well as performance monitoring of these modern applications.

@DevOpsSummit Stories
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.
An edge gateway is an essential piece of infrastructure for large scale cloud-based services. In his session at 17th Cloud Expo, Mikey Cohen, Manager, Edge Gateway at Netflix, detailed the purpose, benefits and use cases for an edge gateway to provide security, traffic management and cloud cross region resiliency. He discussed how a gateway can be used to enhance continuous deployment and help testing of new service versions and get service insights and more. Philosophical and architectural approaches to what belongs in a gateway vs what should be in services were also discussed. Real examples of how gateway services are used in front of nearly all of Netflix's consumer facing traffic showed how gateway infrastructure is used in real highly available, massive scale services.
DXWorldEXPO LLC announced today that Telecom Reseller has been named "Media Sponsor" of CloudEXPO | DXWorldEXPO 2018 New York, which will take place on November 11-13, 2018 in New York City, NY. Telecom Reseller reports on Unified Communications, UCaaS, BPaaS for enterprise and SMBs. They report extensively on both customer premises based solutions such as IP-PBX as well as cloud based and hosted platforms.
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
Wooed by the promise of faster innovation, lower TCO, and greater agility, businesses of every shape and size have embraced the cloud at every layer of the IT stack – from apps to file sharing to infrastructure. The typical organization currently uses more than a dozen sanctioned cloud apps and will shift more than half of all workloads to the cloud by 2018. Such cloud investments have delivered measurable benefits. But they’ve also resulted in some unintended side-effects: complexity and risk. End users now struggle to navigate multiple environments with varying degrees of performance. Companies are unclear on the security of their data and network access. And IT squads are overwhelmed trying to monitor and manage it all.