Photo by Guillaume Bolduc on Unsplash

Because Cloud is not only a technology leap.

The journey to cloud requires not only to master the technology but in order to scale at enterprise grade, other challenges will have to be addressed.

My job consists in designing business ecosystems and for 5 years they all have in common to be hosted in “the Cloud” or more accurately on the platforms of the different Cloud Service Providers (a.k.a CSP) . This led me to implement apps under different ‘cloud’ flavors: CaaS, PaaS, FaaS, as a container, a platform, or a function.

Being able to consume instantly technology either for building a new app, or to try some new cool features (such as a cognitive augmentation) definitely changed how we will bring IT to an enterprise.

As a developer, you get the immediate rewards:

• Instant self-provisioning: Click, click, click and my environments are available, giving access to a vast portfolio of technology.
• Focus on code: No server to set up, no installation, no patching, fixing. Nothing. Developers are here to develop, not install painful fixes on operating systems
• Elasticity: Among the patterns that are considerably taking importance, the elasticity of the platform, based on autoscaling rules is facilitating the conception of resilient platform.

As such, building a new app is considerably simplified. But when scaling it at an enterprise level , to adopt the cloud journey, this simplicity will be the tree that hides the forest.

A journey into the cloud(s)

Transition to cloud is a journey that encompasses at least 4 different phases

• Phase 1: Formalizing the vision of the transition to the cloud, addressing all the different aspects of this journey. What is (are) my technology target(s)? How do I reach it (them)? Is my enterprise ready and mature to make it ? If not, how do we remediate this? What are the efforts and is it worth it at the end?
• Phase 2: Transitioning the existing information system either with a low footprint thru a Migration approach or to maximize the benefits from the Cloud transition thru a Modernization approach.
• Phase 3: Building new applications natively taking the benefits from the Cloud
• Phase 4: Last but not the least, managing your applications especially while running it.

KISS. Yes, of course, but…

At first sight, you would rather want to “Keep It Simple S…” (… standing for “s’il vous plait” as we say in French, of course.).

Low hanging fruits exist and catching them is usually a common and simple way to initiate the journey

1. Assessing rapidly technology: NodeJS, Python, Java, PostgreSQL, CICD… so many capabilities, actionable at a click. Consuming IT without the complexity of painful installation processes.
2. Incubating ideas on a fresh platform to test trendy capabilities such as a cognitive assistant, image recognition...
3. building a brand-new application taking advantages of Microservices or cloud patterns such as service meshing, SSO integration, CICD enabled...
4. even migrating existing applications under a “lift and shift” flavor (meaning taking the application and moving it with the minimal (if none at all) modifications)

This is definitely doable in days. But…

For companies with the ambition to embrace a global strategy, making cloud pervasive across the enterprise requires to balance between the constraints of mastering the existing system, in all its facets to leverage the assets generated since years including resolving technical debt, and the disruption enabled by these new approaches, the new opportunities brought on the table by the Cloud.

As such, serenely adopting the cloud requires then to align several planets without dogmatism. The awareness of all the dimensions involved is a must, but the level of implementation depends of course of the starting point and the ambition. It is the objectives of the above Phase 1 — Cloud advisory to assess the current level of maturity, the target to reach for the different dimensions (technical or not), before defining the timely-manner transition paths.

Technology

In fact, the journey to cloud is also a technology leap. This dimension is a mandatory exercise as it establishes the cornerstone of a Cloud transition: The platform.

Several aspects require to be mastered to build a strong ecosystem. If several technology patterns coexist in the different CSP to embrace a broad variety of situations, my experience on the field tends to raise the container approach as the best trade-off currently available in early 2020. Said like this, it may be seen as an incantation, but:

• As software units, packaging the code along with its dependencies (code, runtime, system tools, system libraries and settings), containers can natively be run on several computing environments, making abstraction of the underlying infrastructure.
• Containers are placed in a technology ecosystems that augment them: Orchestration (With Kubernetes that is a standard) , Service Meshing (such as Istio)… These augmentations allow advanced manipulations of the containers increasing drastically the global resilience of the system, while reducing the risk of deployment (with concepts such as Immutability, and progressive deployment patterns- Blue Green, Canary).
• Containers are versatile: They can host a whole application (fairly useful as a first step while migrating existing application) or be dedicated to an atomic microservice

The architecture and technology vision will be split in

• Cloud platform architecture to master the low-level conception of the platform (Containers clusters, tripod resiliency enablement)
• Application architecture to formalize the conception of the containerized applications. Several architectural references may coexist for example, one for the migrated applications, one for the microservices architecture.

