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

2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 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 AJAXWorld RIA Stories
In his session at 21st Cloud Expo, James Henry, Co-CEO/CTO of Calgary Scientific Inc., introduced you to the challenges, solutions and benefits of training AI systems to solve visual problems with an emphasis on improving AIs with continuous training in the field. He explored app...
Data is the fuel that drives the machine learning algorithmic engines and ultimately provides the business value. In his session at Cloud Expo, Ed Featherston, a director and senior enterprise architect at Collaborative Consulting, discussed the key considerations around qualit...
"DivvyCloud as a company set out to help customers automate solutions to the most common cloud problems," noted Jeremy Snyder, VP of Business Development at DivvyCloud, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY...
"Our strategy is to focus on the hyperscale providers - AWS, Azure, and Google. Over the last year we saw that a lot of developers need to learn how to do their job in the cloud and we see this DevOps movement that we are catering to with our content," stated Alessandro Fasan, He...
"Akvelon is a software development company and we also provide consultancy services to folks who are looking to scale or accelerate their engineering roadmaps," explained Jeremiah Mothersell, Marketing Manager at Akvelon, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct ...
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