The Smile-IT Blog » April 2016

Monthly Archives: April 2016

Automation and Orchestration – a Conclusion

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

 

Automation and Orchestration are core capabilities in any IT landscape.

Traditionally, there’d be classical on-premise IT, comprised of multiple enterprise applications, (partly) based on old-style architecture patterns like file exchange, asynchronous time-boxed export/import scenarios and historic file formats.

At the same time, the era of the Cloud hype has come to an end in a way that Cloud is ubiquitous; it is as present as the Internet as such has been for years, and the descendants of Cloud – mobile, social, IoT – are forming the nexus for the new era of Digital Business.

For enterprises, this means an ever-increasing pace of innovation and a constant advance of business models and business processes. As this paper has outlined, automation and orchestration solutions form the core for IT landscapes to efficiently support businesses in their striving for constant innovation.

Let’s once again repeat the key findings of this paper:

  • Traditional “old style” integration capabilities – such as: file transfer, object orientation or audit readiness – remain key criteria even for a cloud-ready automation platform.
  • In an era where cloud has become a commodity, just like the internet as such, service centered IT landscapes demand for a maximum of scalability and adaptability as well as multi-tenancy in order to be able to create a service-oriented ecosystem for the advancement of the businesses using it.
  • Security, maximum availability, and centralized management and control are fundamental necessities for transforming an IT environment into an integrated service center supporting business expansion, transformation, and growth.
  • Service orchestration might be the ultimate goal to achieve for an IT landscape, but system orchestration is a first step towards creating an abstraction layer between basic IT systems and business-oriented IT-services.

Therefore, for IT leaders, choosing the right automation and orchestration solution to support the business efficiently might be the majorly crucial decision to either become a differentiator and true innovation leader or (just) remain the head of a solid – yet: commodity – enterprise IT.

The CIO of the future is a Chief Innovation (rather than “Information”) Officer – and Automation and Orchestration both build the core basis for innovation. What to look at in getting to the right make-or-buy decision was the main requirement for this paper.

 

Published by:

How to StartUp inside an Enterprise

I’ve been following Ruxit for quite some time now. In 2014, I first considered them for the Cloud delivery framework we were to create. Later – during another project – I elaborated on a comparison I did between Ruxit and newRelic; I was convinced by their “need to know” approach to monitor large diverse application landscapes.

Recently they added Docker Monitoring into their portfolio and expanded support for highly dynamic infrastructures; here’s a great webinar on that (be sure to watch closely on the live demos – compelling).

But let’s – for once – let aside the technical masterpieces in their development; let’s have a look on their strategic procession:

Dynatrace – the mothership – has been a well-known player in the monitoring field for years. I am working for quite some customers who leverage Dynatrace’s capabilities. I would not hesitate to call them a well-established enterprise. Especially in the field of cloud, well established enterprises tend to leak a certain elasticity in order to get their X-aaS initiatives to really lift-off; examples are manifold: Canopy failed eventually (my 2 cents; some may see that differently), IBM took a long time to differentiate their cloud from the core business, … some others still market their cloud endeavours sideways their core business – not for the better.

And then – last week – I received Ruxit’s eMail announcing “Ruxit grows up… announcing Dynatrace Ruxit!“, officially sent by “Bernd Greifeneder | Founder and CTO”. I was expecting that eMail; in the webinar mentioned before, slides were already branded “Dynatrace Ruxit”, and the question I raised on this, was answered expectedly, that from a successful startup-like endeavour they would now commence their move back into the parent company.

Comprehensible.

Because that is precisely what a disruptive endeavour inside a well-established company should look like: Greifeneder was obviously given the trust and money to ramp-up a totally new kind of business alongside Dynatrace’s core capabilities. I have long lost any doubts, that Ruxit created a new way of technologically and methodically doing things in Monitoring: In a container-based elastic cloud environment, there’s no need anymore to know about each and every entity; the only importance is to keep things alright for endusers – and when this is not the case, let admins quickly find the problem, and nothing else.

What – though – really baffled me was the rigorous way of pushing their technology into the market: I used to run a test account for running a few tests there and then for my projects. Whenever I logged in, something new had been deployed. Releases happened on an amazingly regular basis – DevOps style 100%. There is no way of doing this within established development processes and traditional on-premise release management. One may be able to derive traditional releases from DevOps-like continuous delivery – but not vice versa.

Bottom line: Greifeneder obviously had the possibility, the ability and the right people to do things in a totally different way from the mothership’s processes. I, of course, do not have insight in how things were really setup within Dynatrace – but last week they took their baby back into “mother’s bosom”, and in the cloud business – I’d argue – that does not happen when the baby isn’t ready to live on its own.