Remark: Reality is always more complex that you may wish. If containers are really a strong backbone to build robust information system, PaaS (Platform as a Service) can have strong advantages: Being able to deploy in seconds a robust, reliable, secured database or an IAM solution, is really astonishing. It also meets some promises supported by the cloud such as Instant provisioning, Focus on code… I have seen teams, starting to code on the project kick-off day without caring to all the underlying plumbing (Installation, Configuration, Back-up, run). If very seducing, enterprises willing to master the entire ecosystem might want to propose this ready-to-use service based on containers, but they will have to cope with the complexity of implementing, deploying and then managing these services (Data storage, Performance, Elasticity, Run…)

Methods and Tools

Here, methods are all the processes and best practices used to build and manage applications in the Cloud, while tools are artifacts enabled to support the methods. The list of each of them is infinite but some major areas arise.

Adopting an Architectural Model such as C4

The C4 model is a method for visualising software architecture thru 4 dimensions : Context, Containers, Components and Code. It is a fairly simple approach to depicts an architecture on its core elements. On one side , I really love the pragmatism of this approach especially for non-UML aware teams, on the other side, I am really missing some artifacts that I find critical such as the non-functional requirements, or even more important the architecture decisions so I tend to prefer a traditional architecture dossier. I have formalized a template covering the major elements of conception of an architecture dossier directly in a github repo : Access to the Architecture template on GitHub.

DDD (Domain Driven Design)

DDD (Domain Driven Design) is a design approach aligning the software conception with the business’s domains, needs, and strategy. DDD proposes to model the problem in a domain (relying on a common “ubiquitous” language in a bounded context) that should be solved by the software, on two levels: strategic and tactical.

Documentation as Code

You may want to have a look at my story here

CI/CD (Continuous integration Continuous Deployment) :

One benefit expected from the cloud that is usually emphasized is the “TTM* reduction”, as for being able to shorten the delay for an idea to become a sound reality in the hands of the end-users. Almost a buzz-word. But what can be understand behind it, is a strong industrialization of the development process (where a “culture” of test is reinforced, shifting this concern on the ‘left’ of a Dev(left)-Sec-Ops(right) approach), along with a risk-mastered deployment (enabling a progressive deployment of the code thru quality gates) process, built on an atomic (such as micro-services to contain the impact of an evolution of a piece of code) architecture

*TTM: Time To Market

Governance

Mastering the transition to cloud requires the settlement of a governance within a Cloud Competency Center with the ambition to provide a structure of processes and organization.

At a coarse grain level, several governance bodies need to be setup, each of them responsible of a specific Cloud stake. Among them (others can be defined for sure) can be emphasized:

• The Board of Direction: This board is responsible for the definition of the overall Cloud transformation strategy and in charge of all the arbitrations raised by the other bodies.
• The Cloud Transformation Board: This governance body is responsible for controlling, forecasting the cost induced by the transformation of the portfolio. As such, it is responsible for evaluating and monitoring the KPI of the transformation process.
• The Architecture Board: This governance body is in charge of defining the technology vision to support the business strategy. As such, they have to define the reference architecture (being at infra or application level). An extra challenge will to ensure a tight integration with the existing information, especially when will come the conception of the resiliency patterns of the end to end information system (avoiding ‘single point of failure’ exposed in legacy system where resiliency was not managed in the same way).
• The Risk, Security & Compliance Board: This governance body is responsible of the alignment and conformance of the cloud processes with the business domain
• The Innovation Board: This governance body is responsible of the (emerging or accelerating) innovation enabled by a cloud platform. Rapid provisioning, vast technology capabilities, openness to external tiers are the dimensions to master.
• The Service Management Board: This governance body is responsible for the execution of the proposed service (24x7 SLA, mastered progressive deployment, Incident management, Run, Support to end user (among them the development team))

Culture and Organisation

Of course, cloud can be adopted without changing anything in the current organisation. Applications will be delivered and run. But….

...But, by adopting some new perspectives, new cultural traits, the benefits generated by the cloud could be largely amplified.

Valorising the usage of the platform

Valorising (if not monetizing) the usage of the exposed services (especially APIs) and the data is a game changer. It will emphasize the criticality, the importance of the APIs (seen as a product rather than the extension of an existing app) and more largely of the urbanisation of the Information System over the construction of GUIs (applications). Audiences of a correctly urbanized APIs is infinite. Not only benefiting from a rationalised IS, it will multiply the consumers (internal and external apps), and once adopted will provide KPI to decommission less used services and invest the ones largely used.

