The Ten Commandments for a smooth coexistence of cloud and on-premise from a governance perspective

Typical issues we deal with when deploying the cloud

• What do I want to use the cloud for?
• What is the right provider for IaaS/PaaS?
• Don't I need more providers?
• How does my internal automation/private cloud fit into this?
• Which applications are suitable for the cloud?
• What do I do with my existing on-premise infrastructure, what do I keep in on-premise?
• Will I only develop apps for the cloud? And for what?
• Which applications (SaaS) will I take from the cloud?
• What do I need to do to allow the cloud to coexist with on-premise IT?
• Which processes do I need to add, which ones do I need to modify and which ones do I need to do differently because of the cloud?

Access to the cloud

The question of access to the cloud is particularly important for organizations that do not start building their IT directly in the cloud, but start from their own datacenter (on-premise). The attitude of the management depends on, how teams and individuals will approach the cloud throughout the organization. A five-level range of approaches can be traced in the market:

1. Without the cloud - cloud is rejected
2. We respect the cloud - the cloud is acknowledged, but is only used in exceptional circumstances
3. Careful in the cloud - the cloud is accepted and used in cases that make sense
4. Cloud is the first choice - the cloud is used whenever possible
5. Cloud only - there is no choice but the cloud

Cloud usage and application types

What types of cloud we can use, we discussed in this article. Before we get into the question of what the cloud is actually used for, it is important to define the difference between an internal and external application in an organisation.

Internal applications are those that we develop within the organisation by our own efforts (or with the help of external companies). We always have the right to influence their architecture and related infrastructures. We usually run internal applications in our own datacenter, and use IaaS/PaaS services for them in the cloud.

External applications are supplied by third parties. Sometimes they take the form of a service containing an application and business processes. For external applications we have no influence on the architecture and infrastructure. In the cloud, such applications are referred to as SaaS applications.

When is the cloud useful for internal applications?

For internal applications, the use of the cloud depends on the state of the on-premise infrastructure and the investment cycle. If I am facing a new investment cycle, I may opt for a higher rate of on-premise infrastructure replacement.

Otherwise, I opt for a rather gradual ramp-up of the cloud with a form of replenishment. Deciding what to use the cloud for is primarily in the hands of IT for internal applications. You just need to consider the financial implications and resolve a few question marks:

• Which cloud provider?
• Multiple vendors - yes/no (multicloud)?
• Coexistence with private cloud (hybrid cloud)?
• Bound to automation and DevOps?

Choosing an IaaS / PaaS cloud / multicloud provider

Commercial organisations choose from the world's leading cloud providers AWS, Microsoft Azure, Google, Oracle Cloud and sometimes include on-premises cloud providers. State governments are more likely to consider national "certified" cloud providers.

Our experience in cloud projects tells us that due to factors such as presence in our markets, financial incentives to migrate, breadth of service portfolio or level of security and compliance, the choice between AWS a Azure.

When choosing a cloud provider, we choose the entire platform, not just one service. Dual vendor policy (or multicloud)  is an important topic if there are concerns and risks of relying on a single provider.

Deciding whether to use multicloud is hard. On the one hand, there is the benefit of independence, which is countered on the other by the double effort, investment and adoption of multiple providers. If you ultimately decide to dual vendor policy, we recommend spreading provider adoptions over several years.

Want a hybrid cloud? 

Question hybrid cloud is open if the organization has already invested in private cloud - by extending automation in on-premise infrastructure (VMware) or due to the need to have an environment for development/orchestration/automation of microservices (Openshift). Thinking about public cloud deployment opens up issues of coexistence with private cloud:

• Will we continue private cloud activities - yes/no?
• What will we use private cloud for and what will we use public cloud providers for?
• Will we consider extending the private cloud to the public cloud?

In the search for answers, two conflicting lines of reasoning usually come up against each other - Continuity (evolution) versus Innovation (revolution).

Some consider continuity in the use of private cloud more important. Therefore, expanding the data center to the public cloud is seen as an evolutionary step that will bring the same environment, minimal process changes and preserve the investment in the private cloud.

For others, the key revolution is to forget about the private cloud and start using only the public cloud and its associated benefits: innovation, continuous technology development, cloud native application development or the finer points of cloud pricing (pay-as-you-go, reserved pricing, time-of-use workloads).

