From Silos to Services: Cloud Computing for the Enterprise

Aug 31 2016   6:18PM GMT

Cloud-Native Applications in Plain English

Brian Gracely Brian Gracely Profile: Brian Gracely

Red Hat
Image Source: Pixabay

Image Source: Pixabay

These days, you can’t attend any event without seeing some slides about “Digital Transformation” and how companies like AirBnB, Uber and Netflix are disrupting all sort of existing industries. At the core of these discussions is the premise that all companies need to become software companies (e.g. “software is eating the world“). And the types of software applications that companies need to build are called “cloud-native” and the applications are architected using “microservices”.

All of this sounds cool, but I find that so many of the people that discuss this on an everyday basis are very technical and assume that the audience has a similar level of experience and knowledge. So I thought I would take a functioning cloud-native application, using microservices (and lots of other stuff), and break it down into simple terms that hopefully make it easier for people to understand.

[Disclosure: This video/demo is from the Red Hat Summit 2016 keynote. My day job is with Red Hat. The reason I chose this video is not because of the company/products, but because it is long enough to see all of the moving parts – both on the developer and operator side of a set of applications.]

The applications come from this video, and start around the 43:00 mark.

An Overview

This is a customer-facing application. The application has the following characteristics. Think of these as the basic inputs that your product team might provide to the development team:

  • It can be accessed as a browser-based application or a mobile-application.
  • It involves user-interaction which updates the experience in real-time.
  • All user-interactions are tracked and stored in real-time, and based on the interactions, the system will apply business-logic to personalize the experience.
  • Both the technology teams and the business teams have visibility into the data coming from the user-interactions.
  • The application must have the ability to be frequently updated to be able to add new features, or be modified to adjust the experience based on interaction data.

