IT Compass

During a meeting, the terms "north" and "south" popped up again while discussing network zoning and DMZ. North is the "outside", typically the Internet. South are the internal, trusted systems.

North-South in networking (from PaloAlto networking)

How would IT people in South-Africa think about this, where the north is "hot" and very south Antarctica cold? Maybe also good fit: freezing in the data center, hot and dangerous on the Internet.

Unikernel: microservices without an OS

As I continue to spend lots of time on the road and in traffic jams, podcasts are an efficient way to keep up-to-date in the fast moving IT world. Just finished listening SE-Radio Episode 271: Idit Levine on Unikernels. Very interesting.

Had never heard of Unikernel. Actually this is hardly a real OS: no multi-tasking, no security, no memory management. Memory directly mapped to the underlying hardware and some device drivers.

Unikernels become most relevant when used on top of a virtualization layer. A single application is combined with the Unikernel to become a super light-weight runtime unit. A fine alternative for microservices running in a container.

Unikernels are also a nice fit with server-less architectures: the Unikernel App is super-fast to start. So Unikernel Apps as a more efficient Function-As-A-Service approach.

When mapping this to my own world of integration, the Unikernel App could be a nice mechanism to handle all the async events going on in an integration environment. An incoming message or API call starts the Unikernel App which handles the message: transformation, routing, logging, forwarding...

Incredible at which pace the IT world keeps moving.

Event-driven Microservices

A few weekends ago, I decided that it was time to catch up on Microservices. Hadn't been following the topic for a longer while. Starting point is often Safari: but instead of reading, I ended up watching the video tutorial "Event-Driven Microservices". By the way, the first part is freely accessible without a Safari subscription.

The video course is presented by Chris Richardson. I know Chris as a speaker at earlier Devoxx conferences. Very interesting is his approach to address the topic based on patterns, documented at microservices.io.

Microservices patterns (from Microservices.io, by Chris Richardson)

What was new to me and most interesting was the part about Event-Sourcing: instead of storing the state of each object as a database row, the sequence of changes is recorded and maintained. This an approach to tackle the issue of distributed transactions that do not fit with a Microservices architecture. This is also the topic Richardson personally focuses on as his latest startup is all about Event Sourcing.

List of events represents state (Source eventuate.io)

Handling request by rebuilding state from list of events (Source: eventuate.io)

Of course one needs to remain critical about Microservices:

• We've been successfully building 3-tier web and mobile apps, why do it all different now?
• How heterogeneous will all these microservices be?  
• Not every organisation is like LinkedIn or Netflix
• Transactions that are eventually consistent are not trivial
• What will be the next thing after Microservices?

After 4h 47minutes, I understood that Microservices is as well a domain that is in full flux.

Nexus 6 battery life: incredible

After the upgrade of my Nexus 6 to Android 6, battery life has increased in an unbelievable manner. When getting home from work, battery is now around 50%. With lengthy phone calls, USB in the car, hotspot in the once in a while. Simply amazing.

Incompatible Metering info (CallerInformation) in SAP WS

The support of SAP systems for SOAP Web Services is pretty good. I have e.g. been successfully using WS-RM and SAP-RM to have reliable, one-way communication.

During a project I needed to make a call from an SAP ECC 6 system towards an external web service. This external web service was secured with WS-Security X509 Token profile. So the payload had to be digitally signed. With no integration platform yet available, I intended to make a direct call from the SAP back)end system. But this really proofed to be impossible. Getting keys and certificates into an SAP system is always a challenge, but configuration of the WS-Security in SAP’s SOAManager is actually quite trivial.

But things did not work out: a real showstopper became the Metering info that was present in each and every outbound call. As of Support Pack 17 of SAP NetWeaver 7.0, the element <CallerInformation> is present in the SOAP header of each outbound SOAP request. Purpose of this element is to gather service metering and transfer it to the service provider.

  <CallerInformation wsu:Id="part-CallerInformation-2" 
     xmlns="http://www.sap.com/webas/712/soap/features/runtime/metering/">
    <m:Type xmlns:m="http://www.sap.com/webas/712/soap/features/runtime/metering/">SA</m:Type>
    <m:App xmlns:m="http://www.sap.com/webas/712/soap/features/runtime/metering/"/>
    <m:Component xmlns:m="http://www.sap.com/webas/712/soap/features/runtime/metering/"/>
  </CallerInformation>
</soap-env:Header>

And the bad news is: you cannot get rid of this Metering information, as clearly documented by SAP Support (SAP note 1239428). The only workaround is to forward the information in the URL of the HTTP call. But in my case, the well secured web service rightfully refused to accept the web service call with all these extra parameters in the URL.

So SAP has implemented an proprietary and incompatible “feature”. Why can’t it be switched off?
Is this a trick of SAP to enforce the use of SAP PI/PO? Obviously any ESB can remove this ugly SOAP header.

Best wishes for 2015

Devops (3): Chef (and some fun cooking)

After having looked into Vagrant, it became clear that Puppet and Chef are "the" tools to do the structured and repeatable configuration of machines. I picked the recent book "Learning Chef" to learn and experiment a bit.

Tools

• The book uses the recent Chef Development Kit which should gradually replace the tool called Knife.
• The tool "Chef" uses the the Recipe DSL to write recipes (Domain Specific Language, based on the Ruby programming language)
• VirtualBox is used for running the VM's that are going to be cooked and baked
• Complemented with our good friend Vagrant (see previous DevOps blog)(actually kitchen-vagrant)
• Finally the tool kitchen is used  

The focus op Chef really lies on getting the software on the machine installed, configured, and up and running. On the target machine, a Chef Client is installed that will retrieve (new and updated) recipes from a Chef Server. So the Chef clients each pull the recipes from the Chef Server.
Note: the tool Ansible does the opposite, pushing configuration data to the machines.

Many cookbooks or recipes can be downloaded from the Chef Supermarket and others.

Finally
After spending some time look around in the world of DevOps and its tools, I have a few general Observations:

• Devops is strongly focused on Linux
• Diverse programming languages such as Ruby and Erlang are used
• This is a domain in full flux, new initiatives and companies pop up, things evolve rapidly
• First time I see the file format YAML actually being used