In the future, a single company will dominate and control the cloud management ecosystem. This company will gain dominance by shifting its focus from feature-packed products so complicated that customers require PSO, and move to understanding the users needs and wants. By changing focus to users' needs this company will be able to reinvent the cloud management ecosystem, effectively commoditizing services, and driving the competition into the position of a silent partner. This system will be successful by overcoming the core challenges impacting the user’s life and build out from there. 
This vision may sound familiar, and there is a reason for that. It is a proven model that has played out time and time again in many different spaces. Replace the words “cloud management” with “search” and you have Google; replace it with retail and you have Amazon; personal communication you have Facebook; transportation and delivery you are beginning to have Uber. The trend is clear; ecosystems are moving toward more consumerized and centralized experiences, with a single company that controls the market.
 
Imagine a Brighter Future
The impact of this vision is best illustrated by taking a look at what a user’s life is like with this system and comparing the user story to the system version of the story. 

Meet Sam
Sam is an application developer starting a new project for her company, World of Widgets. She is developing a new cloud-deployed application to communicate with internet-enabled widgets.
Sam opens an IDE, creates a new project, and edits the project config details adding team information and a link to the project page. Fast forward, Sam has a skeleton of the app that she is ready to push into the company GitHub account. She enters these commands: 
> git commit -m “ /deploy.dev Initial skeleton of widgetcom app”
> git push

A few minutes later, Sam’s watch chimes with an alert that the widgetcom app has been deployed. She opens up her team's Slack channel and finds a message from the system that includes the IP address, log in credentials, and a link to a dashboard for monitoring the application performance and log details. At the same time, the system automatically updated the project page with the deployment details and notified the team.
Sam wants to be sure that the app is running the latest code for the weekly review, so she goes to Outlook and creates a new recurring event for every Monday from 2:30-3:00 AM and invites the widgetcom app. In the subject line, Sam enters “/rev widgetcom app” and saves the invite. On Monday morning, she goes to the event in Outlook and sees that the event has been updated to include the status of the deployment. 
In this story, Sam never goes to a portal or client for the system even though she has a significant amount of interaction with the system. She went about her job interacting with her normal set of tools, and the system brought information and interactions to her. From her perspective, the system is invisible.

The System Story
Let’s look at the story again, but this time from the system perspective.
The system is monitoring the company’s GitHub account. Every time a developer pushes code, the system scans the commit messages for hashtags, issue references, and slash commands. 
In Sam’s case, the system has a rule that when it comes across a "/deploy" command, it must package up the code and follow the default deployment policy to enable the standard set of services and pick the appropriate PaaS. The "/deploy" command was followed by a ".dev", which told the system to look at the dev policy for details around the deployment instead of the default policy. 


The deployment of a new workload in one of the company’s cloud environments triggers two more rules. For both rules, the system looks in the project config file, located in the GitHub Directory.  The system gets the LDAP id for the application owner, the link to the project page, and the LDAP ids for the primary team members. The first rule tells the system to create a notification that contains the connection details and send it through the configured communication channels to the application owner and the project team. The second rule tells the system to update the project page with the connection details for the applications.
The system uses common protocols to enable two-way communication with the user’s existing applications and tools. The story above illustrates how the system integrates with the user’s Outlook through the CalDAV and CardDAV protocols. By inviting the application to the event, the user lets the system know to monitor the event.  The system picks up the "/rev" command from the subject of the event and goes to the continuous integration system, where it updates the widgetcom application with the latest revision at time of the event. Once the event has passed and the system has completed the update the system amends the calendar event with the details of the update.