Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
SYS-CON.TV
Cloud Expo & Virtualization 2009 East
PLATINUM SPONSORS:
IBM
Smarter Business Solutions Through Dynamic Infrastructure
IBM
Smarter Insights: How the CIO Becomes a Hero Again
Microsoft
Windows Azure
GOLD SPONSORS:
Appsense
Why VDI?
CA
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
ExactTarget
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun
Sun's Incubation Platform: Helping Startups Serve the Enterprise
POWER PANELS:
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
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.

About 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.

Latest Cloud Developer 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...
Cloud computing delivers on-demand resources that provide businesses with flexibility and cost-savings. The challenge in moving workloads to the cloud has been the cost and complexity of ensuring the initial and ongoing security and regulatory (PCI, HIPAA, FFIEC) compliance acros...
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 ...
"MobiDev is a Ukraine-based software development company. We do mobile development, and we're specialists in that. But we do full stack software development for entrepreneurs, for emerging companies, and for enterprise ventures," explained Alan Winters, U.S. Head of Business Deve...
While some developers care passionately about how data centers and clouds are architected, for most, it is only the end result that matters. To the majority of companies, technology exists to solve a business problem, and only delivers value when it is solving that problem. 2017 ...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021



SYS-CON Featured Whitepapers
ADS BY GOOGLE