Running Hadoop with Docker Containers

If you play around with Apache Hadoop, you can hardly find examples build on Docker. This is because Hadoop is rarely operated via Docker but mostly installed directly on bare metal. Above all, if you want to test built-in tools such as HBase, Spark or Hive, there are only a few Docker images available.

A project which fills this gap comes from the European Union and is named BIG DATA EUROPE. One of the project objectives it to design, realize and evaluate a Big Data Aggregator Platform infrastructure.

The platform is based on Apache Hadoop and competently build on Docker. The project offers basic building blocks to get started with Hadoop and Docker and make integration with other technologies or applications much easier.  With the Docker images provided by this project, a Hadoop platform can be setup on a local development machine, or scale up to hundreds of nodes connected in a Docker Swarm. The project is well documented and all the results of this project are available on GitHub.

For example, to setup a Hadoop HBase local cluster environment takes only a few seconds:

$ git clone https://github.com/big-data-europe/docker-hbase.git
$ cd docker-hbase/
$ docker-compose -f docker-compose-standalone.yml up
Starting datanode
Starting namenode
Starting resourcemanager
Starting hbase
Starting historyserver
Starting nodemanager
Attaching to namenode, resourcemanager, hbase, datanode, nodemanager, historyserver
namenode | Configuring core
resourcemanager | Configuring core
.........
..................

Lightweight Docker Swarm Environment

In the following short tutorial I want to show how to setup a lightweight and easy to manage docker-swarm environment. This environment is an alternative to the mostly heavyweight solutions like Rancher or Googles Kubernetes. For developers and companies that are not compelled to operate over 1000 machines on 4 different continents, this can be a clever alternative.

The docker-swarm environment, I am demonstrating here, uses Docker Engine CLI commands entered into a terminal. But as we’ll see, this environment also includes a very nice UI front end. You should be able to install Docker on networked machines and be comfortable with running commands in the shell of your choice.

Continue reading “Lightweight Docker Swarm Environment”

Why we Should not blindly Trust in Microservices

Today, a great deal is written every week about microservices on the Internet. I myself think, that Microservices offer many advantages. And so also I build such kind of services in my own open source workflow engine project. But today I read an article about Microservices which contained a funny picture. The picture should underpin the advantages of separating functions into a microservice architecture with an almost non-existent centralized management. The picture looks something like this:

I asked myself: Which of the two diagrams appears to me, as a software architect, as the clearer one…?

Have we not worked out for years an architecture, that allows us to reduce complexity? With Java EE, which seems to be an synonym for the evil monolithic architecture, we have now a concept which allows us to combine and connect different components (services) in an easy way. And with Java EE application servers we have a professional platform to control all these kinds of services.

Of course, it is painful to learn all the concepts about EJBs, Transactions, JNDI Resources and Pool-Management. And yes, as a beginner you are confronted with all these concepts if you try to succeed with the Java EE platform. But after that, you have a highly scalable, easy to manage platform running your piece of software.

When I am reading all the adulation for having separated databases, with services implemented in different languages, connected to each other without explicit contracts, I’m pretty sure, that in the next few years we have a lot of work, to bring back systems to the left side of the image.

How to Setup a Private Docker Registry

In this short tutorial I will show how to setup a private Docker registry. A private registry can be helpful if you want to distribute docker images in a large developer team or provide docker images to your customers. The tutorial assumes that you have a server with a docker daemon running in your network environment or internet. The goal is to push locally build docker images to the docker registry, so that other team members or customers can pull those images without the need to build the images from a Docker file. In the Imixs-Workflow Project we use such a private registry to support our customers with custom docker images. Continue reading “How to Setup a Private Docker Registry”

Why we should secure Business Objects?

Most applications deal with security in a functional way. This means that a business application typically defines different functional roles which are mapped to different users. For example let’s look on a simple Ordering System. In an Ordering System we will have roles like

  • Order-Creator‘ – creating the order
  • Order-Approver‘ – validating and approving
  • Order-Executor‘ – execution

These roles are typical for such an business application and mostly tightly coupled to the corresponding business methods – e.g. createOrder(), approveOrder() and executeOrder(). This works well in a monolithic business application where we can control the security layers as also the business logic. But as more complex the business application becomes, also the enclosed security becomes more complicated. For modern application design in addition we often have to deal with external web services and business logic which need to be adapted easily to changing requirements. So this static security model leads into a hell of hard coded business rules or, what is worse, can no longer guarantee the security. Continue reading “Why we should secure Business Objects?”

Why it’s Better to Trust in Java EE?

These days it seems to me that everyone blabs about the blessing of microservices and the new architectural style. In most articles about the new glory architecture of microservices, it’s generally assumed, that Java EE is slow, dull and scales poorly. There seems to be a big misunderstanding about what Java EE really is. And I even assume that not many of the young believers in the new world of microservices have engaged much with the concepts of Java EE. I’m taking here three examples each developer is confronted with. And perhaps you will rethink of these scenarios in the light of Java EE. Continue reading “Why it’s Better to Trust in Java EE?”

JPA and @OneToMany – How to Optimize?

In this article I want to explain an issue concerning the JPA OneToMany relationship which I was faced with in one of my own projects. Working with object -orientated languages like java we often model relationships between object in various cases. One of such relationships is the OnToMany relationship. For example an object ‘Server’ may have a relationship to an object ‘Configuration’. To make the ‘Configuration’ object generic we can model the JPA object in Java like this:

@javax.persistence.Entity
public class Configuration implements java.io.Serializable {
 private static final long serialVersionUID = 1L;

 @Id
 @GeneratedValue
 private BigInteger id;

