Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Zakia Bouachraoui, Pat Romanski, Elizabeth White, Liz McMillan

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
Hackers took three days to identify and exploit a known vulnerability in Equifax’s web applications. I will share new data that reveals why three days (at most) is the new normal for DevSecOps teams to move new business /security requirements from design into production. This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 4th annual State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis.Attendees can join this session to better understand how DevSecOps teams are applying lessons from W. Edwards Deming (circa 1982), Malcolm Goldrath (circa 1984) and Gene Kim (circa 2013) to improve their ability to respond to new business requirements and cyber risks.
DevOpsSUMMIT at CloudEXPO, to be held June 25-26, 2019 at the Santa Clara Convention Center in Santa Clara, CA – announces that its Call for Papers is open. Born out of proven success in agile development, cloud computing, and process automation, DevOps is a macro trend you cannot afford to miss. From showcase success stories from early adopters and web-scale businesses, DevOps is expanding to organizations of all sizes, including the world's largest enterprises – and delivering real results. Among the proven benefits, DevOps is correlated with 20% faster time-to-market, 22% improvement in quality, and 18% reduction in dev and ops costs, according to research firm Vanson-Bourne. It is changing the way IT works, how businesses interact with customers, and how organizations are buying, building, and delivering software.
The benefits of automated cloud deployments for speed, reliability and security are undeniable. The cornerstone of this approach, immutable deployment, promotes the idea of continuously rolling safe, stable images instead of trying to keep up with managing a fixed pool of virtual or physical machines. In this talk, we'll explore the immutable infrastructure pattern and how to use continuous deployment and continuous integration (CI/CD) process to build and manage server images for any platform. Then we'll show how automate deploying these images quickly and reliability with open DevOps tools like Terraform and Digital Rebar. Not only is this approach fast, it's also more secure and robust for operators. If you are running infrastructure, this talk will change how you think about your job in profound ways.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.