Category Archives: DevOps

Posted on Wed, Mar 20, 2019 @ 11:20 am

In this series of blog posts, I will take you through the steps involved in the design, architecture, and implementation of a fully functional Enterprise Blockchain Application. I will do that by sharing content from various stages of developing a sample application we (OFS) built for Loan Origination and Payment on Blockchain. If you follow through the end of this series, you will have a better understanding of the internal workings of a blockchain application.

We are building this application in IBM Blockchain Platform 2.0 Beta. Please check out my previous post — IBM Blockchain Platform 2.0 Beta: Run your Blockchain N/W in 10 Simple Steps for better continuity.


The objective is to develop a Decentralized Application that explores potential business benefits of using blockchain like

  • Improved process efficiency
  • Economy of scale
  • Privacy when you need it
  • Transparency and trust
  • Decentralized data with a logically centralized view
  • Recording of payments onto a blockchain

Use case and Actors

The use case we picked up to meet our objectives is a Loan Origination and Payment Application. The actual implementation of the use case doesn’t cover all intricacies and regulatory aspects of the loan origination and payments process but will be a good indicator of the design aspects to consider while building a DApp on the blockchain. The actors in the app are

  1. The Credit Reporting Agency — publishes the credit report of the citizens of demo universe to the Blockchain network. Controls access to the reports through smart contracts.
  2. The Property Title Search Organization — publishes the title report of the properties in the demo universe to the Blockchain N/W. Controls access to the reports through smart contracts.
  3. The Borrower (Applicant) — applies for a loan → receives proposals of various T&C from lenders → obtains the loan → makes the monthly payment, all on the blockchain.
  4. Lender 1 — fully utilizes all that blockchain has to offer, hence the fully automated business process behind the proposal response to the applicant.
  5. Lender 2 — still follows some traditional business process, slowly embracing blockchain.
  6. Consortium — facilitates onboarding organizations and establishes the governing principles of the business network.

Blockchain Business Network

The Blockchain business network of the application looks like this:

Use Case Flow

Animated use case flow

Technical Design and Architecture

IBM Blockchain Platform Business Network Architecture

  • Every organization in the network has a CA and a peer node.
  • A private channel is established between the consortium orchestrator and lenders to securely share proposals, terms, and conditions of the loan with the applicant.
  • The chaincode to create and process the loans will be deployed to the peers of Lender 1, Lender 2, and the consortium orchestrator. We will review the chaincode in detail in another post.

Application Architecture

The design of the Blockchain network is just one piece of the puzzle. Application design and architecture is equally important. Consider the following as you design your application:

  • Although IBM Blockchain Platform with Hyperledger Fabric at its heart scales well when compared to the public blockchain platforms, it is not a transactional database, so don’t expect throughputs like traditional centralized databases have.
  • Use the blockchain for what it has to offer — trust, transparency, and immutability. Decide what you store in your blockchain based on that.
  • Embrace asynchronous event-driven programming — the blockchain nodes are only eventually consistent. The consensus process is not instantaneous.
  • The data in the blockchain is secured by design through encryption and various governing principles of the network, but the security stops at the blockchain network level. You should still address the application security with your design.
  • Think about GDPR-like regulations before you store personally identifiable information onto the blockchain.


We followed a modular microservices architecture. The complexity of interaction with the blockchain itself is abstracted out to a generic component that knows how to invoke chaincode to read/write data from/to blockchain. This helps to keep the other services lightweight and flexible.

Internal components of the architecture

As you can see we are expanding the IBP network to include a node running in AWS, showing the multi-cloud ability of IBM Blockchain Platform.

Data Flow

  • The microservices expose REST APIs for the presentation layer to consume.
  • The services delegate calls to the Hyperledger Gateway for blockchain invocations.
  • The blockchain calls are asynchronous. Once the transactions are added to the blockchain the Event Hub pushes the signal to all interested subscribers through a callback endpoint.
  • We use WebSockets for the presentation layer to react to the events from the Event hub.

Data flow diagram with synchronous (red) and asynchronous (black) calls

Service API Definitions

Borrower (Applicant) Services

Lender Services

Partner Services

Asynch Blockchain Invoker

Event Hub Services

Check out our swagger hub documentation for the APIs

I hope you’ve been able follow up until now. We will catch up on the design and development of the chaincode in my next post.


About the Author






Ganeshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.

Posted on Fri, Apr 1, 2016 @ 7:28 am

This is the second blog in ObjectFrontier’s series on DevOps. To view the first blog in the series, “An Intro to DevOps: How DevOps Fulfills the Promise of Agile,” click here.

In a November 2015 Forrester report, “Forget Two-Speed IT; DevOps Enables Faster Delivery Across the Board,” analyst Kurt Bittner references a 2015 Forrester survey in which global business decision-makers were asked, “Which of the following initiatives are likely to be your organization’s top business priorities over the next 12 months?” The top three answers were improving their products and services, improving their customer experience, and addressing rising customer expectations.

It’s not surprising to us that customer experience and rising customer expectations ranked at the top of the list. In fact, it’s practically obvious that these would be the top concerns for any business. It’s also probably clear that the first priority—improving products and services—is what we believe ultimately dictates whether businesses are keeping their customers happy.

It seems that every tech industry analyst, blogger, expert and “guru” has touted DevOps as the key to improving how businesses deliver better products and services that win customers in a warp-speed digital marketplace. Perhaps your business is planning to implement DevOps automation, hoping that the promise of rapid software delivery and deployment—without the headaches of a stop-and-go process—will ensure your next product is in customers’ hands faster than the next leading competitor can even get their product through testing. However, DevOps doesn’t just mean faster delivery. In fact, your business—and even your company culture—can benefit in multiple ways from DevOps automation.