 public String itemValue;
 public String itemName;

 @SuppressWarnings("unused")
 private Configuration() {
 }

 public Configuration(String name, String value) {
 itemValue = value;
 itemName = name;
 }
}

Continue reading “JPA and @OneToMany – How to Optimize?”

How to Design a Business Process Service Architecture

In my last blog I introduced the concept of a “Business Process Service Architecture – BPSA“.  This architectural style can be used to design a business process running in a microservice architecture, even when all services are decoupled strongly as single verticals.

 

The idea of this concept is, that a separated microservice is running the “Overall-Business-Process” decoupled from the verticals. The business process reflects the workflows implemented in the organisation of an enterprise. These workflows may also be often non-technical and human-centric. For example, the shipment of a product is usually performed manually, but also impacts the technical layers. So the question is: How can we coordinate our vertical service layers to align them to an “Overall-Business-Process”?

I want to explain the concept of BPSA first on a scenario which I visualize with the help of BPMN 2.0. The scenario is based on the example that I used in my first blog. The BPMN model I show here, was created with the Eclipse modelling Tool Imixs-BPMN, but first of all, this model is independent of the later used workflow engine.

microservice-architecture-bpmn

The Model shows four different workflows. One workflow for each vertical and the “Order Management” Workflow  which reflects  the Overall-Business-Process. The model is kept very simple to only show the key facts of the concept.

Starting a New Process Instance

The business logic of a vertical does not happen by itself. There is typically always a triggering event that starts the business process. In our example, this is the reception of a new order. A new order can be received manually by a phone call or an E-Mail, or automatically triggered by another IT system, e.g.  a online shop software. So once a new order is received, we start a new instance of the “Order Management” Process with the task “Receive Order”. The BPMN event “new Order Process” immediately starts the sub-process called “Order”, which is presenting the micro-workflow of the vertical ‘Order Service’. This sub-process can for example callback the microservice to create a new order dataset in a database.

But this is not necessary the only way to start the process. It is also thinkable that the Order Service will start the “Order Management” Process by itself because it’s the piece of software receiving the order details. Or for example the external IT system could trigger both verticals –  the “Order Service” and the “Order Management” Process. The important thing here is, that after we received a new order we start a new Instance of the “Order Management” Process which is triggering the other involved sub processes.

So when we go back to the model example, now we have two new process instances – the “Order” which reflects the status of the vertical “Order Service” and the “Order Management” process which indicates the status of the general enterprise business process. Both processes are tightly coupled, which corresponds to the enterprise business process. On the other hand, the workflow service itself may be loosely coupled to the verticals, e.g. by a asynchronous reactive programming style.

Monitoring the Business Process

Once a new instance of the “Order Management” Process was started, we can now monitor the process including the status of its sub-processes. For example a Workflow Management UI can provide the sales manager with status information about current orders. This person has typically a high-level view on the process with is reflected by the“Overall-Business-Process”.  But also a back-end monitoring system can use the workflow service, for example to control the load of expected records in different databases. In both cases the workflow model can be extended with different tasks to detail the status of each process layer.

The Control of the Process

The interesting part of the example which I illustrate here, is how the process can be controlled by a microservice. As shown in the BPMN model, each vertical has its own sub-process model. And only the vertical assigned to a specific sub-process is allowed to trigger an event inside this process. The “Workflow Service”, on the other hand, controls and verifies the consistency of the business process along the BPMN model.

In our example the “Order Service” may trigger the event “finished” of the “Order” workflow once the service has created the order-record in an order-database. This event will immediately change the status of the “Order Management” Process from “Receive Order” to “Send Invoice”.  As a result of this status change, a new sub-process assigned to the “Invoice Service” will be created by the “Wokflow Service”.

As the order sub-process is now completed, the OrderService will no longer be able to send the “finished” event to the WorkflowService. A workflow engine will typically throw an exception in case a process tries to trigger irregular events. As each vertical can also monitor its assigned sub-process, each microservice can read the model to check the internal status and possible events to be triggered. As a result the typical business logic of a microservice to verify an internal business model can be reduced dramatically. For example we can design each sub-process in a generic style and always provide an event for a success-case and an error-case.

microservice-architecture-bpmn-generic

The benefit is that we can now control the process fully by the WorkflowService and decouple the service from the business logic. On the other hand a human actor may also be involved in the main process model. For example a warehouseman will be informed by E-Mail from the workflow engine that he have to confirm the shipment of the product. He can manually trigger a corresponding action from the Workflow Management UI. As a result of such a manual event the workflow engine may trigger another microservice.

How to Change the Process

In a productive environment, a sub-process will possible consist of a lot of different tasks and events, which can be triggered by the assigned vertical and monitored by different actors. Also the “Order Management” Process will typically contain more events to control the process in various ways. For example the sales manager may be able to trigger a “Cancel” event to stop the order management process. This status change would immediately affect all sub-processes which will be disallowed to send any further events to the main-process.

The advantage of this concept is, that the process models can be changed during runtime, without the need to change the implementation of a single vertical. This makes the concept strong and flexible and takes care about the typical business needs of a changing enterprise – an agile organisation.

Conclusion

Of course, the implementation of a Business-Process-Service-Architecture can be tricky in various details. Much of what is today typically hard-coded in the business logic of a microservice will be now transferred into a process model. For this purpose, also experiences with BPMN are required. But the effects of BPSA can be impressive, especially when the workflow engine itself covers a lot of the business logic. For example, a human-centric workflow engine like the open source project Imixs-Workflow, can send E-Mail messages, provide a process history, or distributes tasks to different actors to be involved in the process. Finally the microservices become smaller and can now indeed decoupled from each other.