Is interesting to see how so many people are writing about SOA technical details (communication protocol, best used language, etc.) but almost nothing is written about management and operations of such system.
What are then management requirements of SOA anyway you might ask? Well it depends from many constrains but if you are expecting to do real enterprise application then you have to prepare system to be at reasonably manageable. If your application is going to be SaaS subtype then application management is even more important (i.e. management cost is directly related to your expenses which means your net profit not to mentioned maintain high level of client satisfaction). Configuration and management mistakes can have profound impact on application stability; performance and reliability which at the end of day might render whole system look to your clients as unusable.
OK, management in SOA is important part of solution but what with it? How to realize it? Shall we follow same pattern as on services and decentralize it or shall we make some “logical” central point where management application or users are able work with it is?
My preference is to make configuration and management accessible from central place as this makes operations live much, MUCH easier and application much more stable from configuration and management point of view. With this approach you simply get all data on one place which makes process much easier to handle, check consistency and address issues. Therefore I can’t really agree with Harry Pierson as he writes:
Yes, decentralized decision making can create a management nightmare. Personally, a management nightmare is much more attractive anything centralized approaches have ever delivered in the IT industry.
Probably the most pragmatic way how to realize central management is as follows:
- Let all services adopt same common management interface (see SmartFrog for one implementation example – via Bill de hÓra).
- Run some management agents on each HW node where you are intent to run any service from your solution (not strictly necessary by greatly helps with some tasks like start new service instances, reporting health state, etc. See SmartFrog for example of use).
- Use centralized configuration database to:
- Record service topology (what runs where, preferred locations, failover rules, etc.).
- Collect application telemetric data (this term “coined” by Dan Pritchett).
- Keep and manage detailed service setup to ensure consistent setup for all services regardless of their physical running location.
- Optionally keep and manage upgrades/updates for services from one place.
- Define process to ensure configuration database and access to it is highly reliable (it might be done via standard tools of DB or via custom solution if you need to address special requirements).
- Develop in-house (recommended if you are really serious about it) or use 3rd party management application which understands configuration DB and how to interpret them.
As you can see listed items above creates significant additional work for design and application development. Even this is additional work it definitely pays off not only in less trouble and software issues in production environment but much more likely during testing when is necessary to test varies number of configurations in controllable way.
And now probably the most important question. If you will go for central configuration and management will retain all benefits SOA approach? You might have at this point same opinion as Harry Pierson on it.
SOA’s “distributed nature” is it’s primary strength. SOA’s not primarily about standards or ease-of-connectivity – though those obviously play a role. It’s about enabling decentralized decision making. Since you can’t be both centralized and decentralized, enforcing centralized management basically negates SOA’s primary strength. This seems like the worst of both worlds to me. All the hassle of distributed decision making combined with all the hassle of centralized management.
My position is you NOT LOSE ANYTHING from SOA goods. Actually opposite is true, as you take the best from both worlds: scalable, distributed, providing intended business value while reliably configured and managed with real business processes modeled closely within IT infrastructure.
I have intentionally avoided talking about concept of ESB so far but if ESB is done properly than the centralized configuration and management capability along with possibility to run individual services in unified environment is probably the biggest contribution of it. Unfortunately is questionable if you can buy such infrastructure on the market just to be right for your application needs.
Finally I would like to stress that average enterprise SOA based application is not equal to large scaled internet application (actually only a few such large scale applications can fit to this definition internet application anyway). Therefore no same running, deployment constrains or configurations conditions can be applicable here. you shall not be scared that your SOA based application will use centralized management/configuration and those large scaled internet applications will not be able to do this (at least not in same way you would do it).
Is my view wrong? Comments appreciated.
-Libor
