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

 

How to arrange cloud adoption? How to coexist cloud with on-premise IT? How to set up the right governance? So asks everyone who ventures down the cloud path. Finding answers may seem complicated at first, but I have good news for you: it’s not only solvable, it’s important. Everyone in the organisation needs simple guidance and clear messages to encourage change and help the organisation adopt the cloud. I will be glad if this article and the draft of the Decalogue contribute to that.

Lukáš Klášterský

 

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 the existing on-premise infrastructure, what do I keep in the on-premise?
• Will I only develop apps for the cloud anymore? 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, modify and 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). How teams and individuals throughout the organisation approach the cloud depends on the attitude of management. A five-level range of approaches can be traced in the market:

1. Without the cloud – the 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 – whenever possible, the cloud is used
5. Cloud only – there is no choice but the cloud

 

 

Cloud usage and application types

We have discussed what types of cloud we can use 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 internal and external applications in an organization.

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

 

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. It is enough to take into account 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 government is giving more consideration to national “certified” cloud providers.

Our experience of 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 falls between AWS and 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 depending 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 opt for a dual vendor policy, we recommend staggering provider adoptions over multiple years.

 

 

Want a hybrid cloud?

The question of hybrid cloud is open if the organization has already invested in private cloud – by extending automation in on-premise infrastructure (VMware) or because of 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 clouds and public cloud providers for?
• Will we consider extending the private cloud into the public cloud?

In the search for answers, two contradictory arguments – contiunity(evolution) versus innovation (revolution) – usually come up against each other.

Some consider continuity in the use of the private cloud more important. Therefore, he sees the expansion of the data center to the public cloud 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, development of cloud native applications 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 applications and microservices).

 

 

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 its 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 investments you make in on-premise automation will be leveraged and multiplied in the cloud. The key is integrating your DevOps platform with the cloud and making it easy to develop 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 to manage the coexistence of on-premise and cloud. The following five principles are used to do this:

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 bimodal IT, which came into use more than a decade ago. To divide applications and infrastructure according to “cloudability”, it is appropriate to divide them into three groups, which also reflect the speed of deployment of new versions (releases):

1. Legacy apps – 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 – developed specifically for the cloud, fastest release

At 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). For Cloud ready applications (typically recently written in JAVA, .NET) we define the conditions, effort and costs under which we are able to migrate the application to the cloud.

With the three types of applications and related infrastructure defined in this way, it becomes 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 a cloud maturity analysis of teams and processes (individual areas will be covered in future articles).

 

 

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

Standardy/Blueprinty. In the on-premise world we use the term architecture standards, in the cloud world the term blueprints is more commonly used. Blueprints can be easily automated, and long-term sustainability dictates that only a small number are needed. From a governance perspective, it is important to define the processes for creating, sizing, updating and approving cloud blueprints, which in the on-premise world either do not exist at all or only to a very small extent.

 

Procurement/ordering. 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 request an additional discount from the provider. From a governance perspective, it is important to define a “billing” structure and tagging principles in order to have a proper decomposition of the costs generated by the cloud platform.

 

Consumption of services. In on-premise we do capacity planning once a year, service design is static and always covers performance margins and all environments. In the cloud, the design is dynamic and we aim to have only the most necessary elements in place so that we only spend on what makes sense. We need to check consumption of services much more frequently – preferably once a 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 control of consumption of services, the frequency of control, the rules of correct and incorrect development of spending and 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 affect 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 laborious (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 service optimization properly set up and linked to manage the budget.

 

Access to external applications

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

 

An outsourced application is one that is customized and we can influence all the key parameters: provider, contract, price, terms of service, security, governance, etc. The application is usually provided on an individual basis.

 

With a SaaS application, the ability to influence the contract and terms of service is limited, and the service is usually provided to multiple customers at once.

 

When is the cloud useful for external applications?

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

• What do we want to take care of and where do we leave the responsibility (e.g. 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 – e.g. 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.