Respect!

Enterprise cloud and digitalisation endeavours may get their learnings from Dynatrace Ruxit. Wishing you a sunny future, Dynatrace Monitoring Cloud!

 

Published by:

System Orchestrator Architecture

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

 

This final chapter addresses architecture components for typical system orchestrators; comparing these with the blueprints for high-grade innovative automation solutions mentioned previously in this paper will reveal the close resemblance between automation and system orchestration patterns in a very obvious way.

The first figure below is system deployment architecture diagram describing the main physical components for a system orchestrator:

System Orchestration Deployment Architecture

System Orchestration Deployment Architecture

Note, that:

  1. the database normally needs to be setup in a clustered mode for high availability. Most orchestrator solutions do rely fully on the database (at least at design time).
  2. the Management Server’s deployment architecture is depending on availability requirements for management and control.
  3. the Runtime server nodes should be highly distributed (ideally geographically dispersed). The better this is supported by the product architecture the more reliable orchestration will support IT operations.
  4. the Web service deployment is depending on availability and web service API needs (product and requirement dependent)

Logical architecture

The logical architecture builds on the previous description of the deployment architecture and outlines the different building blocks of the orchestration solution. The logical architecture diagram is depicted in the following figure:

System Orchestration Logical Architecture

System Orchestration Logical Architecture

Notes to “logical architecture” figure:

  1. The Orchestrator DB holds runtime and design time orchestration flows, action packs, activities, plugins, logs, …
  2. Management Server controls access to orchestration artefacts
  3. Runtime Server provides execution environment for orchestration flows
  4. Orchestration designer (backend) provides environment for creation of orchestration flows using artefacts from the database (depending on specific product architecture the designer and management components could be integrated)
  5. Web Service exposes the Orchestrator’s functionality to external consumers (ideally via REST)
  6. Action packs or plugins are introduced through installation at the design time (normally integrated into the DB)
  7. The Orchestrator’s admin console is ideally implemented as web service, hence accessible via browser
  8. The Design Client UI could either be web-based or a dedicated client application to be installed locally and using a specific protocol for backend communication

Of course, these building blocks can vary from product to product. However, what remains crucial to successful orchestration operations (more or less in the same way as with automation) is to have lightweight, scalable runtime components capable of supporting a small scale, low footprint deployment equally efficient to a large scale, multi sight, highly distributed orchestration solution.

 

Published by:

Student_in der Soziologie gesucht!

Nein – nicht, wofür du jetzt glaubst …

Sonntagnachmittag. Der gestrige Tag wurde von der Generation… (was sind die Damen und Herren jetzt eigentlich; für “Z” sind die doch auch schon zu jung, oder?) … an den Computern verbracht. Leage-of-Legends, Minecraft, oder was das Internet halt sonst noch so an Spielen hergibt. In Konsequenz dessen gab es heute also einen “Frische Luft”-Zwang-Tag. Weitestgehend Internet-frei (außer zur Navigation am Stadtwanderweg Nr. 4) und ohne der Chance, dem mit einem vagen “ich treff mich später noch mit Freunden; ich bleib da” auszuweichen.

Der Drittgeborene (14) schaffte es dann doch noch erfolgreich, sich vorzeitig vom gemeinschaftlichen Ausflug zu verabschieden. Hätte er sein Smartphone etwas selbstsicherer als Navigator zu verwenden vermocht, wäre ihm das lange vor dem Anstieg an den höchsten Punkt des Satzberges gelungen.

Mich stimmen derartige Situationen zweifach – völlig konträr zueinander – arg nachdenklich:

  1. Was ist so schlimm am Rausgehen?
  2. Warum ist ein Smartphone für einen 14-jährigen immer noch nur ein Tipp-o-phon?

Im Volksschulalter

waren mein Bruder und ich mit 3 Kindern aus der Siedlung befreundet. Unsere Eltern trennten streng in Schulgewand und Alltagsgewand. Deshalb hielt uns nach den Hausaufgaben noch das für uns überaus lästige Umziehen vom Treffen mit den geliebten Freizeitkumpanen ab. Wir haben damals Lokal-Geschichte geschrieben auf unseren Ausflügen in die dörfischen Umlande. Der Beweis unserer kindlichen Kraft, in der Lage zu sein, ein Wehr zu öffnen, endete für den örtlichen Forellenzüchter mit dem Verlust seines Fischschwarms – sehr zum Leidwesen unserer Eltern, die das entschuldigen mussten. Dass wir danach was zu hören bekamen, verstand sich von selbst. Tags darauf waren wir dennoch wieder draußen.