In his report, Bittner goes on to discuss three dimensions of DevOps—process, technology and people—that we feel not only ensure faster delivery but actually enhance product quality and team collaboration. Here are just a few benefits that we believe each dimension can bring:

  • Process—One of the greatest strengths of DevOps automation is its ability to break down the walls that put product delivery on pause. DevOps methods provide ways for developers to work in smaller increments and get feedback from real users, which results in a digital product that truly meets customer needs. DevOps also promotes value-stream mapping, which allows organizations to pinpoint and eliminate unnecessary hand-offs that slow down product development and waste valuable time.
  • Technology—Bittner says “loose architectural coupling is the ‘secret sauce’ of faster application delivery.” This allows for your business’s multiple services to work independently of each other, so it’s possible to make a change to just one service without releasing a whole new application. DevOps also allows developers to decouple releases from your customers’ experience, so your business has more control over how, when and to whom a new capability is offered.
  • People—DevOps automation flourishes with cross-functional product teams of people who possess skills across business, customer experience, development, quality assurance and Ops. This translates to more productive collaboration that brings faster delivery and high-quality results.

The report mentioned in this blog, Forget Two-Speed IT; DevOps Enables Faster Delivery Across the Board, was previously available on this site. If you would like a copy, please contact us directly. This report also is available to Forrester subscribers or for purchase here.

Posted on Wed, Jan 20, 2016 @ 2:12 pm

At the turn of the century, the world of software development was introduced to a DevOps_1revolutionary new concept—AGILE! No longer were organizations stuck using the time-consuming and inflexible waterfall model to develop quality software. Software’s brightest minds began to champion this radical new method of product development for all its many benefits. It was a way to work fast, embrace changing requirements, produce deliverables frequently, and encourage close collaboration, all while focusing on technical excellence, good design, and customer satisfaction. With such glorious qualities, agile was all we needed, right?

Agile is certainly essential. For good reason, it is embraced by top software companies as the best way to build modern, innovative software products in today’s fast-paced, digital age. Development organizations are able to churn out excellent software at a rapid rate in the hopes of keeping their business at the forefront of their market.

However, even with all this, there is something agile lacks in the software production lifecycle. When a development organization is finished with their agile process, the software is still not done. It’s not immediately ready for final release, but instead heads over to the operations department to be prepared. Even though agile does so much to speed up software development, the benefits of that speed often are never fully realized since the software gets stuck in deployment limbo while operations makes it production-ready.

It would be easy to blame the operations department for this delay, yet the holdup is not usually either side’s fault. It’s really just an inherent part of the challenge of creating product software, as it is built in one environment and then deployed in another. A lot of time must be spent to ensure that all the code written in the development environment fully translates over into the production environment. Moving thousands of files at once, given all the intricacies and complexities of modern product code, requires great attention and multiple eyes to get everything in working order, so it’s no wonder this is a time-consuming process.

Unfortunately, with delay comes frustration. It’s often easy for one department to point the finger at the other, leading to mistrust between the two groups. Developers pour their hearts and souls into creating awesome software that runs flawlessly on their machines, but once it heads over to operations, they are no longer responsible for it. The operations guys are tasked with getting the software into production and making sure it runs properly. They assume the code they’re receiving works, but they often find out it breaks in production. Their systems get frazzled, and it can take them forever to recover. Operations puts up barriers, feeling they can’t trust the developers’ software. More hurdles are put in place, and it can take many long months back and forth between development and operations to actually release the software.

This presents a challenge to businesses – How do I streamline this process so we can get software out the door as fast as we can build it? It does no good to build software quickly using agile to have it sit for months as it’s prepared for release.

These frustrations around development and delivery have created a revolutionary movement combining not only infrastructure automation, configuration and deployment, but also combining people from Dev and Ops, known together as DevOps. The essence of these DevOps efforts mirrors those of agile development, as it seeks to produce results quickly and increase communication across all teams involved. What agile is for development, DevOps is for deployment.

Eureka! We’ve finally found the missing piece for creating an all-around speDevOps_2edy cycle of software production. Embracing DevOps means increasing the cooperation between Dev and Ops, incenting both sides to get software out the door more quickly.

The operations team has to get involved with the development team from the start, giving their advice up front. This allows the developers to broaden their focus and really see and understand the ecosystem in which their software needs to fit while they’re building it.

Automation tools help in creating development environments that more closely mimic production environments, giving the developers the right place to test things from the start.

Processes of continuous build integration and automated migration help to automatically compile code and move it into production so nothing gets lost and the quality of what’s created stays high.

All of these tools and collaborations allow software products to move much more quickly into final production. With this new swiftness and collaboration between development and operations, DevOps is finally fulfilling the speedy software promise that agile development boasts. Delivering new software is completely streamlined, as cleaning up this transition relieves many headaches and frees up time for your top talent to get back to what you do best – delivering outstanding products and services to your market.

Look out for our next blog coming soon in this series on DevOps!

OFS, as a forward-thinking software engineering firm, decided to invest in DevOps several years ago, seeing it as a way to help our customers bring speed to the production side of their software, just as our agile methods do for the development side, enabling shorter time-to-market. Along with our expertise from two decades in software product engineering, we help our clients automate the provisioning, configuration, build, test, deployment and monitoring of software systems using the best DevOps tools available.

To hear how OFS can help you improve your DevOps efforts, click here