Just over three months ago, we launched a new portal for technical practitioners—IBM Demos.

IBM Demos is designed to let customers get hands-on experience with a broad range of IBM solutions and capabilities.

If you missed my first blog post about it, be sure to read “Three Reasons to Check Out IBM Demos“ before moving on, as this post will focus on the architecture behind the scenes.

Before I get into the details, though, a quick bit about why you might care about architecture. Obviously, as a consumer or user of a site, you just want things to work. However, in order to keep everything performant as traffic grows, the site needs to scale to continue to provide an excellent user experience.

My hope in sharing this information is that you might learn something about how to design your application on IBM Cloud AND handle the type of growth that we’ve seen—such as handling the 70,000+ users since we launched the site. It’s not just talk; we drink our own champagne so our customers can too.

So, let’s get into it.

IBM Demos is a microservices-based application that leverages a combination of open source technology, PaaS services, SaaS services, and custom development. We chose this hybrid combination to allow us to focus on our core competencies and drive business value, as opposed to trying to build everything from scratch. This is a common pattern many enterprises have adopted, and it’s easy to see why. However, before I get into the why, let me describe a bit more about the architecture itself.

While the core application is built of many microservices that each have specific functions, those microservices can be grouped into three major groups: data, back-end services, and front-end web interface.

Front-end services

We leverage Akamai’s Global Traffic Management to give our worldwide user base the best performance (and reliability) possible by balancing the web traffic across a React app running in three different IBM Cloud data centers. Each of these apps leverages Cloud Foundry to provide the runtime for the app to run, leaving the heavy lifting—from a host perspective—to the IBM Cloud infrastructure. We use Redis for session and state management across the instances as well.

Back-end services

IBM Demos also employs a variety of back-end microservices that handle the various responsibilities required to manage the content, reservations, clean up, reporting, and other functions required to provide a robust and secure service. These services are written in Node.js and also run as Cloud Foundry apps.

Data and content management

Ultimately, users visit IBM Demos for the content within it, so let’s take a quick look at how we handle the data. We leverage a managed DBaaS (Cloudant on IBM Cloud) for our operational data and to cache the content for increased performance. We also use a managed hosting provider to ease the deployment considerations for our core content authoring management system (CMS), which is based on Drupal. Rather than trying to build a complete CMS on our own, we opted to go the open source route. This let us focus on molding a preexisting solution to fit our specific use case requirements and drive forward value for our users.

While we also leverage a slew of other SaaS and open source services to provide monitoring, notifications, ChatOps, and other functionalities, I’ll leave that for a future post.

Seeing is believing—give it a try

I’ll wrap up this article the same way I did last time. While I hope you learned something about the architecture, ultimately, I hope you don’t just take my word for it and will try IBM Demos out for yourself.

When you do try out IBM Demos, you’ll also now have a much greater appreciation for the design and architecture that keeps it operating smoothly behind the scenes as well.

Please feel free to reach out to me directly with your comments or questions. As always, I’m available @TalkToErik.