Gut – mag man einwenden: Damals gab es weder Computer (zumindest nicht im privaten Haushalt) noch Smartphones. Aber es gab Bücher. Fernsehen (hie und da). Matchbox-Autos, die man stundenlang unter dem Heizkörper in Reih und Glied aufstellen konnte, und Fußball-Sammelkarten. Gründe genug, das Haus nicht zu verlassen; und oft genug entschieden wir uns für sie. Uns rauszukriegen aus den eigenen vier Wänden war dennoch recht einfach und unsere Eltern hatten mehr Stress damit, was wir nun wieder anstellten, als damit, dass wir zu wenig oder zu spät selbständig werden würden.

Man mag auch einwenden, dass es wohl etwas leichter war, in der ländlichen Umgebung meiner Kindheitsheimat nicht verloren zu gehen, als in einer Großstadt. Ich meine hingegen, dieses vermeiden heute intelligente, hilfreiche Smartphone-Funktionen doch völlig ohne weiteres. Kinder lernen heute in dem Alter, in dem ich Fische unerlaubterweise in ihre Freiheit entließ, wie man ein Smartphone (zum Spielen) benutzt. Da könnte man doch annehmen, dass sie dann im gymnasialen Alter wissen, wie sie es dazu benutzen können, ihren frischluft-fanatischen Eltern zu entkommen.

Oder ist es vielmehr vielleicht so,

dass Eltern heutzutage die Computer-Verliebtheit ihrer Kleinen doch ein wenig genießen? Meint vielleicht manche Mutter, dass ein Nachmittag (10-12 Stunden) Strategiespielen am Kastl sicherer ist, als mit irgendwelchen Freunden, die man vielleicht garnicht so genau kennt, irgendwo in der Großstadt herumzuhängen?

Ein Teil meiner spärlichen Freizeit ist bekanntermaßen mit der Arbeit für eine mir aus zig-1000 Gründen lieb gewordene Organisation – http://www.cisv.org – gefüllt. Wir bieten Kindern ab dem Alter von 11 Jahren an, ihre Ferien mit Gleichaltrigen aus der ganzen Welt zu verbringen und zu lernen, wie die so leben. Für die 11jährigen dauert unser Programm 4 Wochen; das hat gute Gründe in der Zeit, die Kinder in dem Alter brauchen, um sich gegenseitig so richtig zu vertrauen. Wenn ich Eltern davon erzähle, höre und spüre ich die Begeisterung, die sie meinen Schilderungen entgegenbringen – bis zu dem Moment, an dem ich “4 Wochen” sage. Dann weiten sich oft genug die Augen mit Schrecken und es folgt eine Antwort à la “Nein, 4 Wochen – das ist für mein Kind viel zu lange! Das kann es noch nicht!”

Und wenn ich so über uns, über die Generation nach mir, über die nächste danach, … nachdenke, dann scheint es mir fast, als könnte man eine Rückwärtsbewegung des Abnabelns beobachten: Mir konnte es nicht früh und schnell genug von zu Hause weg gehen – sei es mit 11 auf den Feldweg oder zum Fischwehr oder dann mit 18 nach Wien. Unser Drittgeborener definiert soziale Interaktion über den Chat in League-of-Legends. Und wenn wir – was wir noch nie getan haben – dann doch mal das Internet abdrehten, dann sagt er, er verlöre alle seine Freunde.

Ich suche eine/n Soziolog*in,

die Interesse hat, das Phänomen Smartphone/Computer/Internetspiel im Zusammenhang mit dem Loslassen in der Kindererziehung zu untersuchen. Was verändert sich da? Haben diese Devices Einfluss auf den Freiheitsdrang unserer Kinder? Welchen? Und welchen haben sie einen auf das Sicherheitsdenken heutiger Eltern? Sind die vielleicht froh darüber, dass die lieben Kleinen lieber Zeit in ihrem hochsicheren, hochdigitalisierten Kinderzimmer als auf der Straße oder im Park verbringen?

Mich würde das wissenschaftlich interessieren? Ehrlich! Und ich biete hiermit Unterstützung an …! Ehrlich! Wer mag?

 

Published by:

System versus Service Orchestration

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

 

One of the most well-known blueprints for service orchestration is the representation as seen from the perspective of service oriented architecture (SOA).

The following figure in principle describes this viewpoint:

Service Orchestration, defined

Service Orchestration, defined

