WaveMaker Prefabs – A Primer

June 30, 2015
by Karthick Viswanathan

What are Prefabs?
In WaveMaker Studio, you would have noticed this unassuming group of components that are stashed in the Design-Toolbox accordion and contains components like Youtube, Google-Maps and Fbpost under it.(Fig-1).  These group of widgets are called Prefabs.


Fig-1: Prefabs group of widgets

But what are they?  What’s their purpose of existence? These are exactly the kind of questions that we will try to answer in this post.

At a very basic level,  Prefab is nothing but an application.  Like an application, you can develop, test and deploy these Prefabs independently.  User can stack up a group of Prefabs and build a new app.  Prefabs typically represent a small independent logical business need of the enterprise app (a micro app).  For example, an Event Management Prefab.


How are Prefabs structured?
Structurally a Prefab is like any other WaveMaker app containing a UI layer for presentation, a backend layer representing the business logic and a REST API layer between them for communication.  (see Fig-2)

Fig-2: Prefabs Design

For example, the Fbpost Prefab, provided by default in WaveMaker Studio,  has a UI layer, wherein it accepts inputs from the user to post a message into the user’sFacebook wall, passes on these user inputs through REST APIs to the backend business logic, which communicates with the Facebook server to post the message.

Prefabs fosters the concept of reuse

I have already explained on how Prefabs are just micro-applications that can represent an independent business logic like Event-Management.  But in explaining that one important point would have got lost, if not for this section on reuse.  This Event-Management Prefab once created can be re-used across any apps within an enterprise.  This concept of REUSE is a very powerful one and is often not given its due share of importance in an application building process.

Prefabs abstract API consumption complexity
Prefabs are essential tools in abstracting the complexity associated with API consumption and saving a lot of time.  Business developers in an enterprise usually find it difficult to understand the intricacies of the APIs because of the technical nature of its existence.  In the example above, instead of using a Fbpost Prefab, if the user had to directly work with the Facebook APIs, then that immediately increases the complexity associated with the task manifold.  API complexities range from understanding technologies like OAUTH for authentication to understanding the semantics associated with APIs itself.  But what if these complexities are abstracted and presented as simple intuitive UI components? …that is exactly what a Prefab does.  Of course, there is an one time effort in creating the Prefab itself, but WaveMaker envisions an app and Prefab marketplace where these common utility Prefabs can be just got out of the box and integrated into the app.

Prefabs to assemble your apps
Composable Enterprise, a concept where the applications are built based on the composition of decoupled services to achieve higher levels of agility, is a concept that is gaining prominence.  You can learn more about composable enterprise model in this blog written by Jonathan Murray, EVP and Chief Technology Officer of Warner Music Group.  WaveMaker uses a Prefab to ease the process of building composable apps.

In WaveMaker, Prefabs are used like any other UI widgets.  All that user has to do is to drag and drop these Prefabs onto the canvas.  Prefabs use their REST API layer to communicate with the parent app (see Fig-3).  Applications can be built as stackable layers of Prefabs.

Fig-3: Stacked prefabs to assemble an app

And finally, when an application gets deployed, WaveMaker resolves all the Prefab dependencies of the app and deploys the app as one single component into a Docker  container as shown in Fig-4.

Fig-4: Prefabs and app in a docker container

All the REST APIs in the Prefab can also be published for sharing and consumption by other apps.  This is similar to design and sharing of APIs in an app and is done using API Designer.  If you are interested you can read my earlier blog post that talks about the capabilities of the API designer in detail.

Prefabs to integrate 3rd party widgets
Prefabs are powerful tools for extending the capabilities of the WaveMaker Studio.  Whenever the developer feels that a particular widget, available externally,  is not available natively in the WaveMaker Studio library, he or she can immediately integrate that external 3rd party widget into WaveMaker Studio library using Prefabs.  Prefabs in a way extend the capabilities of the studio through this approach.  In one of my earlier blog, I had explained in detail on how you can integrate an external 3rd party Jquery widget.

Prefabs as Microservices [#]
Microservices (MSA) is a new (yet another!) software development architecture, which is gaining prominence.  In this approach, a bigger app is built as a composition of  small decoupled services, called Microservices, which typically represents an independent business need.  These micro-apps are connected together by APIs (primarily HTTP/REST APIs) to build a bigger app.  These Microservices also have technical characteristics that include independent testability, deployability and upgradeability. For a more detailed explanation of MSA, you can checkout Martin Fowler’s article on Microservices here.

By now you would have noticed that Prefabs perfectly fit into the definition of a Microservice as defined above, word for word. As WaveMaker takes its next step into the future to enable Microservice based apps, Prefabs will play a significant role to ease the process of creating and deploying MSA based apps.

Checkout the sample reference architecture (Fig-5) of an MSA app created using WaveMaker and Prefabs deployed into separate Docker containers in WaveMaker Cloud platform.

Fig-5: Prefabs as Microservices – Reference Architecture

Prefabs ecosystem [#]
Prefab is a great utility for achieving modularity, reusability and abstracting complexity in WaveMaker,  but it’s not free lunch either.  There is a one time effort that is involved in creating a Prefab before the user and the enterprise can reap its benefits.  But to even reduce this one time creation step, a simple effective utility, which has revolutionized the way inwhich people consume services in this digital world, can be used.  This utility is called a MarketPlace or an AppStore.  Once an ecosystem of the commonly used Prefabs and apps is established, the consumption of these Prefabs will be as easy as discovering the Prefabs in the AppStore and integrating it into your app.

Checkout the below image that captures the overall prefabs usage succinctly.

Prefabs can be quite a powerful tool if used strategically and can make the concept of composable enterprise come true very easily.  Excited to try Prefabs? Create your WaveMaker app now!

Key
[#] – Planned for future releases

Docker from Development to Deployment

June 29, 2015
by Karthick Viswanathan

Are we bracing ourselves for a world where we are going to see developers, testers and other stakeholders in a development process working on their own sandbox containers?  The answer seems to be a resounding YES.  Let’s jump into the concept of container driven development (CDD) – I think I just found a new acronym that’s going to be famous, in a world that’s begging for more acronyms :).   Or do you think DDD – Docker Driven Development, sounds better than CDD? (;-) Anyways, let’s jump in.

In an application life-cycle process, lets take the 3 biggest stages – Development, Testing and Production.  This post is going to focus on how Docker containers can play an active role in each of these life-cycle stages and benefits that can be derived from them?

Note, I am going to make assumptions (like just 3 life-cycle stages) to keep this post short and concise, but an enterprise is free to extrapolate and devise better ways of doing the same.

Develop in a container
Consider a scenario where every developer builds his application inside a container, which is provisioned exclusively for the project being developed.  These Docker based containers are extremely light weight.  They can be instantly provisioned in a developer laptop or an enterprise server infrastructure that can be accessed remotely through console utilities.  These development containers will be based on a Docker image that can contain all the relevant utilities for a developer.  Docker image itself can be stored in a Docker Registry.  These containers, based on the Docker image, can be provisioned in a matter of seconds. For example, if a new developer joins a team, he can provision a container instantly with all the utilities (like Eclipse IDE) pre-installed.  And finally after the developer gets his app to work, he can push the image of the app-build to the registry.  A docker container for a developer can look like how it is shown in Fig-1.


Fig-1: Sample Docker container during development stage

A container has 2 primary configurations to it.

  1. The hardware configuration is a factor of 3 parameters – CPU, memory and disk.  A sample configuration of Dev, Test and Production containers are shown below in Fig-2.

    Fig-2: Sample container sizes for various life-cycle stages.
  2. The software stack is contained in the container.  In this case, from Fig-1, you see that the Dev-Container has Eclipse, Java and Tomcat as a part of it.  There is also a dedicated DB container that is used by the development team that contains MySQL as a part of the container.

Also note that the utilities that need modifications to its configurations like the DB settings, utilities for monitoring and log files need not be a part of the container necessarily.  They can be configured when the same container is provisioned in different release stages.

What are the benefits of using containers during development?

  • Instant provisioning of the requisite hardware resource as a container
  • Instant provisioning of the requisite software stack configuration of the container
  • Option to de-provision container if it’s not used (Needs to be coded)
  • Integrated DevOps.  The development and operations are not disconnected anymore.

 Test in a container
Once the app-build (See App v1.1 in Fig 1 & 3) image is pushed into the registry by the developer, it indicates that the build is ready to be tested.  In pre-container days, the tester would set up a new physical machine or a VM instance, install the requisite software, and then deploy the app.  It never worked the first time.  Developer just says “It worked for me”.  All these kind of excuses are going to be a thing of past, now that the containers have emerged .  In my previous post on Docker, one of the benefits I highlighted was “Guaranteed Reproduce-ability”. That means, by packaging your ap­pli­ca­tions into containers you can be sure that they will run as id did in a development environment, wherever they are deployed. In summary there is a guarantee of reproducing the same behavior wherever it is executed.  Hence when a Tester/QA provisions a container based on the app-build image, its guaranteed to work as it did for the developer.
QA can provision individual containers for themselves to focus on various aspects of the app like performance etc or all individual QA members can work on just one provisioned test container and focus on particular area/feature of the app.
QA can find bugs in the app that can be reported back to the development in no time and this process can speed up the overall delivery process, with a little automation. In fact consumer facing services/apps like Amazon do multiple releases in a very short span of time (in interval of one to few days) using continuous deliveryprocesses and containers are going to make that even more faster.  The idea of having a 1:1 mapping between the app being developed and the container also speeds up the delivery process with a lot more clarity, since now the deployment of app is nothing but simply provisioning a container.
At this stage of the app lifecycle the testing containers are provisioned and the lifecycle is visually represented as in Fig 3.


Fig-3: Sample Docker container during testing stage

What are the benefits of using containers during testing?

  • No more writing huge complex scripts to deploy apps and make them work
  • Developers can heave a sigh of relief – no more excuses like “It used to work for me”
  • Automate everything.  No time wasted.  Execute continuous delivery and make frequent product releases

 Deploy in a container
Once the the app build has passed the QA, it’s ready to be deployed into the production environment.  All that needs to be done is to provision a new production-container (bigger size as given in Fig-2) and its all set.  The guaranteed reproduce-ability will make sure that the app deploys and works as effectively as it did in the dev and testing environments.  There are few more steps like migrations of DB, services etc but that looks like a topic of another blog post.
The instant provisioning and de-provisioning of containers offers tremendous flexibility to update to newer app version with rolling upgrades or blue-green deployment.  The lightweight nature of the container also makes the localized error detection and fixing extremely easy.  All that needs to be done is to image the production container and move it into a debugging environment for a quick inspection.  An app in a container has also added fuel to the new MicroServices based app architecture, where independent modules are deployed in separate containers and are scaled independently.  The commoditization of hardware and container based PaaS platforms offer tremendous benefits to instantly scale the application.  Check out my previous blog for more details on localized error detection, horizontal scalability and lightweight containers .

The complete app life cycle after the app is deployed into production should something like this(Fig-4)…


Fig-4: Sample Docker container during production stage

What are the benefits of using containers for the production phase? 

  • Every app gets a container. targeted error detection.
  • Instant rollback of faulty builds
  • Rolling upgrades with zero downtime
  • Enabled for Microservice apps
  • Instant horizontal scalability

So, What next?
It all seems so easy isn’t it? Not really.  There are a lot of unresolved issues during this app delivery process that are being/yet-to-be addressed.  Some of them include..

  • Continuous deployment needs governance semantics around it
  • Migration from one life-cycle stage to another (say dev to testing) requires migrations of DB, services, logs etc and that is not easy.
  • Do-It-Yourselves options for managing containers are not there.  Still this area looks geeky with command line options.

 How can you solve this? Are there any tools that can ease the task for you? I would suggest you taking a look at WaveMaker’s case-study on “How WaveMaker Got Faster, Better, More Agile with Docker”.  It also touches on general benefits of Docker and issues of management complexity.