What is ‘private cloud’ really supposed to look like?

Crucial for success in building a private cloud platform.

Generated using DALL-E-2

The cloud is a platform that abstracts, and pools resources thereby simplifying and enhancing application delivery and infrastructure efficiency. This is done by providing services, platforms, and infrastructure for development teams to build great products with.

Public clouds

Public cloud providers sell these services to other businesses, taking the burden of implementing and maintaining the cloud, while other businesses pay for these services.

Private clouds

Private clouds are meant to be an implementation of some of the concepts behind cloud computing, while the implementation is done by the business itself, using its resources. Such implementations occur because of:

• Specific concerns regarding data governance.
• Cost optimization.
• psychological barriers regarding the placement of critical data on hardware that isn’t managed by the business.

The problem today with private cloud solutions

Organizations may decide that they ‘want’ the capabilities that the cloud has to offer, but due to numerous reasons, might choose to build a private cloud instead.
The way that many organizations end up implementing private cloud solutions do not achieve part of the major benefits that such a platform has to offer. This is because many organizations mistakenly decide to adopt new technologies, such as containers, API management solutions, and other open source technologies without changing the way infrastructure is perceived in the organization - ending up with old concepts and new technologies.

How ‘private cloud’ is supposed to look

The first step to building a private cloud platform is defining the principles that the solution is used to achieve.

Self-service

A major benefit that the cloud has to offer is that resources are provided on-demand. This means that any service that is provided by the organization’s private cloud provider, is expected to be managed via API that is accessible by other teams.
This is the minimal requirement to call the platform a ‘cloud’.

Rich set of services

Another benefit that the cloud provides is faster software delivery. The cloud allows this by providing as many tools and services for developers, thus allowing the developers to focus on building the product, while the cloud provider focuses on the infrastructure.
Examples include managed databases, DNS, big data tools, monitoring infrastructure, API management solutions, etc.

The structure that organizations should use to back their ‘private cloud’

After understanding what we want to build, the next step is understanding how.
According to our expectations from building a private cloud solution, we understand that the cloud and traditional I.T are disparate.

In order to achieve self-service, a combination of the right approach and technologies (in that order) is required. We must start treating I.T. teams as platform teams.

Platform teams, as mentioned in Team Topologies: Organizing Business and Technology Teams for Fast Flow by Manuel Pais and Matthew Skelton, are aimed at providing X-as-a-service, thereby allowing faster delivery of other teams that consume their service.

An important aspect of this is creating interaction between internal platform teams, allowing faster feedback and efficient structure.
An example would be a managed database platform team that uses the virtual machines of the compute platform team.

Choosing this organizational structure allows for both attractive career opportunities for engineers and an improvement in quality of service, by raising the bar for the organization’s I.T.

The challenges that organizations will face while building a ‘private cloud’

Changes at this scale bring challenges. These challenges are part of the inherent evolution that organizations must go through in order to grow and improve.

Day one

A major question that we must answer is where to start. this isn’t a simple question because of the current investments, ongoing projects, and existing teams that might not be aligned with the concepts we’ve mentioned earlier. Are we supposed to invest additional resources to start? Should we shift teams and engineers to the ‘private cloud’ project?
There isn’t one answer to this question, but deciding on the way that this project should be implemented is crucial to the success of the private cloud.
Another pain that the beginning of our private cloud brings is the initial migration. This is inevitable due to the changes in platforms and technologies that are part of the implementation of our private cloud.

Organizational buy-in

The internal changes that the I.T. teams must make have a great effect on the development teams as well. There is a shift in the responsibilities that development teams need to take to migrate their workloads. The I.T. teams no longer perform application level deployment or management, they provide an API that allows the development teams to perform these tasks independently, this requires additional knowledge from the development teams.

‘Billing’

A technical issue that we might face along the way is how we aggregate and allocate development teams’ resources. Teams are going to use numerous kinds of services, these services are provided by teams that also receive resources from underlying service teams — this makes summarizing the resources used by each project quite complicated.
The reason that this is an issue is that for public cloud providers, usage is billed directly from the user’s credit card, while in the private cloud, this doesn’t exist because both the developers and the cloud providers are part of the same organization.

Summary

To summarize, the cloud enables much faster delivery. To enjoy these benefits, implementation of a private cloud platform requires the correct principles for guidance during the process, along with the right structure to back such a strategy.
Building a private cloud has its challenges. This is part of the journey toward a faster organization