Total cost of ownership: The hidden part of the iceberg
Explore the invisible costs of migrating to the cloud
It seems like these days, everyone is talking about Containers, Kubernetes, microservices, serverless, cloud-native computing, and the Journey to Cloud or multicloud. These key technologies have many advantages, but you should be aware of some of the hidden costs associated with moving to the cloud so that you can plan in advance and avoid any surprises along the way.
Before migrating to the cloud, you should consider the following:
Migration of your business applications: How, when, and with what method are you going to rehost your applications (other common terms are like for like, as-is, or lift and shift), or will you rearchitect them?
Target platform cost (could be one of the cloud providers, a container platform, the license/subscription costs): Find out your existing environment details (baseline, capacity, and performance) and calculate what you need in the target environment.
Decide your future operating model: How to enable the application of your strategy to a business or operation and be organized to deliver and execute more efficiently and effectively.
Get buy-in from the product and business owners: Rather than building new features, you will be working on something that on the surface is of no value to the product and business owners. Only in the long term will they be able to see the benefits of being able to deliver faster. You need to be able to give them a value-add from that work so that they will support the effort you know you need to do. This is often an issue. Sometimes, the value-add is not tangible, so you almost have to market this “journey.”
Create a project plan and start moving.
Apart from deciding the target platform, the migration approach, tools and processes, getting the support, and creating a project plan, you need to be aware of the Total Cost of Ownership (TCO).
Total Cost of Ownership
Gartner defines TCO as “a comprehensive assessment of IT or other costs across enterprise boundaries over time.” For IT, TCO includes hardware and software acquisition, management and support, communications, end-user expenses, and the opportunity cost of downtime, training, and other productivity losses.
In the context of the Journey to Cloud, TCO is the metric to quantify and measure cloud adoption success. This perspective helps you understand the return on investment so that you can prioritize and focus.
TCO is not only about capacity, software, or licenses — it is more of a holistic perspective of the journey that includes organization, culture, talent, communication, consulting, and more. What you consider at the beginning of the Journey to Cloud is just the tip of the iceberg. Let’s look at some of the invisible costs:
Organizational change (pair programming, DevOps)
Cultural change (fast fail, innovation, MVP)
Enablement of these changes
The break-even point
Your progress in this journey will bring higher expectations of availability, performance, and reliability. You will need new approaches to operate your new environment paired with organizational and cultural changes. As you work to transform your organizational practices, be mindful of the context that you are starting from and how open your organization is to making changes. In a traditional setup, your organization might have database teams, middleware teams, and operations teams based on their skillset; unfortunately, this structure does not work with a microservices architecture or cloud native system. You need to create teams that have the end-to-end responsibility of a specific component: They develop the new features, build it, deploy it, run it, and maintain it if the component is broken. Each team is completely responsible for delivering a component.
You can also build a roadmap to leverage new engineering practices: enterprise design thinking, agile, and iterative development. With DevOps, the common goal of the developers, operations, or designers is delivering applications together with a shared responsibility and a common goal that drives the automation of tasks. This is a people and an organizational principle, not just process-centric. It can be a challenging task, so be careful not to create new silos and be cautious with anti-patterns. This change is a key: The companies that are willing to make the necessary organizational changes are more likely to succeed in the cloud.
Cloud native is a different way of thinking compared to the traditional systems. Cloud-native systems do many things differently. Cultural change is crucial to achieve this. Changing the thinking at a high level is as critical as the low-level practice. Especially in larger organizations, having an agile delivery team with an offering team in legacy mindset would help you to achieve your goals. For this reason, you need to prove that these practices can truly deliver applications that can scale quickly and safely.
First, agile does not deliver software faster, but it does decompose your application into smaller pieces that can help you deliver faster and more frequently. It’s not a release of the full application anymore, but smaller isolated components.
An important value of agile is openness: the necessity for a blameless, post-mortem culture to reveal the root cause of an incident and learn from it. Fast failing is another key aspect, creating an environment for innovation, of course with the support of automation and leaving more time to the developers. The adoption of cloud with access to more data, analytics, and AI accelerates the innovation. You can support the fast-failing approach with Hypothesis-Driven Development, where you use hypotheses instead of requirements to hypothesize and make data-based decisions to deliver what your customer wants. Experiment early and often, solicit feedback from your customers as to what works for them, and discard any features that provide little benefit or hinder customers. Adopt a mindset of continuous experimentation, where you explore multiple options. You have to be willing to fail fast and accept the outcomes when the experiments don’t work.
Also, the traditional way your teams used to develop, build, deploy, and deliver an application will change drastically: DevOps pipelines and the principles surrounding them (for example, continuous integration, continuous delivery (CICD), and Automated Testing) are another aspect to consider.
It’s equally important to contemplate how this cultural transformation will take place. The complexity and the cost of this transformation are two main reasons why many organizations are still not ready with their journey. Like any other complex project, enabling these new technologies requires detailed planning and flawless execution.
To implement a DevOps culture, you need tools and infrastructure that can enable automation, collaboration, and communication across your developers, designers, and operations teams. A CICD pipeline supports the teams to automate the steps in the delivery process, such as code builds, running automated tests, and deploying to a staging or production environment. You need to plan using toolchains to start developing and automatically delivering applications quickly. This can be a bit messy because there are so many open source and proprietary tools. You can roll your own set of tools or consider an enterprise scale tool. Using Red Hat OpenShift might help to reduce the worry here, because it has a set of tools to cover the development, monitoring, logging, deployment, and many other concerns.
Automation is fundamental for a successful cloud journey. The DevOps pipelines help to automate the testing of the applications and even stop the deployment if any of these tests fail not to have any issues in the production. The cloud infrastructure can also be created and configured with the use of code: “infrastructure as code.” It enables you to deploy and configure network, storage, compute, database, operating systems, security, and other components via some API calls. While enabling the CICD for your application builds and deploys, you should also consider adopting “infrastructure as code” with your deployments. Integrating these two aspects helps you to have a rapid, flexible, and self-healing system. We can categorize the automation in three different levels:
Application Deployment : CICD Pipelines using Jenkins, Tekton, and UrbanCode
Middleware, Database, Agent deployments, and configurations: Configuration automation tools like Chef, Puppet, and Ansible
Infrastructure Deployment: Infrastructure as code using TerraForm, CloudFormation, and Ansible
Securing your new hybrid multicloud environment requires different approaches, methods, and tools than your on-premise environment. It might become a little bit more complex to manage at the beginning and involves additional costs: software license and labor. Considering security at every phase of your new lifecycle is a key to a successful journey, which will lead you to combine it with DevOps to emphasize the need to build a security foundation: DevSecOps. This framework thinks about application and infrastructure security from the beginning, with built-in security and the use of automation at every chance to allow for flexibility and agility. Choosing the right tools to integrate the security (like security scanners for containers or security testing in the continuous integration process) can help you to achieve your goals. But remember, this is not only about tools and technology, it is also about the cultural changes: security is not a separate tower, it is included within the end-to-end application lifecycle so that you can avoid long development cycles even if you apply DevOps approach. Adding that after the fact will break your agility.
Another aspect you should consider is labor cost. While introducing new technologies like cloud platforms, Containers, infrastructure as code (IaC), and more, you also need people to execute. It’s important to plan to up-skill your people: training is a significant cost. You might need some consulting services to do the following:
- Define the opportunity and prioritize the ideas (co-create)
- Realize this opportunity with your first MVP(s) (co-execute)
- Scale it while transforming your culture and transferring the knowledge to your teams (co-operate)
(See the IBM Garage Method for details.) First, you can plan to earn the skills to have pipelines and a running container platform before really thinking about having a full cloud native, 12-factor-enabled applications. You might need to hire new people with different skills, while keeping your team with years of experience to create a balanced mix. This can help get buy-in and keep your workforce challenged as they learn new skills. They can create repeatable patterns to save time and frustration. Implementing patterns after behaviors have been formed is hard, but doing it from the ground up eases the effort for adoption. And remember, skills are tightly coupled with enablement.
The break-even point
There’s one more thing to be aware of: the break-even point. While investing on these new technologies and migration, you expect to gain agility, flexibility, speed to go to market, innovation, and more. Your investment will pay off but not right away. You need to invest continuously to get the return on the investment, so you need to know how long your company can wait for this return. What’s the break-even point for your company for the journey to cloud to pay for itself? A new cloud ecosystem/environment will go stale just like a data-center-based one if you don’t build in the right expectations for continual investment to keep it running in tip-top shape.
Wrapping it up
At some point, you might start to transform your infrastructure to a hybrid multicloud platform to enable your enterprise to build, run, and manage applications and workloads in a consistent way for innovation and digital transformation. This Journey to Cloud can bring you efficiency, flexibility, scalability, and agility along with a cost: your TCO. Be mindful while calculating your TCO, because it not only consists of tools, licenses, cloud environment resources, and migrating your applications to cloud, but also organizational changes, cultural changes, enablement, automation, security, skills, and the break-even point. Taking these points into consideration in your early plans can help you achieve success in your journey.
You could take a DIY approach to deal with all the required transformation. You can also work with a trustworthy Cloud Managed Service Provider to control and reduce your TCO significantly. You could leave the heavy lifting to the managed services or public cloud providers so that your staff can focus on driving the real business value for your customers instead of maintaining the infrastructure, configuration, and operations such as monitoring, logging, and anti-virus; creating an automation platform from scratch; keeping the environment up to date to avoid any technical debt. They bring their tools, expertise, experience, proven methods, and frameworks specific to your industry to accelerate the value realization in your Journey to Cloud.