Operational components – such as “commercial off the shelf” (COTS) or custom applications, possibly with a high level of automated functionality (see previous chapters) – are orchestrated to simple application services (service components) which in turn are aggregated to atomic or composite IT services which subsequently support the execution of business processes. The latter are presented to consumers of various kind without disclosing any of the underlying services or applications directly. In well established service orchestration, functionality is often defined top-down by modelling business processes and defining its requirements first and then leveraging or composing necessary services to fulfil the process’ needs.

A different approach is derived from typical definitions in cloud frameworks; the following figure shows this approach:

System Orchestration: Context

System Orchestration: Context

Here, the emphasis lies on the automation layer building the core aggregation. The orchestration layer on top creates system and application services needed by the framework to execute its functional and operational processes.

The latter approach could be seen as a subset of the former, which will become more clear when talking about the essential differences between system and service orchestration.

Differences between system and service orchestration

System Orchestration

  • could in essence be comprised of an advanced automation engine
  • leverages atomic automation blocks
  • eases the task of automating (complex) application and service operation
  • oftenly directly supports OS scripting
  • supports application interfaces (API) through a set of plugins
  • may offer REST-based API in itself for integration and SOA

Service Orchestration

  • uses SOA patterns
  • is mostly message oriented (focuses on the exchange of messages between services)
  • supports message topics and queues
  • leverages a message broker and (enterprise) service bus
  • can leverage and provide API
  • composes low level services to higher level business process oriented services

Vendor examples of the former are vRealize Orchestrator, HP Operations Orchestration, Automic ONE Automation, BMC Atrium, System Center Orchestrator, ServiceNow (unsurprisingly some of these products have an essential say in the field of automation as well).

Service orchestration examples would be vendors or products like TIBCO, MuleSoft, WSO2, Microsoft BizTalk, OpenText Cordys or Oracle Fusion.

System orchestration key features

System orchestrators are mainly demanded to support a huge variety of underlying applications and IT services in a highly flexible and scalable way:

  • OS neutral installation (depending on specific infrastructure operations requirements)
  • Clustering or node setup possible for scalability and availability reasons
  • Ease of use; low entry threshold for orchestration/automation developers
  • Support quality; support ecosystem (community, online support access, etc.)
  • Database dependency to minimum extent; major databases to be supported equally
  • Built-in business continuity support (backup/restore without major effort)
  • Northbound integratability: REST API
  • Southbound integratability and extensibility: either built-in, by leveraging APIs or by means of a plugin ecosystem
  • Plugin SDK for vendor external plugin development support
  • Scripting possible but not necessarily needed
  • Ease of orchestrating vendor-external services (as vendor neutral as possible, depending on landscape to be orchestrated/integrated)
  • Self-orchestration possible
  • Cloud orchestration: seamless integration with major public cloud vendors

Main requirements for a service orchestrator

In contrary to the above, service orchestration solutions would focus mainly on message handling and integration, as its main purpose is to aggregate lower level application services into higher level composite services to support business process execution. Typical demands to such a product would therefore involve:

  • Support of major web service protocol standards (SOAP, REST)
  • Supports “old-style” enterprise integration technologies (RMI, CORBA, (S)FTP, EDI, …) for integration of legacy applications
  • Provides a central service registry
  • Supports resilient message handling (mediation, completion, message persistence, …)
  • Includes flexible and easy to integrate data mapping based on modelling and XSLT
  • Supports message routing and distribution through topics, queues, etc.
  • Integrated API management solution
  • Integrated business process modelling (BPM) solution
  • Integrated business application monitoring (BAM) solution
  • Extensibility through low-threshold commonly accepted software development technologies

As a rule of thumb to delineate the two effectively from each other, one can say that it is – to a certain extent – possible to create service orchestration by means of a system orchestrator but it is (mostly) impossible to do system orchestration with only a service orchestrator at hand.

For this reason, we will continue with a focus on system orchestration as a way to leverage basic IT automation for the benefit of higher level IT services, and will address vanilla architectures for typical system orchestrator deployments.

 

Published by:

What Is Orchestration?

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

 

Prior to diving into the architectural patterns for a robust orchestration solution for the enterprise, a few definitions need to be clarified, and as this paper talked a lot about Automation in the first place, we shall begin with outlining precisely the delineation between Automation and Orchestration – to begin with:

  • In any IT architecture framework, the automation layer creates the components necessary to provide atomic entities for service orchestration. Automation uses technologies to control, manage and run atomic tasks within machine instances, operating systems and applications on the one hand and provides automation capabilities for the larger ecosystem in order to automate processes (e.g. onboarding a new employee)
  • Orchestration – in turn – uses processes, workflows and integration to construct the representation of a service from atomic components. A service could e.g. consist of operations within various different systems such as the creation of a machine instance in a virtual infrastructure, the installation of a webservice in another instance and the alteration of a permission matrix in an IAM system. “Orchestration” would provide means to aggregate these atomic actions into a service bundle which can then be provisioned to a customer or user for consumption. The Orchestration layer makes use of single automated service components.