Incubation and innovation

Hopefully, mankind did not wait for the Cloud, to innovate and incubate ideas. But Cloud is generating lots of accelerators.

• Being able to consume service ‘on the shelf’ at a click of the mouse from a vast Service Catalogue is real vector of innovation. I have numerous examples of applications that have tested a chatbot as a first flavour of IA before scaling to more business-oriented use cases.
• Exposing a Developer Portal , where technical communities of the enterprise can contribute to the elaboration of a software is a strong enabler in term of team synergy while augmenting the resulting quality of the implementation (bugs are widely chased) and its adoption (“Eat your own food”) within the entreprise.
• Hackathons are so easy to setup, when it takes seconds to provision environments ready to code to users. I am amazed how, with few directions, non-technical participants of these hackathons are able to assemble ideas into an actionable app.
• Openness: Large organisations can be tempted to perform their innovation activities internally within the boundaries of the enterprise. By exposing and/or consuming services internally and externally, a company can expand the breadth of the innovation, freshen its vision and reduce the ‘We have always done it like that, and pardon me, it worked for XX years’ pattern.
• As a strategy, innovation process and organisations can be adapted to enable a “funnel” approach where unlimited ideas are tested in an incubators and/or within a project (thru a dedicated innovation sprint, for example) and only the ones that are able to expand, drive a technical community around them, to scale into sound applications, remain.

Agile (at Scale) in a cloud factory

Application delivery models need to evolve in order to gain in flexibility, because promises such as the TTM reduction can’t be fulfilled only by relying on technology. Embracing agility as a delivery model is strong enabler, as it will allow a dynamic adaptation of the solution to the richess of the business situation and adjust the decisions constantly. Moreover, it will be a vector for innovation for new products and services.Several models and frameworks exist to support this challenge, such as SAFe or the Spotify model

Cloud Service Management and Operations

This one rocked my world. Since 20+ years, my teams are developing software that we transfer to operation teams to run it. Then , after deploying it on a Sunday to limit the service disruption to end users, they were, from time to time, forced to solved deployment problems during sleepless nights so that end users are not affected (though less true in a worldwide context). With Cloud, I have seen new roles emerging, such as Site Reliability Enginneer to automate, industrialise, impact the features of an app to have an evermore manageable applications. In the same time, new patterns such as progressive deployment allowed to limit the impact of a failure to an early-adopters community, accepting that “Failure as normal in a system”.

On top of this, CSMO is supported by a new generation of tools able to correlate, anticipate, avoid failures and share the findings vastly not only to operations teams but up to the developers in order fix issues with a maximal velocity.

Cloud or not Cloud, that is the question… really?

One could, with reason, argue that most of the above elements are not specific or limited to “Cloud”.

It has been years that we have in our enterprises

• Design Authority committees, tending to urbanize information systems as isolated and independent (web and then micro) services,
• Architects designing secured platforms resilient to workloads
• Developers implementing loose coupling patterns relying on efficient Integrated Development environments
• Consultants inventing features relying on Design thinking as a cocreation with end-users
• Agile experts delivering the solution in a timely manner strategy, focusing on the value generated

What Cloud brings on the table is that enabling accordingly ALL of these disciplines, generates an amplification of the resulting benefits.

The list could be very long but, as a first intention:

1 — The resulting software, focused on the value it brings to it end-users, is delivered with a high velocity (as all atomic part can be delivered in parallel with a low regression footprint) thru an industrialized CI/CD. Technology can be consumed rapidly to enrich an app with features (A simple example is the addition of virtual assistants to support an application deployment. Though peripheric, it brings lots of value to a deployment with a low entry-level effort.

2 — The deployment risk will be reduced as

• The impact is limited by design to the microservices. External tiers, as long as they cope with the interface contract are not affected
• Deployment is not a vertigo depending on the number of end user impacted. Mastered progressive deployment allow to serenely bring a feature to its end-users mastering the targeted population.
• Natively, the immutability of a container allows to quickly rollback to a previous stable situation in case of trouble (No painful iterative, installation/deinstallation that you do in the stress of the service rupture)

3 — The platform itself! Robust, resilient, elastic, easy provisioning, low footprint in term of CSP… Cloud platforms clearly generate an agile and flexible information system.

The Cloud destination counts, but as well as the journey that takes us so far.