Automation, DevOps and cloud native applications

The cloud is built on resource efficiency and automation, DevOps and cloud native applications (container-based and microservices-based applications).

On-premise automation is built from the ground up by passionate individuals who love to explore and want to make their jobs easier. However, it takes a lot of effort and energy to maintain, develop and document an automation environment.

 The public cloud has automation as one of the basic parameters. Automation, DevOps and cloud-native applications are positive motivators and accelerators to leverage the cloud - so they shouldn't be missing from any cloud strategy.

 The positive news is that most of the investment you make in on-premise automation in the cloud will be used and multiplied. The key is the integration of your DevOps platform with the cloud and the ease for developing cloud native applications (containers and microservices).

How to manage the coexistence of cloud and on-premise?

Another very important topic is the principles and tools that will help you manage the coexistence of on-premise and cloud. These five principles are used to do so:

1. Divide IT into smaller areas (separately they are easier to solve).
2. Follow the same principles for each area.
3. Use multi-speed access.
4. Define cloud/on-premise rules for internal applications.
5. Define cloud/external vendor rules for external applications.

Three-speed access for internal applications

The multi-speed approach is a tried and tested procedure. You may recall the term two-speed (bimodal) ITwhich began to be used more than ten years ago. To divide applications and infrastructure according to "cloudability", it is useful to divide them into three groups, which also reflect the speed of deployment of new versions (releases):

1. Legacy applications - cannot be migrated to the cloud or very difficult, slow release
2. Cloud ready applications - can be migrated under certain conditions, faster Release
3. Cloud native applications - are developed specifically for the cloud, the fastest release

U Legacy we're not even thinking about the cloud. It is important to have such a category and not to try to cloud it. Cloud native on the contrary, it tends to be a whole new category. In order to have cloud native applications, we need to change our development and operational practices and use a 12-factor approach (we'll cover in future articles). U Cloud ready applications (typically recently written in JAVA, .NET), we define the conditions, effort and costs under which we are able to migrate the applications to the cloud.

With the three types of applications and related infrastructure defined in this way, it is easier for the organization to define governance principles such as: where to place applications, development style, use in DevOps and automation, architecture and development standards, type and speed of release, types of application integration, and many more.

The following figure shows an example of how to define the basic principles of IT Governance:

Governance of internal application processes

Cloud implementation will usually affect most IT processes. What needs to be adjusted and changed is always the result of cloud maturity analysis of teams and processes (individual areas will be discussed in future articles).

Most organizations will be surprised when deploying the cloud by the following five processes, which are completely different/new compared to on-premise practices - in content, interconnectedness and the intensity with which they need to be addressed.

Standards/Blueprints

In on-premise we use the term architecture standards, the term blueprints is more commonly used in the cloud world. Blueprints can be easily automated and long-term sustainability dictates that only a small number of blueprints are needed.

From a governance perspective, it is important to define the processes for the creation, sizing, updating and approval of cloud blueprints, which are either non-existent or very limited in the on-premise world.

Procurement/procurement 

In on-premise we tender specific hardware/software/services several times a year and then order one or more fulfillments.

In the cloud, we have the provider's price transparently clear up front. It depends on what parameters we choose, and the price tag is clear. If we want better conditions, we need to know the expected cloud spend for the next 2-3 years and ask the provider for an additional discount.

From a governance perspective, it is important to define the "billing" structure and labelling principles (tags)so that we have the correct cost breakdown generated by the cloud platform.

Consumption of services 

In on-premise we do capacity planning once a year, the service design is static and always covers performance margins and all environments.

In the cloud, the design is dynamic and we tend to have only the most necessary elements in place so that we only spend on what makes sense. We need to check service consumption much more frequently - preferably 1x per month.

The more often we check our service consumption plan, the less likely we are to spend on something unnecessarily. From a governance perspective, it is important to define the owners of the service consumption control, the frequency of the control, the rules for correct and incorrect spending and the timely termination of services.

Service optimization 

In on-premise, optimization of services is done once a year, or when there are performance problems. Everything is properly oversized to avoid problems, and the license forces us to do shared technology units.

In the cloud, design is done at a micro level and it is more than appropriate to focus on optimizing services much more frequently - ideally quarterly. This will capture longer term trends resulting from monthly service consumption checks and new developments in cloud services.

