September 04 2015, 10:34

Got the hang of SAP hybris YaaS – a SOA-based cloud solution for e-commerce. Managed to do some coding and customization. Last week, we launched an Open Beta for the SAP partner community.

An extremely interesting, somewhat trendy, and visually appealing concept.

lightweight storefront @AngularJS + API first + Scalability + EJB/COM + RAML + MQ + Pivotal Web Services / Cloud Foundry

The storefront is an extremely lightweight solution, in the out-of-the-box example it has no server-side scripts at all, it’s built on AngularJS, which is a JavaScript framework. The server side is the yaas.io service, which acts as a container for RESTful API – it proxies requests to real services, hosted on platforms such as pivotal.io, incorporating its own checks. Some of these APIs are offered as hybris-as-a-service, covering both core and e-commerce functions.

Development involves creating custom APIs, publishing them as services in the cloud, and connecting them to each other and to the storefront.

You can subscribe to other people’s APIs, for which there is a marketplace. The market allows you to publish your publicly beneficial APIs and make money from them (not yet possible).

For example, you subscribe your store to an API from the Email library, and voila, you have the cloud capability to send emails, with a corresponding REST interface.

Subscribe your store to a search API – and you have the cloud ability to search your data. There’s a choice between different search engines. Facets are available too.

Created your own service for KLADR address verification – and you earn by others using it.

Of course, connecting any new service requires you to hack the storefront on AngularJS quite substantially, but it’s all documented. Or, add interactions to your own APIs.

Ultimately, the store consists of a lightweight storefront + a set of APIs on different servers, loosely coupled to each other + a lightweight, extensible admin panel on yaas, which interacts with the same APIs for data retrieval/modification. Essentially, there’s no core system – the system consists of many small e-commerce blocks scattered across different domains, servers, clusters (though currently all hosted on the same platform). Each can be individually enhanced.

APIs are hosted on Pivotal.io/Cloud Foundry. There is a convenient mechanism for publishing APIs to the cloud, as well as an easy way to provision resources for it.

API development uses the RAML language, allowing easy expansion of your services with library capabilities, known as RAML traits – “features” that can be applied to new APIs, like adding filtering or paging to APIs that return records sets.

There’s also its own cloud middleware software for MQ, for communication between APIs and external systems like ERP. There’s a mechanism for extending data in the API framework. Data behind the API is handled by MongoDB, but it’s invisible as access to objects is through REST interfaces.

@[658732965:2048:Andrey Tatarinov] there’s something very corporate about it @[1431739380:2048:Grigory Bakunov] @[100001168004708:2048:Erik Babadzhanov]

Apart from the advantages (and I haven’t listed them all), I know the drawbacks. The vendor’s model is not yet fully developed, neither technically nor business-wise. Still figuring out the details. How soon will we implement a system based on this technology? Are there similar themes in the market?

August 31 2015, 18:53

The number of the day, I believe.

As usual, went to check before reposting.

The US restaurant market – $700 billion a year. Typical tips – 10-15%. Downside – not everyone gets them, plus – not only restaurants give them. $40 billion is quite a realistic number, despite finding nothing on Business Insider.

By the end of last year, our IT market was around 700 billion rubles (software+services+hardware), which at that exchange rate also seemed like $20 billion.

August 31 2015, 07:26

Google Inbox has introduced a new feature to the market – versioning of online applications. I haven’t encountered this anywhere else.

The idea is that each new version of an online software like email gets deployed on a separate cluster, and transitioning from the old version to the new one is done with the user’s confirmation of their desire to do so. After confirmation, some data migrates between servers and the user starts working with version +1. Theoretically, there should be a mechanism to return to the old version (-1), but I can’t find such a button yet – apparently, it’s only available to those who contact support.

Typically, online services prefer to change transparently and imperceptibly to the user. Suddenly, new settings appear in the options, etc. If something goes wrong, you can’t roll back. If there is a migration to a new version with user confirmation, it usually happens not for mass services (like “hosting”) and, typically, only between a couple of versions – “very old” (“old UI”) and “brand new” (“new UI”), after which (brand new+1, brand new+2, etc.) changes are unnoticeable to the user.