Looking at these basic requirements, they include some basic elements that should be at the core of all modern applications [note: I created this framework at Wikibon based on interactions with many companies that have been leading these digital transformations and disruptions:

  1. The API is the product. While parts of any application may live in a local client, the core elements should be interacting with a set of APIs in the backend. This allows user flexibility, and broader opportunities to integrate with 3rd-party applications or partners.
  2. Ops are the COGS. For a digital product, the on-going operational costs are the COGS (Costs of Goods Sold). Being able to optimize those COGS is a critical element to making this digital product a success.
  3. Data Feedback Loops. It’s critical to collect insight into how customers interact with the business digitally, and this data must be shared across technical and business team to help constantly improve the product.
  4. Rapidly Build and Test. If the product is now software, it is important to be able to build that software (the applications) quickly and with high quality. Systems must be in place to enable both the speed and the quality. Using data as the feedback loop, knowing where to build new aspects of the software will be clearer than before.
  5. Automated Deployments. Once the application has been built (or updated) and tested, then it’s critical to be able to get it to the customer quickly and in a repeatable manner. Automation not only make that process repeatable (and more secure), but it helps with the goal of reducing the Ops COGS.

The Developer’s Perspective (starting at 50m 0s)

Screen Shot 2016-08-31 at 2.34.59 PM

The demonstration starts by looking at this application from the perspective of the application developer. In this case, the developer will be building a Java application on their laptop. In order to make this simpler for them, they use a few tools. Some of the tools are directly on their laptop and some of them are running as a cloud service (could be private cloud or public cloud):

  • “Project” – The local representation of the application on the developer tools.
  • “IDE” (Integrated Development Environment”) – The local tools on the developers laptop + tools running on a server to help them build the application
  • “Stacks” – The groups of software/languages/framework that the developer will use to build the application.

The tools provided to the developer are there to make sure that they have all the things needed to build the application, as well as making sure that their software stack aligns to what is expected by operations once the application eventually gets to production.

Once that is in place, the developer can then begin writing (or updating) the application. When they have completed a portion of the application, then can move it to the system that will help integrate it with the other pieces of the application:

  • “Microservices” – The smaller elements of an application that perform specific tasks within a broad application experience.
  • “Pushing to Git” – Updating the application into a Git or GitHub repository, so that it can then be stored, tested and eventually integrated with other pieces of the application.
  • “Continuous Integration” (CI) – A set of automated tests that look at the updated application and make sure that it will run as expected.

NOTE: There was a small section in the demo where the developer made a small change/patch to the application. The small change then went through the “pipeline” and eventually got integrated and moved to production. This was done to show that updates to applications don’t have to be large (or any specific size) and then can now safely be done at any time of the day – no longer need outage windows.

The “Pipeline” (starting at 56m 0s)

Screen Shot 2016-08-31 at 2.35.52 PM

This part of the demonstration is focused on the guts of the “bits factory”, the place where the software gets tested and reassembled before it’s ready for production use.

  • “Continuous Integration / Continuous Deployment” (CI/CD) – A set of tools that take application updates from developers, automate the testing of that software with other pieces of the broad application, and package the validated software in a way that can be run in production.
  • “Pipelines” – The on-going flow of application updates from developers. In an agile development model, these updates could be occurring many times per day.
  • “QA” – Quality Assurance – The part of a pipeline responsible for quality testing. Hopefully this is where software bugs are found, before going into production.
  • “Staging” – An intermediate step in a pipeline between QA and Production, where a company will try and emulate the stress of production. Sort of like a dress-rehearsal for a theater play.
  • “Blue / Green Deployment” – Even after being QA tested, when application updates are available, there needs to be a way to deploy them and make sure they work properly before completely removing the old versions. Blue/Green is a way to validate that the application update works before eliminating the old version. It also allows for “roll backs” if some chaos occurs.

The Application and User-Experience (at 1hr 0min)

Screen Shot 2016-08-31 at 4.45.34 PM

Now that the application has been written and moved from being tested to being deployed into production, on a container application platform, the actual interaction with customers can begin. In this demo, we can see the real-time user interactions and how the interactions are tracked by the backend databases (and business logic). While the demo only showed the basic user interaction, the overall experience was made up of a number of microservices (login/user-authentication; user profile; game interactions; scoring dashboards,  user status levels, etc.). Each of those microservices could be independently updated without breaking the overall application experience.

The Business Analyst (at 1hr 3min)

Screen Shot 2016-08-31 at 5.26.53 PM

Previously, I talked about how it’s important for both the technical and business teams to have visibility to customer/market interactions with these new digital products/applications. In this part of the demo, we see how a “business analyst” (or some might call it a “data scientist”, depending on the scope of the work) would interact with the data model of the application. They are able to see the interaction data from the application, as well as make changes to how data relationships can be modeled going forward. They could also make adjustments to business logic (e.g. marketing incentives, customer loyalty programs, etc.). As they make changes to the business rules, those changes would be validated, tested and pushed back into the application, just like a developer that had made changes to the core application.

Platform Operations (at 1hr 6min)

Screen Shot 2016-08-31 at 5.47.32 PM

This part of the demonstration is somewhat out of order, because the platform operations team (a.k.a. sysadmin team, network/storage/server team, infrastructure team) would have setup all of the platform components prior to any of the application work happening. But in this part of the demonstration, they showcase several critical operations elements:

  • How to use automation to quickly, consistently and securely deploy the platform infrastructure that all of the applications will run on.
  • How to easily scale the platform up (or down) based on the needs of the application and the business. “Scale” meaning, how does the system add (or remove) resources without causes outages and without the end-user customers knowing that it’s happening. In essence, ensuring that user-experience will be great, and costs will be optimized to support the right level of experience.
  • How the operations teams can work more closely together with the applications teams to deliver a better overall experience to the end-user customer.
  • How to manage and monitor the system, in real-time, to correct problems and failures.

A/B Testing the Market (at 1hr 12min 20sec)

Screen Shot 2016-08-31 at 5.57.34 PM

In an early segment of the demonstration, they showed how application updates can go through the “pipeline” and be deployed without causing any disruption to the user-experience. But sometimes the business isn’t sure that they want the entire market to see any update, so they’d like to do some market experimentation – or A/B testing. In this case, they are able to test a specific experiment with a subset of the users in order to collect specific digital feedback about a change/new-feature/new-service. The application platform is able to provide that level of granularity about which users to test and how to collect that data feedback for the business analyst teams (or marketing teams, or supply chain teams, etc.). These experiments are treated just like any other change to the application, in that they go through the pre-deployment QA testing and integration, as any other update to the microservices of the application.

Agile for Developers AND Operators (at 1hr 14min)

Screen Shot 2016-08-31 at 6.05.06 PM

Just as application developers are trying to go faster to keep up with business demand, so too must the operations teams be able to move faster to keep up with the developers. In this part of the demo, we see them using similar technology and process to update the platform infrastructure when a security threat or software bug happens. It is important for them to be able to test new software before deploying it live into production, as well as experiment and make sure that something new does not create unexpected problems in the overall environment.

In Summary

There were a lot of moving piece to this demonstration. From a technology perspective, it included:

  • Containers (Docker)
  • Container Application Platform (Openshift/Kubernetes)
  • Middleware (JBoss)
  • Many development languages (Java, nodeJS, .NET)
  • Microservices / Cloud-native applications
  • “Legacy” applications (SQL databases)
  • Continuous Integration (Jenkins)
  • Automation (Ansible)
  • and lots of other stuff…

But what I hope you were able to see was that these new environments are much more agile, much more flexible (for both developers and operators), and require closer collaboration between the business and technology teams to deliver a great end-user experience.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: