The CIO dilemma. Should you adopt a Cloud Native strategy?

We live in a world where change is constant. As this is written we are living through the COVID pandemic, and, although the vaccines are starting to emerge and roll out, it is an absolute certainty that the way businesses operate will have to, at some level change and adapt to the new consumer and enterprise buying behaviours.

To help with the thought process of how IT can support and be the enabler for re-pivoting, I’ll endeavour to cover the areas one ought to reflect on if streamlining IT costs of operation is on the agenda. To this there are many options and approaches; I’ll start small, covering what you need to review if you have not embraced Cloud as part of your strategy, then move through to the more advanced thinking of those that have made the leap and are embracing what is universally known as a Cloud-Native strategy. I will endeavour to provide some practical suggestions on what to review and some principles/characteristics around the various options.

The role of the CIO is changing; initially, the function was to deliver IT to support a Business; the CIO role is now an important one that is an equal stakeholder in the board room.

Let’s level set. Technology enables businesses to react and respond. Before I get into Cloud and Cloud Native, first let’s anchor on some fundamentals which are pertinent to this blog. There are three drivers for adopting Cloud:

• Lower Capital and Operational Expenditure
• Increase Agility
• Business modernisation through innovation

At Oracle, customers work with us to deliver one if not all three of the aforementioned drivers. Transforming the organisation to be agile and respond to headwinds; these could be market-orientated but are often internal, where the retirement of legacy on-premise applications to drive down re-purchase costs is high on the agenda. If the credit crunch of 2008/9 and the Covid pandemic of 2020 has shown us, having capital reserves is key to survival, paying homage to the age of saying of, “cash is king”.

Cloud enables the continuation of service while removing the 3-year cycle of on-premise server/storage re-purchases that were commonplace. Now, The CIO and CFO functions can leverage working capital management principles, to be more financially agile, which is a pre-curse to business agility.

Heraclitus, the ancient Greek philosopher said, “the only constant in life is change”. This is true in so many contexts. For businesses, “business agility” is a common term and more recently, “IT agility” has equally found its place in the board room.

The Business tells IT what to do; not anymore, they don’t.

The business should always lead IT, but IT has a say when it comes pivoting a business. I am sure it is a universal agreement, though organisations will be at different stages in this approach, the CIO is more than just an enabling function. With the variance of global trade and the accessibilities to new and emerging markets; managing customer interactions, their data and dealing with compliance and regulatory authorities in the markets in which they operate in, is a complex and challenging ongoing operational set of tasks. These new outbound focusses, compound and even conflict with the traditional focus of the CIO; the management of the inbound, or in-house/traditional on-premise activities, such as system uptime & upgrades, infrastructure modernisation; leveraging the advances in networking and security. These critical areas will remain a core focus, but as the world of commerce accelerates at speed, unfortunately, the same cannot be said for the traditional organisation-owned datacentres and its corresponding ageing- server/storage architecture.

Coupled with the persistent pressure to reduce CAPEX and minimise OPEX and, in parallel, deliver new services that support business agility through innovation, the CIO role is hard, very hard. Cost efficiency is an area that has not diminished over the years and those IT services that have assumed commodity status is seen as a principally ripe for modernisation.

So how can this be done, effectively in an ever-changing world?  Adopting an agile mindset and delivering innovation will be very dependent on the organisational culture. This will play a large role and, their ability to handle risk will be key in adopting a new way of running the business.  The CIO function is no longer just a cost centre, it is a pivotal strategic function that can help navigate an organisation towards its objectives.

Cloud adoption has its path mapped out by the macroeconomic indicators of geographical regions, and the operating markets of those organisations that trade and operate within. To see the projection, a CIO must better understand these leading and lagging indicators to better predict the responses needed to deal with these head and/or tailwinds.