From a governance perspective, it is important to define processes for optimizing services, covering peaks, timing resources off and on, and new component pricing plans.

Budgeting

On-premise is the normal budgeting of IT services for the year with 3-4 updates per budget chapter. Allocation of budgets per application is not required and, if implemented, is very labor intensive (especially when determining allocation keys).

In the cloud, the budget is calculated for 2-3 years, with continuous monthly checks and corrections after quarters. Unfortunately, at a much higher granularity (applications, environments, cloud components).

From a governance perspective, it is important to have the processes of standards/blueprints, procurement/ordering, consumption and optimization of services properly set up and linked so that the budget can be managed.

Access to external applications

External applications are divided into two types - outsourced and SaaS.

Outsourced application is one that is tailored to us and we can influence all the key parameters: provider, contract, price, terms of provision, security, governance, etc. The application is usually provided individually.

U SaaS applications the possibilities to influence the contract and the terms of provision are limited, the service is usually provided to several customers at the same time.

When is the cloud useful for external applications?

The motivation to use the cloud for external applications is different from internal applications. While internal applications seek to use the entire cloud platform, the choice for external applications is individual and has many motivations:

• What do we want to take care of and where do we leave the responsibility (for example, for operations and infrastructure) to someone else?
• Do we or do we not have a choice? Some applications exist only in the cloud (e.g. productivity applications Webex, M365, GApp).
• Do we have the ability and resources to innovate technology? Or do we purposely want it from a provider who can do it better, faster and has more money to do it?
• We know that someone specializes in selected business processes that allow us to accelerate the business or the efficiency of the organization's processes, and at the same time offers an application - for example, ServiceNow.

The decision to choose the right solution for SaaS applications is much more in the hands of the business units, taking into account the opportunities in IT.

Governance of external applications

Governance of external applications depends on the ability to control the terms of delivery of the application/service. The more we can influence the terms of delivery and contractual arrangements, the more our the application governance rate increases and the risk decreases (and vice versa). From this point of view, it is useful to divide external applications into three groups:

1. SaaS without governance - The contract is immutable and online, we usually can't influence much/anything - typically a "take as you go" service.
2. SaaS with governance - The contract is partially immutable, we can modify the terms of service - manage settings, integrate identity and control access to data (e.g. SalesForce, JIRA, ServiceNow).
3. Outsourcing applications - The contract is tailored to our needs, we can influence many parameters including governance and risk.

For outsourced applications, we can afford individual governance. For SaaS applications with governance, we can manage governance through integration with corporate identity, manage corporate data, set risk factors and corresponding security, GDPR and regulatory controls - there is no more the provider or platform can offer.

The ten commandments for a smooth coexistence of cloud and on-premise! 

Cloud deployment is a big change. The organisation needs to the help of all its members - and they in turn need simple instructions with clear messages for communication and adoption. Governance rules for the coexistence of cloud and on-premise are an important part of cloud strategy as well as a fundamental essence for change management. I offer a simple ten for these purposes:

• It is useful to have a definition, what is the organisation's approach to the cloud. The exact type of approach is not important, but clearly communicated position.
• The mathematics of 1 + 1 = 3 (more here). Therefore, set Rules proceedings cloud-based, on-premise and the coexistence of both environments.
• Internal applications use the cloud differently than external ones. The rules for selecting and managing cloud platforms and providers must respect this.
• The world is not a simple place and we must clearly deal with questions multicloud (dual vendor) and hybrid cloud.
• Cloud help accelerate Automation a development of cloud native applications.
• DevOps is an excellent link successful coexistence of cloud and on-premise environments.
• Cloud enables versus on-premise faster deployment of applications. IT governance rules should respect the multi-speed approach as one of the key parameters of governance.
• Split internal applications by "cloudability" (legacy, cloud ready, cloud native) and define key governance parameters - Application release and placement speed, development style, use in DevOps and automation, architecture and development standards, types of application integration, and more.
• Split external applications according to "impact on delivery and contract conditions" (SaaS without governance, SaaS with governance, outsourced applications) and define key governance parameters - Identity integration, corporate data management, determining risk factors and corresponding security controls, GDPR and regulations.
• Expect that unlike on-premise, you will have to make your management processes can be divided into three types1) you keep the same, 2) you have to do things differently, 3) they are new to you.