As  I’ve been involved in a few projects lately, moving Oracle databases and middleware to the (Oracle and Azure) Cloud, I thought it would be nice to share my experience and some do’s and don’ts. This post is not meant to be a highly academic and theoretical essay with a lot of architectural talk and accompanying buzzwords, but more of a practical guide in the good practice of sharing knowledge. It’s inevitable, however, that all of this stuff is embedded in the steps you take when following architectural frameworks like TOGAF.

I chopped the process of the journey to the cloud in the following pieces:

  1. The decision
  2. The strategy
  3. The preparation
  4. The design
  5. The effectuation

1.     The decision

The most important part of the journey is: why? Why move to the cloud? Is there a business case, and is it clear when it’s considered to be a success? Does it solve a (future) problem? When this is a bit unclear, or not fully supported by the stakeholders, it’s almost a guarantee for unpredictable results.

If it’s predominantly an IT push, it’s hard to explain to the business and difficult to get funding and (test)resources. The IT department exists for the business, so the business case must be solid, crystal clear and monitored during the journey.

A business case like ‘becoming more agile’ will be questioned during the project when the costs are higher than expected. Especially when the business is the supplier of the funding and test-resources.

Sometimes, an image works better. It could help the management to decide and you to discuss and define the hard and soft savings, validated to the business needs.

Source: https://recap-project.eu/news/what-is-the-future-of-hyperscale/cloud_computing_strategic_alignment_model/

Soft cost savings are difficult to define, such as the before mentioned ‘becoming more agile’ or ‘improve business and IT performance’. But when they’re clearly defined, in more detail, they may have a lot of impact. They could even hold the key of getting the business on board, and be a motor for the project.

Hard cost savings are easier to define, such as ‘Operational savings’, concretized by a TCO-calculation. Be aware, however, that these kinds of calculations tend to be open to multiple interpretations.

This chapter can also be summarized in fancier words:

  • Cloud Business Vision: Align your cloud strategy with business objectives to create a compelling target end state
  • Cloud Value Case: Identify the costs and benefits of the next stage of your journey to the cloud

2.     The Strategy

The decision has been made and the business is heading to the cloud. One of your next decisions should be: which cloud? Private or public, and when public, should it be Azure, Google, Oracle, AWS? Or should we put our eggs in more than one basket?

There are a lot of blogs about how to choose the right cloud provider. Most are based on the provider’s quality and other important criteria like location, e.g.: https://blog.avmconsulting.net/posts/2018-02-14-choosing-the-right-cloud-service-provider-for-2018/ .

But this decision also depends on your own strategy and situation. A small list of considerations:

  • The scope of the move. Are all applications going to the cloud, or only the new ones? When you intend to use the cloud for development purposes only, you have to look at the development possibilities of the intended cloud provider. When data is more important, it could merely be the location and management capabilities.
  • Don’t focus on database alone. There’s also an application running, perhaps on Windows or Solaris. Move the complete application stack, don’t leave anything behind to avoid the risk of network latency.
  • Is there already something running in this cloud?
  • Has a particular group of applications and/or databases similarities, like:
    • Chance on cutting license costs. When e.g. less licenses are needed on-premises, the business case could be simpler, purely based on hard savings. In the case of Oracle software, the Oracle cloud could be a logical choice, but not by definition the right one.
    • Same Operating System. When the intended Operating System and environment of authorization and authentication is still mostly Windows-orientated, the logical provider could be Microsoft Azure. On the other hand, when the intended environment is Linux oriented, all the providers do qualify, including Microsoft Azure.
  • Is the policy to have less management of the applications and databases, or is the policy to just move the stuff and manage it yourself? In other words: SaaS, PaaS or IaaS? Not all the providers deliver the SaaS or PaaS services you want. E.g. Microsoft Azure has no SaaS or PaaS service for an Oracle database or middleware.
  • Is it important for you that the provider guarantees the data location and security? Microsoft, for example, states that you are in control of your data location: https://azuredatacentermap.azurewebsites.net/ . Quote: “Most Azure services enable customers to specify the Region where their customer data will be stored. Microsoft may replicate to other Regions for data resiliency but Microsoft will not replicate or move customer data outside the Geo (see below for details). Customers and their end users may move, copy, or access their customer data from any location globally.”
  • Is there an exit plan, or is it no problem ending up in a kind of vendor lock in?

 