While the above definitions mainly address the system context in IT architectures, it is valid to say that there is another slightly different context – the service context – which demands for another definition of the term “orchestration”:

  • Service orchestration is the coordination and arrangement of multiple services exposed as a single aggregate service. It is used to automate business processes through loose coupling of different services and applications, thereby creating composite services. Service orchestration combines service interactions to create business process models consumable as services.

In order to underpin the danger of confusion when discussing orchestration, here are a few references for orchestration definitions:

  • “Orchestration describes the automated arrangement, coordination, and management of complex computer systems, middleware and services.” (wikipedia: https://en.wikipedia.org/wiki/Orchestration_(computing) )
  • “Complex Behavior Interaction (Logic/Business Process Level): a complex interaction among different systems. In the context of service-oriented architecture, this is often described as choreography and orchestration” (Carnegie Mellon University Research Showcase 12-2013: “Understanding Patterns for System-of- Systems Integration”, Rick Kazman, Klaus Nielsen, Klaus Schmid)
  • “Service orchestration in an ESB allows service requesters to call service providers without the need to know where the service provider is or even the data scheme required in the service” (InfoTech Research Group Inc. “Select and Implement an ESB Solution”, August 2015)
  • “Orchestration automates simple or complex multi-system tasks on remote servers that are normally done manually” (ServiceNow Product Documentation: http://wiki.servicenow.com/index.php?title=Orchestration#gsc.tab=0 )
  • “The main difference, then, between a workflow “automation” and an “orchestration” is that workflows are processed and completed as processes within a single domain for automation purposes, whereas orchestration includes a workflow and provides a directed action towards larger goals and objectives” (Cloud Computing: Concepts, Technology & Architecture”, Thomas Erl, Prentice Hall, October 2014)
  • “Orchestration is the automated coordination and management of computer resources and services. Orchestration provides for deployment and execution of interdependent workflows completely on external resources” (ORG: http://cloudpatterns.org/mechanisms/orchestration_engine )

Even though these definitions seemingly leave a lot of room for interpretation of what system and service orchestration really covers, clarity can be gained by looking at a few architectural principles as well as requirements for different orchestration goals, which the last few chapters of this paper will be focusing at.

Published by:

From Automation to Orchestration

This post is part of the "Automation-Orchestration" architecture series. Posts of this series together comprise a whitepaper on Automation and Orchestration for Innovative IT-aaS Architectures.

 

In some cases, choosing an appropriate IT automation solution comes down to a matter of business dependency, migration efficiency, or simply vendor relationship and trust. Many times, these criteria alone might provide enough information to make a solid buying decision.

However, to make the best decision for an organization, examining prospective automation solutions more closely could be an option. A key consideration are the solutions’ architectural patterns, which should be assessed through well-planned proof of concept testing or a detailed evaluation. Some key questions to raise are listed below, for convenience and possible inclusion in the evaluation questionnaire:

  • Does the solution have sufficient scalability to react to on-demand load changes and at the same time allow for the growth of IT automation and orchestration as your business grows?
  • Does the solution provide object orientation which allows for representation of real-world IT challenges through well-structured re-usable automation objects and templates?
  • Can the solution quickly and easily integrate and adapt to business process changes?
  • Does the solution guarantee 24/7, close-to-100% availability?
  • Is the solution able to interface with traditional legacy system files and applications through integrated file transfer capability?
  • Can the solution provide a full audit trail from the automation backbone and does it support compliance standards and regulation out-of-box?
  • Does the solution offer multi-clients support and have the ability to segregate organizational and customer IT segments?
  • Does the solution include the latest security features supporting confidentiality, integrity and authenticity?
  • Can the solution handle the integration needs in a homogeneous way from a central automation layer that enables IT admins to come up to speed quickly with minimal training?
  • Does the solution dynamically control the execution of processes at all times?

Obviously, not all automation solutions in the market would be able to give a “yes” to each of these questions; and as always the goal is to find the platform that does bundle all of the described criteria in the best possible compromise.

A supportive element to this decision could be a solution’s capability not only to automate mundane operations tasks in an IT landscape but to bundle these tasks into larger system orchestration scenarios.

What’s the essentials of such scenarios? What’s to look at? And what about the delineation between system and service orchestration? This is subject to the following chapters.

Published by:
%d bloggers like this: