How do you move your enterprise applications to the cloud?

First, we should tackle some short definitions:

• What really is the cloud?
• Cloud is a frame of mind
• Enterprise architecture
• Build, run and observe

If you’re already comfortable with these terms, skip ahead to Getting your enterprise to cloud.

What really is the cloud?

To dive into this, we need to first look into what the term “cloud” really means. There's one commonly used definition from Michael Dell, which is quite accurate in my opinion: “Cloud is not a destination – it's an operating model”. 

To me, cloud is more about how and why. That makes creation of a cloud also much more difficult, when it's not a what, there's no clear end result defined – and no recipe to replicate.

The cloud was originally popularized by Amazon. They gave consumers access to computing resources in the same way as they could access traditional shopping items in the Amazon marketplace. Thus, it was not a new approach altogether, just selling something else online, but computing was more than a completely new type of item made available. 

Cloud is a frame of mind

If we consider that the cloud is about getting what you want, when you want it, it becomes more of a frame of mind. Pay as you go, self-service, instant delivery – these are not characteristics of a cloud as such, but essentials for fulfilling basic human demands for satisfied delivery. I want everything, and I want it now. Having everything at the same time is obviously impossible, so the next best thing is the ability to browse through the full selection quickly until you make your selection. Again, it’s the same as shopping for a suit, a shirt or anything else. 

Obviously, everybody doesn't want to browse through each option to find the absolute best choice, but most instead prefer to rely on common validated choices. Personal trust is given to an external authority, who doesn't actually know about your specific situation or isn’t even involved in the activity itself. 

Solution building itself then is another activity that is also quite related to social interactions. As all documentation is now public and the technical base components are quite settled, finding solutions to your own specific problems is very easy. In other words, you can Google it.

The result of this approach is extremely rapid development, with incidents and issues being fixed through development – as long as the development happens. Once development stops, everything stops.

Enterprise architecture

Alright, time to jump to the other end of the pool – not specifically about what enterprise infrastructure itself is, but more about its principles and how it’s driven. Above, I discussed fulfilling human personal needs – I want, I need. On a similar note, enterprise infrastructure and architecture are fulfilling the needs of the corporate business side.

To put it bluntly, enterprise architecture doesn't care what anyone personally wants. Individual desires are irrelevant for enterprise goals and targets, as depressing as that may sound. These requirements are of course mostly then also targeted towards solutions, not people – solutions must fulfil this or that requirement to be compliant. 

The model is simple. Businesses have needs, so people must deliver and comply. This works extremely well in fairly static traditional environments, as requirements are exactly what operations need to deliver sustainable results. Innovation in operations can be catastrophic in the worst cases, so it’s safer to stick with if-A-then-B policies. 
Getting your enterprise to the cloud 

Based on these definitions, enterprise requirements and the cloud way of doing what you want seem like opposites. And combining them might sound difficult, which has been true in many cases. But opposites don't need to collide. Rather, you can change your perspective to not assess what each does, but instead consider what each is missing – then, the challenge becomes much simpler. 

Enterprise architecture in the traditional world skilfully connects business demand to operational delivery, two aspects lacking from the people-driven cloud approach. 
On the other side, the cloud model's innovation-driven approach delivers new features daily. This is exactly what a modern IT business needs to keep up with competitors. And in today’s world, every business is an IT business.

Fortunately, when positioned correctly, opposites attract by complementing each other. However, cloud approaches present a key difference from the traditional enterprise approach, where processes are the top layer of the delivery. Under cloud integration, control processes must be flipped to the background – from control to observation.

Build, run and observe

Now we get to the actual target state – a sustainable application delivery pipeline. The pipeline consists of three functions: build, run and observe. The observe and run functions are supported by the traditional enterprise architecture approach, while the build function naturally comes from the cloud approach. 
The key to setting up the delivery pipeline is to maintain a native approach for all actors in the flow.

 Build

For developers, it’s vital to offer cloud capabilities in their native format, without creating processes or custom interfaces that might block their effectiveness. Giving them processes for how to offload deliverables, ready results, to operations – to the run function. Wait for goals and targets from the observe function; then decide what to develop next.

Run

Traditionally known as operations, the run function requires stable and controlled processes, accepting new things only through validated flows. Processes and flows are governed according to enterprise architecture and controlled by the observe function.

Observe

The observe function includes business visibility of the cycle and control over targets, budgets and operational requirements. The key part to understand here is that the flow controls are not between the developers and cloud capabilities. Instead, the approach is to observe the results after they've been handed to operations and adjust development targets accordingly.

What’s next?

Now that we know how to integrate the enterprise and cloud, let's look at some ways to execute the application transformation effectively. 

Traditionally, transforming the enterprise landscape into the cloud has been an extremely challenging task, initially looking easy but ultimately becoming a years-long project burdened by dependencies and missing low-level details. And what takes time, takes money, as both direct project costs and indirect costs in the form of lost potential business due to missing out on expect and promised target benefits. 
The traditional process is to migrate applications to the cloud, do some level of transformation to each application along the way, and, only then start reaching the modern benefits. 

In partnership with VMware, we've developed a new approach to this, one that doesn't take years and offers cloud benefits as soon as within one month. Sounds too good to be true? It's not. Indeed, the details speak quite clearly for themselves. 

Hybrid Cloud Infrastructure as a Service on VMware 

VMware is known as a solid building block for any private infrastructure, and a clear majority of private deployments run on it. For this reason, it's the most common source for cloud transformation.  
 
With Hybrid Cloud Infrastructure as a Service on VMware, we approach cloud transformation from a different angle. Instead of moving your applications and servers to the cloud, which requires transformation, we're scoping the migration to the full data center level.

We've taken common building blocks from VMware Cloud Foundation and VMware solutions on Azure, AWS and Google and layered one common service on top – providing a harmonized cloud delivery approach across all cloud delivery locations. This starts from customer edge locations, through different highly secure TietoEVRY private cloud deployments, and to public clouds ultimately. And all this is available through one delivery via VMware Cloud Director. 

Why move the whole data center to the cloud?

Moving the full data center to the cloud has two key benefits in cloud transformation. One is that the applications or workloads require zero transformation. In other words, everything can go as-is, as long as we stay within the X86 context. Another benefit is that once the data center is transformed, we get modern cloud native capabilities from the private cloud delivery as well, including Kubernetes container as a service, which means that for core re-platforming transformation, we don't need to move into a public cloud anymore. 
 
Of course, public clouds have vastly more services, and transforming onto them often remains the best approach. In this context, having the data center in the cloud offers much more flexibility in the transformation. When the data center is in the cloud, legacy workloads can physically run in the public cloud, right beside the cloud native hyperscaler capabilities. 
 
This means we can execute transformations in a vastly more granular way, just selecting small pieces of the legacy solution and replacing them with cloud native services. 
 
Want more information? Contact us or connect with me on LinkedIn.

For more insights about moving your applications to the cloud, check out the blog: Relocate, the new "R" to move your applications to the cloud faster