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 sorts 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. These emerging applications play a role in reshaping how businesses interact with their customers and how they strategically engage with the market. But I also find that 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.
The reference applications come from this video, lead by Red Hatter Burr Sutter (@burrsutter) and a cast of talented engineers. It was highlighted as part of a live demonstration during the keynote at Red Hat Summit 2016 in San Francisco.
It’s important to note that everything shown in this demonstration is built using open source software. Open source has become the de-facto way that companies not only build modern software but also how they engage with communities of developers to create and evolve innovative new technologies. Open source software is and will be a core element of every successful company in the 21st century.
This is a new, customer-facing application. The application includes the characteristics listed below. 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 should be usable in whatever interaction model your customers desire.
- It involves user-interaction which updates the experience in real-time. It should represent an engaging experience for the customer.
- All user interactions are tracked and stored in real time and based on those interactions, the system will apply business logic to personalize the experience. We (the business) want to learn from the customers’ interactions and improve the experience over time. We also want to better learn about how the customer engages with our business.
- Both the technology teams and the business teams have visibility into the data coming from the user-interactions. This is a “digital experience” and one where the business leaders must work closely with the technology leaders to get from “idea” to “execution”.
- The application must have the ability to be frequently updated in order to add new features or be modified to adjust the experience based on interaction data. The business is no longer going to predict the future 12-18 months in advance. Instead, it must be able to quickly adjust to the changing expectations of the customer.
Looking at these 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]:
- The API is the product. An API is a way to represent a business service as a programmable interface. While parts of an 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.
- Ops are the COGS. For a digital product or service, 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. Businesses can differentiate their digital services on user experience, as well as closely controlled the cost to operate those services.
- 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. In the digital world, strategy is a constantly evolving model that requires data-driven insights.
- Rapidly Build and Test. If the digital experience for a customer is now a software service, it is important for the business to be able to build that software (applications) quickly and with high quality. Systems must be in place to enable both speed and the quality. This is called continuous integration (CI) and continuous deployment (CD).
- Automated Deployments. Once the application has been built (or updated) and tested, then it’s critical to be able to deliver it to the customer quickly and in a repeatable manner. Automation not only makes that process repeatable (and more secure), but it helps with the goal of reducing the Ops COGS.
The Developer’s Perspective
The CEO’s Perspective: These are the people that are building the digital “face” of your business. They translate business requirements into technology. They must have the ability to create rapid prototypes and make frequent changes based on market feedback. And they need to understand the business planning to make sure the applications will be able to handle the growth expectations (or surprises) of the business.
The Demo: The demonstration starts by looking at this application from the perspective of the software developer. In this case, the developer will be building a Java application on their laptop. Their laptop has a set of developer tools called an IDE (Integrated Development Environment), which help to simplify the development process. 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 a developer’s laptop plus 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 (languages, frameworks, libraries, dependencies), 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 CI system that will help integrate it with the other pieces of the application:
- “Microservices” – The smaller pieces of a larger application that perform specific tasks within the overall 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. Git keeps track of each new update to the overall project.
- “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 CEO’s Perspective: This is the supply-chain of your digital transformation. Its job is to make sure that quality software can be delivered to the customer experience in the most efficient and cost-effective way possible.
The Demo: 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 “rollbacks” if some chaos occurs.
The Application and User Experience
The CEO Perspective: This is the new storefront of the business; how customers interact with your products and services. It must be able to deliver a great experience, as well as showcase a breadth of services from your business.
The Demo: 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
The CEO Perspective: As W. Edwards Demming famously said, “You can’t manage what you can’t measure.” This system allows a business analyst to have real-time visibility into the business, and ask questions about how to improve it. In this new model, they will work closely with the application developers to implement drive business optimization through the applications.
The Demo: 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.
The CEO’s Perspective: This group manages your “digital factories”, making sure that the assembly lines run at maximum capacity, ensuring that capital assets or operational expenses are highly utilized. Their ultimate job is to make sure that your customers are never without service or have a degraded service. An additional job is to make sure that your valuable data is kept secure from cyber-terrorists (a.k.a. “hackers”).
The Demo: 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 set up 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
The CEO’s Perspective: No matter how good your marketing, product management or business analyst teams are at predicting the market, nothing beats directly engaging with the market. This technology allows your teams the ability to rapidly test new ideas with the market and make adjustments to align your product/service offering with their needs.
The Demo: 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, or 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
The CEO’s Perspective: As much as teams plan for success, occasionally problems arise, and they need the ability to rapid fix those problems and not disrupt business operations. Downtime is costly and unacceptable. These systems ensure that mistakes and problems will not be noticeable to customers.
The Demo: 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.
There were a lot of moving pieces 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.