Enterprise Application Development

WaveMaker Prefabs – A Primer

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.

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)

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’s Facebook 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 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 Fb post 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 themselves.  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 a 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 the 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 widget.  All that user has to do is 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.

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.

All the REST APIs in the Prefab can also be published for sharing and consumption by other apps.  This is similar to the 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 blogs, I had explained in detail 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 check out 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.

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

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 in which 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.

Check out 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!

[#] – Planned for future releases

Enterprise Application Development

Docker from Development to Deployment

[vc_row][vc_column][vc_column_text]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, let’s 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 lightweight.  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.

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.
  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 their 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 the 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.  The developer just says “It worked for me”.  All these kinds of excuses are going to be a thing of the 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 it 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, it’s 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 a 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 (an interval of one to few days) using continuous delivery processes 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 the 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.

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 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 it’s 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 offer tremendous flexibility to update to newer app versions 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

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 is 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 take a look at WaveMaker’s case-study on “How WaveMaker Got Faster, Better, More Agile with Docker”.  It also touches on the general benefits of Docker and issues of management complexity.[/vc_column_text][/vc_column][/vc_row]