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.