SAP Hybris and the push towards enterprise microservices - an analysis

I attended last week’s Hybris Digital Conference in Munich and one of the event’s announcements concerned the new SAP Hybris Revenue Cloud offering.

SAP Hybris Revenue Cloud works as a stand-alone solution connected to an enterprise’s existing IT systems, or it can be operated as an integral part of the SAP Hybris cloud portfolio. This gives enterprises an end-to-end commerce solution that enables customer engagement across channels and devices, and allows them to respond to changing customer needs, such as by providing initial offers and cross-sell, up-sell and down-sell options. Importantly, it allows customers to build new subscription- and usage-based offers grounded on deep customer insights.

Reading the associated press release, I noticed the emphasis on the availability of this new offering including a set of microservices available on SAP Hybris as a Service:

SAP Hybris Revenue Cloud constitutes a new generation of cloud products based on a microservices architecture that enables partners and customers to build and harness flexible extensions and solutions. The SAP Hybris cloud suite can run on SAP Hybris as a Service, (informally known as YaaS) that helps businesses rapidly and easily augment and enhance their existing solutions with microservices and software-as-a-service applications.

These microservices aren’t the first ones for Hybris – the company has a series of other available services:

What Hybris has done from a microservices standpoint is basically break up a product into 31 pieces and tell customers to keep what they like and leverage what they have and do it at a global scale,” Grady said. “We see this as where the industry is going, and the industry leader is going this way. We think it’s going to have a massive impact on the market.

As evidenced by the keynote at last year’s TechEd in Las Vegas, SAP is trying to show that it has microservices front and center in its entire cloud architecture.

How enterprise software vendors use microservices

SAP isn’t alone in the endeavor. Many enterprise software vendors have been describing the important role of microservices in their solutions.   In my opinion, there are three patterns regarding microservice usage in enterprise software:

• Internal: a software vendor uses microservices as part of their internal architecture
• Platform: a software vendor creates an environment that can be used by third party developers to create microservices
• Commercial: a software vendor sells microservices

Note: A software vendor may also support all three patterns – for example, in different products.

Note:  My intention in this blog is not to perform a deep dive into the underlying technology behind microservices either in SAP software or in that of other vendors. To better understand where Hybris’ microservices fit into broader trends in the industry as well as how they fit into SAP’s cloud strategy, we need to provide a context in which to view these activities.

1. Internal microservices

This pattern is perhaps the most common of the three and is present in a variety of companies –though not necessarily enterprise software companies.  Netflix was an early implementer of such architectures.

One example of this scenario in enterprise software is Workday. As per Saugatuck Technology:

Workday has began to decompose their monolithic application into microservices, with the initial focus being on their Insight Applications which have a significant amount of processing underlying their multidimensional predictive model, as well as functions like Time Entry which tend to happen all at once. Over time, they have plans to apply machine learning to the scaling itself, so that the system will know to predict expected spikes in load and preemptively provision additional resources.

Note: For more details on Workday’s strategy behind microservices, CTO Stan Swete provides additional information in this video.

Microsoft’s Service Fabric represents a similar pattern:

Part of what makes Service Fabric a unique offering, says Russinovich, is that it has been "battle hardened" by developers inside Microsoft who have been using it to build Azure applications as services for five years, including Azure Database, Skype for Business (formerly Lync), Bing Cortana, Service Bus, Event Hubs, Power BI, Azure Machine Learning, Intune, and DocumentDB. He emphasizes that:

[Service Fabric] is not a version of something that we have powering those services I mentioned. It is not just taking the concepts and creating something new and then saying, “Hey, this is bringing the same kind of stuff to you that we are using internally.” These are … the exact bits that we’re running internally underneath all those services.

Regarding SAP’s products, there are few details about if and how their internal products utilize microservices. The new Revenue Cloud is build using new YaaS microservices.   A job offering for Junior Developer in the project provides some technical details and confirms the press release.

However, skills in microservice-based cloud architectures comprising Cloud Foundry, Spring/Spring Boot, CI/CD (Jenkins), databases (PostgreSQL, Redis, …), messaging (RabbitMQ), GitHub, Kibana and Maven, as well as skills in JavaScript and HTML5 are a clear bonus.

What is important to understand is that the Hybris Revenue Cloud, however, is more than just Java-based microservices - it's also an application that was developed from ground up based on this new architecture. Beyond that, I have yet to see any usage information on YaaS services in other products from SAP.

