Estimated reading time: 15-20min
How did we get there?
The “ABC” enterprise (fictitious, obviously) wants a new IT for 2020 with 2 main objectives: optimize time-to-market (reduce time to provision), optimize finances (reduce CapEx with OpEx instead, Amortize and report in EBITDA).
The IT solution for these two business problems is to move its existing infrastructure to the Public Cloud(s).
This assumes that the enterprise has an infrastructure – which is rhetorical, since ANY enterprise with existing activities will have IT assets.
A newly created startup may be able to start directly in the Public Cloud, but for almost all existing or new businesses, the next step will be to “go to the cloud” and not to “start in the cloud”.
Frame needs and vendors
A first look at the Public Cloud vendors gives a very long list (https://en.wikipedia.org/wiki/Category:Cloud_computing_providers).
The enterprise has few but strict demands: The IT decided to migrate Pre-Production and Production assets – some will remain OnPrem according to regulatory or content delivery needs. They are not (yet!) integrating Development purposes because they focus on “quick wins”, highly visible budget and more predictable costs.
Moving existing assets requires platforms. whatever this term means -I’ll cover it in a future post- here, we will consider the enterprise’s IT assets are composed of physical servers, virtual machines (vm), containers.
Discuss only of providers who actually “own” their Cloud within their data centers, provide multiple levels for necessary platforms and are significantly present in the world.
The top10 shortlist is:
- Amazon AWS
- Microsoft Azure
- Google Cloud
- IBM Cloud
- Oracle Cloud
- Alibaba Cloud
- Fujitsu Cloud
All of these providers have in common the provision of hosted and infrastructure services and platforms. But without being restricted to these services, they also offer various others, from networking to IoT (Internet of Things).
Each provider has its own specialization and particularities: some are focused on IoT, others offer a large amount of services, some have additional security qualifications while others have presence in specific geographic areas.
The IaaS services (IaaS = Infrastructure as a Service) offered by public cloud providers include bare-metal servers (hosted), virtual machines (vm), containers (in Kubernetes constructs) – which cover 100% of the needs of our ABC enterprise.
Services of Public Cloud providers in addition to the IaaS services are usually called “native services”. This is everything that is “uncommon” and with added value – examples are global dns, LoadBalancer, file storage, machine learning, function triggers and much more.
The “move to the Cloud” is a multi-dimensional strategy.
First dimension of the strategy is “migration approaches“, which help to select the way to go.
Second piece is the “cloud within the cloud” layer, indicating which technical formatting can be used.
Last one is “those little things“, which consist of non-technical requirements to be successful.
Each dimension will be detailed in the following paragraphs. A quick graphic on that:
Migration approaches (workload typology)
Migration approaches is tied to how workloads and associated applications are developed and the technical debt.
The more applications the company has, the more applications are considered to have a high technical debt. That’s also applicable with the age of enterprise, complexity or merges and acquisitions, or even the business vertical.
I will not detail here what means technical debt and application typology, but in short there is the “legacy” apps/workloads (usually the large majority) which are implemented using classic or IaaS platforms – something/someone provision the hardware and operating system, App owners do the rest. Remaining is either Paas or SaaS-based, currently in development or in process of re-engineering.
To move those workloads to the Cloud, there is 3 main choices:
- Continue as the enterprise does, add the new needs -> Platform first.
- Use what providers offer and complete with IaaS as needed -> Native Services first.
- Take advantage of both worlds by mixing the old but well known way of IaaS-based services and use native services when it makes sense and with respect for agnosticity -> Cloud Native approach.
Let’s detail these levels:
The first one, “Platform first” is platform-focused, it’s the easiest approach because it only involves IT staff, no changes intended or planned on the processes or people, no actions/participation of B2B (business-to-business) or LoB (line of business). However this will not help the enterprise to save money (as it is a 1: 1 move), while the OnPrem cost is often cheaper than those of Public Clouds. IT spent will become even more expensive than before. Note that vendors often tout this approach as “invisible”, but if technically it can be true, it’s generally not painless in terms of process (day1 and day2) and people (training, certifications, …).
Second item, “Native Services first” -this is the approach favored by techies- it’s the most beautiful technically speaking because it uses the best of breed of the vendor and the available technologies.
However, vendor-locking is very important and it’s in reality a technical chimera. To add another of the several drawbacks, it’s quite impossible to achieve required changes in the IT management of the enterprise – that represents a huge step in terms of technicality, process, teamwork, skillset.
Migration to that will require a huge investment and involvement of all teams, from IT to externals and developers, going though line of business and management.
Third and last, the “Cloud Native approach”. This partly uses the IaaS model for a large part, some native services or external services and an growing amount of PaaS for new applications. It allows the enterprise to capitalize on known elements, without changing old / legacy / commercial off the shelf (COTS) applications and opens the possibility of modernizing applications (replatform//recode/reengineer) to reduce the technical debt of existing applications.
Upon seeing these details, the journey of ABC enterprise will consist in 2 stages: start with “platform first”, which would help migrate large amount of the workloads, and finish with the “cloud native approach” for the remaining.
Cloud within the Cloud (tech platform)
Tools exists to migrate from the existing OnPrem platforms to the Public Cloud platforms- some vendors can also convert the source to their format. This last statement may not look like much, but it’s a very important topic- yes, each vendor have its own format, and it counts in the vendor-locking. At this point, ABC enterprise is not fooled and does not expect zero vendor-locking.
To minimize/avoid vendor-locking from Public Cloud providers, ABC enterprise can use a subset of the offerings: a technology common to multiple providers which will allow easy move from one provider to another.
The only technologies available on all major Public Cloud providers and partners come from VMware for virtual machines and based on Kubernetes for containers.
VMware has presence on Amazon AWS (VMConAWS), Microsoft Azure (AVS), Google (GCVE), Oracle (OVS), IBM (VSI and others), Alibaba and OVH. It is largely based on the VMware Cloud Foundation solution (VCF), which brings all parts of software-defined datacenter to hyper-converged infrastructures.
Kubernetes is present in all providers, but not without “customization”- you may not be able to do the same complex things on all providers.
Having a common underlying technology (VMware and Kubernetes) is EXTREMELY important: it helps a lot in the process, people and tooling – a company cannot afford to re-train all the staff, write new processes for all IT BUs and create new operations units and operators staff.
The average cost analysis of virtualization shows that more than half the cost of a vm is linked to processes and people (not hardware or software) – hence the advantage of using known technologies. Having the same execution infrastructure (VMware or Kubernetes) on several Clouds and OnPrem facilitates the move (back and forth, if necessary) of workloads. Day2 operations (a major expenditure item) will not be a surprise as the platform and its operations is well-known and will save a lot of time and money.
No need to say that the format of the vm or container is not only file extension and coding but everything tied to these objects. Some examples, technically speaking: backup features and compatibility, monitoring tools, showback/chargeback tools, assets management & inventory tools, upgrade systems and their processes, security responses and posture, network connectivity…
Outside the tech, the format also relate to communities, number of active users, size of knowledge base, number of people trained on the job market…
Those little things (non-tech needs)
The third topic to consider for a migration to the cloud is the “side things” of IT or non-technical needs. Usually forgotten by migration teams because it is not (only) technical, but nevertheless very important as it could make the best planned and executed migration fail.
A list of those little things is:
- Adoption by the IT teams
- Maturity of the security and operations teams
- Process maturity, openness and flexibility
- “Promoting IT” – the other BUs in the company know IT and do not see it as just a cost center
Unlike the other layers, there is nothing to choose from here – it is about making sure that each element is sufficiently complete.
Each element of this list that is not (at least almost) complete is a risk for the migration to Cloud.
This list is ordered – the beginning requires education to eliminate the risk, the end requires financial investment.
If we dig a little bit deeper into the elements:
Adoption is needed because the teams cannot support, architect and properly operate something they disagree on.
Maturity of IT Sec & Ops teams – why specifically these teams? Because they are known to have maximum ability to cause trouble, and they MUST be aware that we are no longer in the 90s. An enterprise cannot continue to do security and operations in environments not-fully-managed (like public clouds) as they would like to do with a fully controlled environment. It has nothing to do with the technique but a mindset to adopt and some “best practices” to reconsider.
Process maturity is about getting ready for the new process, the ways of managing and operating, teamwork, hierarchy of teams, virtual teams. Major groups are infrastructure (monitoring, logs, security, capacity planning…), operating systems / middleware, application (injection tests, load testing…), assets management (licenses, inventory), FinOps (costing, (re)billing,…)
“Promoting IT”, totally non-technical, this article is generally classified as “marketing”. IT is often seen as a cost only, because the services provided are seen as “basics” by employees and management. To get more credits and be able to survive, IT needs to show its value (the first step is often to do showback and chargeback). But that’s also mood, adoption and influence. The best ambassadors of IT is their users (including admins, developers…), and the enterprise “controlled” Cloud must be valuable enough.
To reiterate, those four items are not a choice and are a risk until completed.
That must not be underestimated, a single of these things going wrong can screw up the entire Public Cloud journey.
Bring all together
To all those highlights, ABC enterprise has decided to go with the standards and not venture off the beaten tracks (by other enterprises).
Selected (simplified) 3-d model looks like this (the orange box):
Let’s be clear: this kind of migration seems like a “one-click button”, but tailoring it to reality and thousands of workloads isn’t that simple.
Unaccompanied enterprises will have difficulties for sure to go through this journey without assistance.
It is strongly recommended to get help for this migration, from technical points to governance model, including external ideas and experience from the past.
Setting up a migration factory and driving this journey is something that could be handled by services companies and vendors, thus don’t waste a second and onboard them from the beginning of the story.
We saw from the beginning of this post that in order to achieve such outcomes (better time to market and optimized finances), Public Clouds are valid candidates, but it’s not as easy as it seems. From vendors to platforms types, application maturity, processes and people, it’s a complex equation.
There is no bad or good choices, but several different ways for different goals to achieve. It’s simple to concede on the hearsay but don’t be fooled- zero locking does not exist. zero process or people investment does not exists.
IT is not free nor free, just choose the most suitable for your needs.