With Cloud computing, and inside VLEs and the IT media industry, there is a groupthink that all technological innovation is now ‘Digital Transformation’. This is of course a lot of nonsense. Cloud computing covers Infrastructure, Platforms, Software as a Service, Security, Application re-platforming, Data Layer improvements, Single-Sign-On and an almost unlimited level of technical opportunities which may, or may not be, related to Digital Transformation. Putting technology under one rubric is pointless. Digital Transformation used to mean, and it still should mean, the following:
DT is the application of digital capabilities to processes, products, and assets to improve efficiency, enhance customer value, manage risk, and uncover new monetization opportunities.
Some applications and systems are indeed Digitally relevant. Many are not. Most workloads in most VLEs are not customer facing revenue engines, but work-flow systems, managing processes, data and functional requirements. They may, or may not, feed into a Digital system. Not every company is a software company and most firms are not Netflix.
Given the reality that not everything is ‘Digital’ needing ‘DevSecOps’, or ‘AI Automation’ or other buzzwords, there is however, a market opportunity to help firms move from Legacy Applications to Public Cloud platforms which can be troublesome and cumbersome. An approach would be to use automation in the use of Containers (or VMs) and apply a ‘factory’ approach to migrating (not necessarily transforming), applications to the Cloud. Public Clouds do have tools in place to aid with this, but often they are not built-to-scale, when many applications or ‘heavier’ systems are in play.
The IT media chatters that most companies have adopted a bimodal IT approach. In this approach, the traditional (“mode 1”) waterfall / legacy approach to IT remains unchanged, while the adoption of emerging digital technology is pursued following new exploratory / agile approaches. The assumption – which is wrong – is that every firm is a software company.
Agile is a process of IT delivery in which the business is integrated with IT subject matter experts (SMEs) on a product development or a project (both are valid). Agile can be used in development, migrations, refactoring, or even in planning new marketing products (IT SMEs would obviously not be involved with this). There exists a legion of challenges with Agile (cultural, organisational, budgeting, skills, HR, change management, offshore delivery, etc). Within IT projects if we accept the ‘bi modal’ view of technology, there are some very sharp challenges in integrating ‘modes’ 1 and 2:
Maybe by using cloud and devops technology, some firms with highly skilled experts can overcome these issues and begin to engage in ‘digital transformations’ while at the same time increasing the productivity of the IT organisation as a whole.
Gradual deployment into the Cloud(s)
There is some veracity in the complaint that while “lift and re-platform” approaches from in-house data centres to Public Clouds will succeed, the benefits in terms of scalability, flexibility and time-to-market were way below “native” cloud applications. Keep in mind that ‘native cloud’ entails a re-architecting, re-build, the use (most likely) of micro-services and Containers and is complex and budget-time consuming. Not every application must be Cloud-Native (another ridiculous myth). But for those applications which do face an end consumer, in a competitive market, where application intelligence can be used (eg. Automated loan approvals), then Cloud-Native is probably the only real option.
To enable targeted legacy applications to take advantage of Cloud-Digital technology, there is an approach firms can follow and use existing platforms. This entails the use of an Openshift (recommended), or OpenStack (not recommended), Private Cloud infrastructure, and automating the deployment into the targeted Public Cloud.
Example: On Premise, Openshift to AWS
(source:access.redhat.com/articles/2386731 Redhat, 2016)
Summary of components of using a Cloud ‘Factory’ process:
| Open Stack Infrastructure | A ‘Factory’ can be automatically set-up by Ansible scripts on any kind of Open Stack infrastructure. Regardless whether using a public, enterprise, or private cloud.
Manual configuration is limited to very basic tasks like for example establishing network connectivity and provisioning of certificates. Key Technology: Open Stack, Ansible |
|
| Open Shift / Kubernetes | The management of both core and domain specific components is handled by RedHat OpenShift. This component is based on Google’s Kubernetes and Docker which reduces vendor lock-in to RedHat while at the same time gaps in the “enterprise-readiness” of Kubernetes (e.g. high-availability proxies etc.) have been filled.
Key Technology: RedHat OpenShift, Google Kubernetes, Docker |
|
| Registry Core Services | The core services are the basic building blocks of the Cloud Factory. Core services are used to not only manage the Cloud Factory itself but also to provide reusable services (e.g. GitLab, Jenkins, etc.) across domains. The services are provided as standard Docker containers in a Docker registry with additional metadata which allows an automated provisioning in OpenShift.
Key Technology: Docker Registry |
|
| Runtime Core Services | The core services which ship with the Cloud Factory are:
Key technology: Atlassian Jira, Atlassian Confluence, Mattermost, OpenLDAP |
|
| Registry Domain Services | Additional services which are specific to a domain are provided in ether GitLab (Source Code) and / or Artifactory (Deployment Units).
Key technology: JFrog Artifactory, GitLab |
|
| Assembly Lines | The assembly lines are based on standard CI/CD components:
It is however important to note that Cloud Factory Lines go beyond the provisioning of best-in-class CI/CD components. The assembly lines could be built with fully automated “commit-to-deploy” templates in JobDSL so that manual configuration is reduced to a minimum and the configuration itself can be version controlled. Key technology: Jenkins, SonarQube, Selenium |
|
| Monitoring | The monitoring is divided in two areas: the cluster monitoring of the Cloud itself (using Heapster) and the application monitoring (using NewRelic or Nagios).
Key technology: Heapster, NewRelic |
|
| Logging | A Cloud can leverage the widely adopted ELK stack for log aggregation and visualisation. By configuring custom queries and dashboards, the logging can also provide specific KPIs like transactions times of important business functions.
Key Technology: Elastic, Logstash, Kibana |
|
| Transformation Dashboard | Firms will need a cloud migration assessment (part of a Cloud Service Orchestration Platform), which helps identify the applications which are most relevant for the migration and can also track the status of the application migration.
Key Technology: Cloud Migrate templates |
|
| Productivity Dashboard | Productivity is tracked in JIRA, however getting a consolidated overview across all work-streams and comparing planned vs. actual figures requires a lot of custom reporting. With private Cloud Dashboards, this information is available in easy to digest graphical form in real-time. Each item in the dashboard is further supported by a drill down into JIRA.
Key technology: Atlassian JIRA, HTML5 |
|
| Quality Dashboard | The quality dashboard is comprised of two components: SonarQube for measuring the static code quality and a custom dashboard for JIRA to track issues from test and production.
Key technology: SonarQube, Atlassian JIRA, HTML5 |
|
| Speed Dashboard | GitLab Cycle Analytics | |
With automatic provisioning capability, the infrastructure allows firms to set-up additional assembly lines whenever the need arises. There is no further postponing of new feature developments, because of test or release windows. An example using Terraform and OpenShift is here.
There are two different scopes in which assembly lines operate:
The network results in the following release timelines. This flexible approach could allow a gradual enabling of legacy applications within targeted Cloud Platforms.
Maturity levels:
Note: The deployment in production may still require human interaction as per current governance models.
Application Operation
(e.g. for static / singular services)
It is however insufficient to measure the progress in the technical enabling of infrastructure and applications. At the end, it is only the gain in productivity, quality, and speed that matters for businesses. Hence, the hybrid-Cloud provides three specific dashboards for this purpose:
With these dashboards, the improvements can be measured and concrete KPIs can be established for performance-oriented commercial models.
==END