For IT today, there are specific macroeconomic indicators surrounding the adoption of Cloud. The most common one at the time of writing this blog is Covid-19. Throughout 2020, we saw a seismic shift of organisations and governments moving their workforce to remote working and relying on technology to underpin their operations. The phrase “shall we Zoom” had little meaning to everyone a year ago, but now it is commonplace in society. The reliance on technology; Cloud especially, has enabled the world to respond, adapt and overcome the challenges it has faced.

As much as a government department or an organisation needs to adapt, so do customers. Businesses are driven by the markets they operate in; the customer being at the heart of all they do, therefore keeping their customers loyal and happy is a frequently used key performance indicator. I am not going to cover macro and micro-economic indicators and the analysis of thereof in detail, though I wanted to introduce the principle as a discussion point to underpin why Cloud is gaining prominence.

If you are interested in what these leading and lagging indicators, some of the notable ones are listed here:

Leading: Stock market. House Prices. Bond Yield, Production and Manufacturing, Retail Sales, interest rates.

Lagging: GDP, CPI, Currency strength and stability, employment statistics, Commodity markets.

Before you move, know what you need to pack and do your homework.

Not all clouds are the same. Just we have in the meteorological sphere, the Cirrocumulus and Cirrostratus, known as high-clouds and the stratocumulus and stratus for the low-lying clouds, each technology Cloud vendor equally has its set of offerings and place in the Cloud Market.

There are three accepted areas:

SaaS, Applications centric, known as Software as a Service, where a third-party host a Software distribution model, that hosts applications, accessed over the internet.

PaaS is where a third-party host a Platform as a Service model, for application development, providing the platform and the tooling on its own infrastructure accessed over the internet.

IaaS, compute and network, known as Infrastructure as a Service, where a third-party hosts server, storage and other virtualised resources, providing the compute instances, accessed over the internet.

So, knowing what area to invest in for your needs is quite important when making a decision to adopt Cloud. Each Cloud provider will offer some or all of these areas; at Oracle, we provide a cohesive set of offerings that span all three areas and are designed from the ground up to work together.

Most organisations start small, trial Cloud services and expand as confidence grows. Confidence in shifting workloads should never be understated. As to my previous remarks towards the customer being centric to business strategies, having that confidence in your Cloud vendor’s ability to deliver exceptional service needs to be fulfilled before one will bet big.

In the early days, we saw a lot of infrastructure workloads moving into the Cloud (IaaS). This freed up datacenter compute to that was needed to focus on other areas. As global trade (another indicator) accelerated; opening/up new markets this created opportunity, but equally competition at the same time.

Businesses needed to respond; cost is always a focus especially when one needs to pivot to counteract any contingency facing the organisation (see The Contingency Theory of Organisations, by Lex Donaldson for context). As we are in the heart of the digital age, technology is shifting its prominence from a support role to a leading one, showcasing how agile an organisation is.

Governance, Risk and Compliance is common-place and an integral element of any corporate operating procedure. Organisations have a higher standard for applying governance today than ever before. It is necessary to prevent and as well as prove that any potential threat or compliance breach is thwarted.

As cloud usage expands, configurations in both production and development potential can drift from standards and vulnerabilities will then emerge. We have seen this many times where organisations have a robust set of criteria for moving to the cloud, then just don’t implement the right approach to deal with the operational aspect. PaaS provides a comprehensive set of logging and audit tools to help manage operations.

Another challenge that PaaS solves is that developers are being challenged to increase productivity and quality. Yet, as organisations scale and innovate, development processes could and often falter due to assemble-it-yourself continuous integration/continuous delivery (CI/CD) environments. PaaS development needs to rely on prebuilt yet open integrated development environments and this is where Oracle adds value to organisations.

Another gotcha that often experienced when adopting a cloud strategy, is integration. The servers, platforms and applications will need to connect with and communicate to/through the different Cloud layers, just as they were on-premise.

I worked with a customer that was defining a core set of critical cloud-based management capabilities, for their B2B operations. They knew the architecture and the applications, that they wanted to leverage; this included moving their financials into to the cloud and connect with the Commerce and Configure Price and Quote system, using their CRM with adaptive intelligence to manage their business processes. It was a complicated solution, but a proven one that at Oracle we have done before, quite a few actually. For me, the critical components were within the PaaS architecture; getting that right set up the application to map into the customers business processes, set the integration points and build out a personal UI which enabled the business to operate in their way.

You will find many Cloud vendors offering services, but when you are looking to invest, it is not just the application you need to be thinking about, it is underpinning platform services that will give you that integrated and future proof approach.

Furthermore, as more and more customer adopt and standardise on Cloud, the tools used to create, deploy and manage applications are shifting too. The traditional on-premise approach: processes, tooling and even mindsets are shifting in parallel. These shifts are needed to enable IT to be agile and support the business adjustments that organisations are dealing with. This shift is in the form of Cloud Native. And it is this topic I cover next.

Taking the next step into Cloud Native.

Container-based.

The premise of containers is to create and deploy an application and the associated dependencies together, that can be version controlled and accesses and distributed between developers. Just as the VM movement allowed a guest OS to be virtualised, containers take this to the next level, by using the host OS and encapsulate the application logic, the necessary binaries and configurations needed for the application to run, making it incredibly lightweight and portable. So portable the code can be run anywhere, even a desktop, which makes it ideal for development teams operating in a CI/CD model.

The key difference between virtual machines and containers is that containers offer a way to virtualise an operating system, whereas virtual machines, it is the hardware that is being virtualised, to allow a multitude of operating systems to be run.

At Oracle, we have the Oracle Container Engine for Kubernetes. This is an Oracle managed container orchestration service, which is certified by the Cloud-Native Computing Foundation (CNCF) https://www.cncf.io/

It is simple to use and has full support for REST APIs and has a robust CLI.

HIPAA, PCI and SOC 2 compliant and uses native Identity and Access management, for governance and control, plus the Oracle Identity Cloud service, allowing for a zero-trust strategy, which is a common approach for Cloud Native applications. Because, after all, just because an application sits behind a firewall, doesn’t mean you can reduce your security.

Services based.

A core reason for the organisations to leverage a Cloud Native strategy is that the services enable organisations to adopt a modern application development approach, using technologies such as Serverless functions, API’s, Docker and Kubernetes.

It is with these technologies and their open-standards approach, that organisations are looking to adopt Cloud Native, as it helps avoid proprietary vendor lock-ins.

Further benefits include developing and deploying applications at scale and speed; reducing the operational tasks involved. This allows developers to focus on developing applications by using open standards and open source allows the deployment of those applications to any environment without refactoring any code.

A point to note is that not all applications will, or even should be refactored for a cloud-native deployment; in these instances, the applications will serve out their purpose in a non-cloud native state.

Applications are built with services wrapped up in containers, deployed as ‘microservices’ and managed on elastic infrastructure through DevOps processes.

As Cloud Native applications are services-based, the Microservices architecture will allow for the creation of these applications that are designed to be decoupled from the traditional monolithic deployments found within datacentres.

Although the term microservices conjures up the image of services that a ‘micro’ in nature, they don’t have to be small. There is no defined size structure for microservices. It is more of a term than fact.

This serverless approach creates the agility and flexibility needed for application deployment because they are decoupled from the physical infrastructure, they are highly portable. This portability stems from the application being built with a small number of services, each running its own processes, communicating via APIs over HTTP.

At Oracle, we have our Functions as a Service. Functions is a serverless platform that lets your developers create, run, and scale applications without managing any infrastructure.

We also believe that what we provide needs to be simple and Functions is no exception. Your developers just write and deploy their code. We will take care of automatically provisioning and scaling resources needed to support your projects.

Security is a common theme throughout Cloud Native and using the Oracle Functions your teams can build and run code in isolation; access management is built-in with key stores, and authentication is delivered through Oracle Identity Management services.