At the Hybris event, the customer panel  included Eberhardt Weber from a German company called “Lieferladen” – an online supermarket - which has developed their solution using YaaS.  This pattern is an example of other enterprise software -related start-ups using this technology as well.

2. Platform microservices

This characteristic concerns the ability of platforms created by software vendors to support microservice development. This is by far the most popular in the enterprise software space with a myriad of examples.

• Oracle: The use of its existing service bus to support microservice architectures
• SAP: The use of the HANA Cloud Platform
• SAP: HANA itself can also support microservice architectures
• IBM: Docker and IBM’s PaaS BlueMix in microservice architectures
• Tibco: The use of its existing service bus to support microservice architectures
• Microsoft: Its Azure Service Fabric can be used to build and deploy microservices.

Although many of these vendors refer to cloud-based deployments, the examples of Tibco, Oracle and HANA demonstrate that on-premise platforms can also provide a setting for such scenarios.

YaaS also represents this pattern in that developers can also deploy microservices on the platform – although the focus is on the deployment of such services on the SAP Cloud Platform (SCP).  There is an excellent description available that describes how SCP and YaaS fit together technically.

3. Commercial microservices

Note: Selling such services (indeed, providing any enterprise software via an online store) is a non-trivial task that involves various hurdles of a legal and commercial nature.

This pattern is based on the sale of microservices by an enterprise software vendor. Of the three patterns, this one is the rarest.

YaaS’ microservice marketplace is one example of this pattern.

Note:  In the YaaS Marketplace, there are different packages that each includes a set of related services.

These are services marketed towards developers – either in customers or in partners. These services are currently not advertised to business users.   This is an important distinction between this pattern and other environments where business users can buy completed packages (ie, SaaS applications).  Thus, the commercial success of such environments is tightly connected with the ability to attract developers to this ecosystem.

Furthermore, the model of selling individual services to developers is an entirely different sales process as that as that associated with a PaaS (a platform) or a SaaS (an application).  Take a look at some examples of subscription costs associated with specific packages on YaaS.

Package	Additional usage per month
Customer Journey Manager	$1.71 per 1 Interactions
Profile Core Services	$2.99 per 1,000 Contacts
CECenter SAP Jam Communities Integration	$0.10 per 1,000 API Calls
Customer Accounts	$0.10 per 1,000 API Calls $10.00 per 100 Registrations

A developer can pick 1 or more services for his application. How will an existing SAP sales rep or a partner respond to such scenarios?  A new “low-touch” sales model is necessary – one is that is reminiscent of the sales strategy proposed by SAP’s Chief Digital Officer Jonathan Becher.

One example of the impact of this “low-touch model” is that it is only possible in the YaaS marketplace to pay via credit card:

When entering into the Framework Agreement, Customer will be asked to enter credit card information since any fees which will become due for the subscription to a Cloud Service Customer wishes to subscribe will be balanced to such credit card. Please note that there is no other payment method available than credit cards.

This is similar to typical cloud agreements where business users can purchase SaaS applications.

Some might be questioning why I haven’t mentioned the SAP Cloud Platform (SCP) in this section. At the moment, it is not possible to purchase individual services in this environment.  If you look at the cloud offers in the SAP Store , you will see packages based on usage (for example, the starter package). Of course, these packages include all the services that SCP includes – however, you can’t buy individual services.

It's mportant to note is that there are a few microservices running on SCP.  One excellent example is the SAP Data Quality Management service which is currently available in beta. It allows developers to embed data cleansing and enrichment services within any business process or application with a self-service, right-sized consumption model.

This offering provides HTTP/JSON-based services running on SAP HANA Cloud Platform.  Developers can simply integrate these services into their own applications to provide address cleansing/validation, geocoding, and reverse geocoding capabilities.

The SCP API Hub has expanded its list of APIs (including those from Hybris – one example, that of the Category service) but you can’t buy anything on the site and the “APIs that you subscribe can only be used for testing and trial purposes." This represents the difference between a platform, and an individual service-focused approach.

My take

Discussions of microservices often focus on the technical aspects of this technology.   Usually, the content is directed at developers in enterprises wishing to implement microservices – for example, via Cloud Foundry.  As I’ve depicted in this blog, there are different possibilities – besides the underlying technology/code - to view how microservices fit into enterprise software.

In the next blog in this series, we’ll take a take a deep dive into YaaS microservices to gain more understanding of their concrete manifestation in SAP’s solutions.  We’ll also take a crack at describing the evolution of microservices in enterprise software – in particular, for vendors that already have an established portfolio that includes on-premise, as well as cloud-based monoliths.