A deep dive into SAP Hybris YaaS microservices

In the first blog in this series, I established a set of microservice usage scenarios in enterprise software.  My goal was to provide a context for a deeper examination of microservices in SAP solutions – in particular, SAP Hybris as a Service or YaaS.

My intention in this second blog isn’t technical, but rather to try and understand the larger patterns (in maturity, organizational impact, etc) that lie hidden behind the bare API RAML definitions for YaaS.

A deep dive into YaaS microservices

Note: The definition of microservices is as hotly contested a term as cloud.  It is equally important to understand that microservices aren’t only a technology but an architecture/philosophy that can be realized using a variety of technologies.

As I started this research, I didn’t have many details to work on. I was less interested in the contents of the APIs themselves (whether they read information from customers or deal with loyalty cards, etc) but was more intrigued by the “metadata” associated with the microservices - details that are usually not exposed publicly.

Most useful was the YaaS Release notes page  and I decided to mine this page to try and discover something relevant.

Note: This page is not a perfect source of data. It doesn’t contain the release notes of all available services - for example, the Text Analysis microservices recently released by SAP aren’t listed there. Bug fixes also appear not be listed - for example, there was a bug fix for the Checkout V1 service that was deployed but isn’t listed in the release notes page.

Here are some of the patterns that I found:

Origin

At the moment, there are 33 packages – four are published by SAP and the rest are from Hybris.  The first release was in summer 2015.  Most packages are from Hybris – the SAP packages (for example, those concerning HANA-based text analysis) are more recent.  There are no packages from other vendors, partners, customers, etc.

My assumption is that technical hurdles are not the reason behind the dearth of microservices on YaaS.  Although the marketplace purposes that developers “Develop your own! Start building cloud-based applications in whichever language you choose. Collaborate with others in projects to build, manage and publish your services.”, there are still various issues that must be cleared up before externals can publish their services on the marketplace.

Release frequency

Based on my analysis of the YaaS release notes, there have been over 270 individual releases since the platform started in 2015.

The diagram below shows the individual releases per month.  I deleted the legend with over 101 individual services from the diagram, because it was just too much detail.  This diagram looks chaotic and is very different from would be expected in a typical waterfall-based project with regular releases:

This graph shows that many of these services are being released independently of each other.   For many SaaS applications, you can expect a quarterly release cycle for the application. The YaaS microservice releases occur when necessary – even if releases are required multiple times in a single week.

Another diagram of the releases focusing on the number of releases per service demonstrates that there is high degree of diversity:

Of course, older services will potentially have a large number of releases but there is a high degree of variety in the release counts.

If we zoom in on two specific services with details on exact release dates, we can see more evidence of these patterns:

These are two services that being released independently from each other at different intervals.

Some of the YaaS microservices (in particular, those for C4C), however, demonstrate a different release cycle:

These are three (there are 19 in total) services that originate from an application (C4C) that has yet to be decomposed into microservices.  The underlying application is still a monolith and these are more APIs rather than microservices.  The associated microservice releases are associated with specific C4C releases. This is evident in the associated release notes from these services.

• This release is in sync with the SAP Hybris Cloud for Customer (C4C) 1702 release.
• This release is in sync with the SAP Hybris Cloud for Customer (C4C) 1611 release.

It is unlikely that this will change for C4C – at least in terms of the existing underlying application. In the short term, completely rewriting the application based on entirely on microservices is non-trivial.  This ability is easier for new solutions, such as the Hybris Revenue Cloud.

In conversations with executives at last week’s Hybris Digital Conference, we gained insights into the teams at Hybris supporting such services.  These teams represent modern DevOps strategies and include developers and Op teams who are responsible for their particular services.

Why is this important?  We are still talking about enterprise software when we discuss YaaS microservices with all the security and quality (for example, tests) requirements that customer expect – especially coming from SAP.  Without automation and organizational maturity, it isn’t possible to meet these standards.   The advantage for customers is that these separate release cycles mean that new features don’t have wait for a quarterly release cycle but can occur at a much faster rate.

My take

In recent years, SAP has been aggressively promoting itself as a “Cloud” company.   This transition hasn’t always been easy.  The recent developments regarding the Public Cloud edition of S/4HANA demonstrate that SAP is also forcing its core ERP business into the Cloud. Comparing this version of S/4HANA to the new Hybris Revenue Cloud (with its basis in the new microservices) is probably unfair - the two offers have fundamentally different technical histories and meet different business requirements.

A new microservice (currently in beta) on YaaS that was released last week provides some indication of how these two worlds might come closer together.  The new microservice is called “Currency Services Exchange Rates” and provides new functionality to S/4 customers.

The Currency Services package includes the Exchange Rates service, which is a customizable reuse service that allows you, as an S/4HANA consumer, to import daily and historical currency exchange rates.

Through the Exchange Rates service, you can make REST calls that fetch the data you need in an easily usable format. The exchange rates service allows you to input a pair of source and target currencies for a specific date or for a date range. You can configure an existing transaction like TBD4 on your SAP S/4HANA system to use this data.

This functionality is different from the APIs that are available for S/4 in the API Hub – indeed, this new service isn’t available in this SCP (SAP Cloud Platform) site.  I could imagine that you might see similar new functionality for existing applications, such as S/4HANA or C4C, emerging as new services on YaaS.  Such complementary functionality would then be made deployed on SCP.   This would fit well with the strategy of using SCP as an extension platform.

The organizational / technical changes associated with microservices are non-trivial and it would probably be unwise to shift whole development organizations to this model unless experience is there to correctly implement it. SAP practices agile development - in particular, in the SCP team (take a look at its release cycle – every two weeks is pretty good).  SCP-related services (SAP Translation Hub, Integration, API Management, etc.) are already being released independently of each other but I don’t think the underlying applications are based on microservices - yet. A more gradual approach is probably more desirable – the “SAP Data Quality Management” microservice is one example of such a scenario.  A blog regarding this beta microservice promises other similar services:

We are planning to provide pre-built integrations of these services in other applications from SAP which will provide a very simple way to consume this functionality.  More to come on that in the future.   If you have an application from SAP and you wish we provided these or other data quality type services within that application please let us know as well!  These capabilities are just our starting point.

It doesn’t make sense to “rip and replace” whole applications (or individual SCP services) to force the transition to microservices.

For customers, microservice-based architectures also represent new challenges. If you are using an application that is composed of 90 different services from 10 different sources, who do you call if there is an issue? You want one neck to choke. From a CIO perspective, governance of such scenarios will probably be become more complex.  Eventually, there well may be a list of vetted service providers for a particular customer (similar to the list of accepted SaaS vendors) from which corporate developers can choose their services.