A comparison between IaaS, PaaS and SaaS:

https://www.eukhost.com/blog/webhosting/iaas-paas-saas-cloud-computing-services-comparison-and-advantages/

This chapter could also be summarized as:

  • Cloud Roadmap: Plot your journey through the options and activities needed to deliver the end state

A nice story about choosing a strategy: https://www.vxchnge.com/blog/how-to-develop-a-cloud-strategy

3.     The preparation

ust like a regular move, you tend not to move all the stuff that’s in your house (I hope…). You decide what furniture will get another home, and what will accompany you to the new house.

Sometimes it really helps to realize that every application or database that runs in the cloud, generates costs. Make these costs visible.

Some points to consider:

  • Know your own environment / applications. Are your applications cloud-aware? Is there an updated CMDB, for example, and do you know the dependencies between the applications and the databases?
  • Perform an application rationalization (“Is that legacy application really needed?”)
  • Check where your data resides, regarding privacy regulations.
  • Align the technology roadmap with the business roadmap or the other way around.
  • Plan a pilot.
  • Get your organization ready for managing the new environment regarding changing roles and (SLA) processes.
  • Train your personnel.
  • Get everybody on board.
  • Define your architectural principles.

This could be summarized as:

  • Cloud Transformation Plan: Identify the associated organizational changes and skills needed to unleash the true potential of cloud.

4.     The design

The design is actually part of the preparation, but I thought it deserved a separate chapter. You should consider making a thorough cloud design, with special interest in network, high availability, performance and security. I strongly recommend to always make a design.

Some design considerations, depending on your architectural principles:

  • What is the so-called ‘end state’ of your applications and databases? Modernize or not, while moving? And is the policy valid for every application?
  • Which application will be moved to PaaS and IaaS, and what SaaS can be used?
  • Define one or more availability configurations in the cloud, and plot your applications on one of those, depending on their requirements. Don’t end up with endless discussions about the number of 9s: 99.99% or 99.9999% availability.
  • In case of a datacenter outage, decide if you’re taking extra measures. Use of a standby-database in another datacenter makes sure you’re in control, for example, and not the provider.
  • Which applications/servers in the subscriptions (Development, Test, Acceptance, Production) are 24/7, and which can be switched off during the night and weekend?
  • If possible, start with a small capacity and scale up when needed.
  • Trust the monitoring capabilities of the cloud provider, or plan your own management/monitoring-tooling. Focus on monitoring of the operational costs.
  • Is there any risk of latency? Especially when old applications (clients / middleware) are left behind on-premises and the databases are lifted to the cloud. Try to avoid that situation.
  • What will be the level of automation, and should I design some tooling for this?
  • Are basic services such as file services, Active Directory, DNS and monitoring/management also moving to the cloud?
  • What are, approximately, the monthly costs?

5.     The effectuation

If there’s one thing I would recommend when going to the cloud: start a pilot or Proof of Concept! But don’t restrict this just to technical capabilities. Perform this together with the business.

Involve the following in the pilot:

  • SLA with cloud provider, software providers and maybe more partners.
  • Performance: is it as expected?
  • What level of automation do you want to achieve?
  • Life Cycle Management, what to do with patches e.g.
  • Changing roles, is the skill level of your own people enough?
  • Technical stuff like performance, High Availability, cloudready applications etc.
  • DevOps readiness
  • ITIL processes, like change management and incident management
  • Security
  • Governance (when not already covered by other subjects)
  • Monitoring
  • Failover test
  • Etc.

When the pilot is done, evaluate and decide if it meets the requirements and goal. You can still turn back now…

If everything looks positive, make something like a “Cloud Implementation Roadmap”: Plot your journey through the options and activities needed to deliver the end state.

And execute through DevOps or another method.

Example high end:

Source: https://its.umich.edu/projects/cloud-program/program/roadmaps

Regards,

Job.