https://docs.cloud.oracle.com/en-us/iaas/Content/Functions/Concepts/functionsoverview.htm

Leading with APIs.

API’s, Application Programming Interfaces is a computing capability, that expresses how the interaction between multiple software programmes will communicate. It defines the call requests; the when and how, what format they will be made in and what type of response is returned.

APIs are not native, pardon the pun, to Cloud Native, as you will be aware they have been around for some time and is an excellent way of providing an application to application interactions. When thinking of cloud-native, leading with an API strategy is a good approach as the way that your services interaction will be via APIs, normally the REST API over HTTP. Before you design the service architecture, define how these services will interact and communicate to and through.

Build automation.

Automation from the building to deploying is a key area for Cloud Native application management and is completely aligned to the principles of DevOps.

It is important to note that this automation extends beyond the deployment of applications to include, operational tasks around the infrastructure. Terraform is an open standard infrastructure as code tool for building, changing and versioning infrastructure efficiently. It does this by codifying what needs to happen from a single application to the whole environment, by creating declarative configuration files that can be run and shared.

I have mentioned CI/CD and DevOps previously. This helps with the automation of the infrastructure and services associated with cloud-native. Look to automate as much as possible from the build, through testing, deploying and updating of the application.

The OKE offering we have at Oracle has DevOps automation built-in and this enables the streamlining of development and operations of Kubernetes clusters. Using our Visual Studio, you will be able to automate the build of your cloud-native applications and monitor and secure these through the tools we provide.

Self-healing is another strategy of ours when OKE detects a fault, it auto provisions new worker nodes to maintain cluster availability.

Security and Governance.

One of the many things I learnt during my 10-year tenure at Symantec, was that anything that is accessible by connection is a potential security vulnerability.  Traditionally, IT administrators of applications that reside within the datacentre only needed to think about perimeter security and authentication, but as the world has evolved and the use of technology has proliferated so has the need for a modern workforce that utilises a remote and mobile working as a core operational strategy. With this and with the evolution of Global e-commerce more systems are interconnected both internally and externally, therefore increasing the security risk posture of those services, applications and the organisations.

Cloud Native at its heart is exposing endpoints that will allow connections and interactions for communication, therefore security needs to be thought right at the very beginning.

On top of a layered security approach, business agility, through IT agility, is managed and maintained through robust governance and compliance process, especially when running and controlling the rate of change through the DevOps process.

Extending SaaS.

If you would like to see how the application can be extended using Cloud Native technology, please see these links for more information.

• https://www.ateam-oracle.com/the-cloud-native-approach-to-extending-your-saas-applications
• https://docs.oracle.com/en/solutions/extend-saas-cloud-native/index.html#GUID-AD545A4D-F22D-469E-AE2B-DF73B6E51312
• https://www.youtube.com/watch?v=f2sLHsphR3I

Conclusion.

A Cloud Native strategy and shifting your application deployment approach is based upon a number of areas, notably; your appetite for risk, your need to be agile in the markets in which you operate and your organisational culture. Cloud Native is a way of life for IT and to embark on this journey will take planning and commitment. The benefits are there; you will be incredibly agile and deploy/upgrade applications faster, but there will be overhead in operation process design that will need to be worked through to support the change on the direction. These benefits can be realised by driving cost efficiency throughout your IT operations. Architecting and re-engineering applications and infrastructure can be costly. Especially in global markets where competition is fierce; even in Oligopolistic and Monopolistic competitive markets, product differentiation is so critical, margins can and will be tighter, therefore the cost of operation needs to be carefully considered. Cloud Native can support the cost-conscious business, as there will be times when the re-architecting and spinning the application in new directions are needed to address external contingencies. Further efficiency gains can be seen through the micro-adjustments to parts of the applications, through the modification of specific services, rather than modifying the whole application configuration.