Addressing a uniform language based app stack

In the past I've been a proponent of ployglot development  - wherein one project contains a host of different languages - such as Javascript on the frontend backed by a mix of various server side languages like java/.Net that make up the application level layer and its corresponding business layer and which further interacts with a domain driven language/tool like SAP abap/ERP which could (theoretically be coded in an altogether different language).
Having said that, developing and maintaining such an application in the real world quickly escalates into a proverbial fireball that gets tangled in the different parts of the application. Now let me explain this - for instance, a part of team is writing a web-service in java, and another part is writing a different part in python. This leaves with no scope of inter-operability in future (if one needs to mix and match say 2 functions of these two services). I can also cite example of Ruby On Rails into this, where the fairly immaculate ruby code gets interspersed with bloated html code, which leaves a bad taste in the maintainability of the application.

A wonderful example is the case of node.js which has proven why a fairly consistent language helps alleviate issues of managing different languages in a single application, thereby creating fewer bugs and reducing the overall development coordination and time.

I've found scalaJs to be an equally good tool to be used in Play/ scala based web applications and services which require complex frontend development as well. Hopefully, I'll be able to write some applications to try and assess its impact over conventional apps.

On why we fail at DevOps

Seeing that devops practice does not really seems to be taking off in my present workplace, I decided to decode the underpinnings of the concept and try to interpret what is perhaps not going in the desired direction and more importantly, what is required to be applied which will enable this transformation.
In different texts, I came across a common theme that covered DevOps in detail and each pointed out to The 3 principals underpinning the devops practice [http://itrevolution.com/the-three-ways-principles-underpinning-devops/]

Arguably, DevOps is about making that process of build/release transparent and automated to make this process smoother, but just like agile, it is more than just tools (ant/maven/, jenkins, sonar, docker,etc.) but is more of the discipline that needs to be imbibed. Few years back, most of the server side application developers used to treat UI like anathema but due to rise of Javascript as a first class language, one can not longer resist being a full stack developer. In somewhat a similar discipline, there is a need for developers to treat build configuration (gruntfile, dockerfile, etc) as a vital portion of codebase and likewise for system administrators, who also require repository access to check-in their changes.

In monolithic softwares like SAP Hybris, directly building docker images are a challenge at the moment as only the datahub, essentially a tomcat web application can easily be dockerized. But it remains to be seen whether we will have more microservice/YAAS based approach in the post 6.3 releases of Hybris.

my two cents

Turbocharging SAP Hybris with SAP HANA

In my current work with Hybris, in most implemented solutions, scalability challenges come at persistent layers where there is a little say over data management (due to Item modelling created within the persistence layer in hybris) to normalize/optimize the database. To overcome it, I am currently trying to utilize SAP HANA, which is a relational database offering benefits of NoSql databases as well (as it is a RAM residing database which offers instantaneous data results akin to other OLAP offerings).

First, I sign up with SAP Cloud Platform which is currently offering a full scale HANA instance for 12 hrs (you would need to restart the instance). After this, I can create a database on the SAP Cloud Platform Cockpit as well as view my login credentials.

Next, I set that up on my local machine via eclipse. To use eclipse, one needs to install hana library (which I did via this update site : https://tools.hana.ondemand.com/neon on my Eclipse Neon).

Here I can see various infrastructure related things that can be modified to set the database level user management as well as utilize Hana for other things like predictive analysis, real-time machine learning from the available data, etc.

 

Now that our connection has succeded, we can create a little jdbc application to test the credentials that we used to confirm whether we can connect with the database. We will need to have the Hana java driver in the classpath to make this happen.

 

It is worth mentioning that as the database is tunneled via the Hana viewer, the host becomes localhost:30015 and the user name/password is the one that you have set for the database instance (not the S/P user ID that SAP gave you or the userd id of the SAP Hana Cloud instance)

After this, we can trivially set this up on Hybris via the following db configuration in local.properties:

db.url=jdbc:sap://localhost:30015/?reconnect=true

db.driver=com.sap.db.jdbc.Driver

db.username=

db.password=

Start the Hybris and initialize it (note the DB name in the following image)

After initialization, you can use Hybris as an e-Commerce/CRM solution and utilize HANA as its extremely fast and fault-tolerant backend system.

My experience was that it was not as blazingly fast as it is portrayed to be, but then I am just using a 2MbPS connection but YMMV.

What was your experience ? Do let me know in the comments below or shout out to me @sumitbbd your experiences.