Proof of Concept: A waste of time and money?
- November 07, 2018
Very often, moving into a new field brings more questions than answers.
Thus enters the cloud vendor. The IT team, without much cloud experience, sits in a room while sales and an architect from the cloud vendor present a bunch of slides, detailing how everything will get better once the company buys the vendor’s product.
All those unicorns and rainbows sound great while everyone is in the meeting room, but afterwards doubts begin to plague both management and the IT team. How good is this approach, really? Is it going to meet our requirements? Are we going to be able to manage it? How are our internal customers going to feel about it?
And the big one: should we go ahead with it?
What the team really needs at this point is a proof of concept (PoC). But you have to do it right.
A cloud PoC should be a cloud built on a very small scale, but with all important components in place, so the admin and development teams can see -- and more importantly actually, try out -- the cloud. Developers can see how to onboard an application app or two. Tests can be conducted for situations such as instance component failure. Overall the cost is moderate, especially compared to a large deployment, which will require a large financial commitment.
It's important that the PoC is not only created appropriately, but deliberately used. Nobody is served if the PoC cloud is just set up and demoed to management; that can be achieved much easier by demoing the vendor’s cloud environment.
The truth usually lies somewhere in between.
At Mirantis, we recommend a reasonable approach to PoC setup. The servers don’t have to be new or top-of-the-line, but they should be of reasonable specifications, and if they are not new, well tested if--especially if the reason for retiring them is not known. They must also match the requirements from the Mirantis MCP hardware recommendation list. If in doubt about specifications, talking to the vendor is much easier than deploying and then finding out things don’t work.
Preparing the hardware involves ensuring that it is racked and stacked, tested and accessible via IPMI. The customer must also provide for remote access for offsite deployment engineers or a usable workspace for onsite engineers as necessary.
All teams must communicate from the very beginning, and ideally the customer IT crew will be part of the deployment as it happens, at least to the degree their own work schedule allows. After all, if the PoC is successful, they are the ones who will be working with the resulting production cloud.
Engineers can then use the model, together with the foundation node, to deploy all components of the cloud onto the rest of the hardware. Any changes are first made to the model and then deployed in turn, so that the model is always an accurate representation of the actual infrastructure. This is how it works on the large-scale production cloud, so it must work like this on the small scale, too.
Unlike in production, however, the PoC could makes it possible to do destructive testing, enabling the deployment team to show how failed parts of cloud can be rebuilt in short order from the model. Tests should include not only cloud functionality and verification that all requirements have been met, but should also show all involved parties--from administrators to developers to management--how everything works together in real life.
A proof of concept is not a demo conducted by a single person, but a real world, albeit small, cloud environment, showcasing how the subsequent large deployment will ultimately be handled.
Meanwhile, the PoC cloud is still sitting there. Should you go ahead and dismantle it? I say that’s a waste. Here you have a small cloud that has all of the functionality you expect from your production cloud. The work and effort to create it has been spent, so let’s put it to good use.
Option one is to integrate it into the production environment as staging cloud--after all, you need one anyway! Making use of the PoC cloud means you don’t have to provide extra hardware and effort to set up staging. Changes to production can be tested properly, before they are implemented in production. (This is specifically how the MCP workflow has been designed.)
Option two is to have the deployment team create a new staging cloud together with the production environment, and grow the PoC cloud to a test and development environment. The admin team and the developers should already have an established workflow for this cloud from their time testing the PoC. Keys are in place, and software can be deployed using established methodology.
But which option should you choose? It depends on the hardware.
If the hardware for the PoC is similar to what is being deployed in production, it makes sense to consider the staging option, but if the PoC has been built from well maintained, but older hardware, test/dev should be your first choice. Of course the dev cloud will have to have considerably more compute resources than the tiny PoC cloud, but we can use this as a welcome opportunity to scale out a cloud environment and encounter the workflow and challenges posed by scaling out an environment and overcome them in a safe and low-pressure environment.
One thing a PoC is not is a waste of time and money. Even in the rare cases where a PoC fails, it is much better to experience that failure with a relatively small financial outlay rather than have a production-ready but unsuitable cloud sitting around, burning money.
And if it is a success, the experience gained, the workflow mechanics learned and the development integration tested will prove invaluable when the production environment is built and goes online.
Besides, as the PoC cloud is repurposed, instead of building a test/dev or staging cloud after the fact, the net financial outlay is in essence minimal.
The Customer’s Dilemma
Consider, for example, a company that has ample experience with traditional IT, but is encountering the limitations of the traditional approach and wants to consider moving to cloud computing.Thus enters the cloud vendor. The IT team, without much cloud experience, sits in a room while sales and an architect from the cloud vendor present a bunch of slides, detailing how everything will get better once the company buys the vendor’s product.
All those unicorns and rainbows sound great while everyone is in the meeting room, but afterwards doubts begin to plague both management and the IT team. How good is this approach, really? Is it going to meet our requirements? Are we going to be able to manage it? How are our internal customers going to feel about it?
And the big one: should we go ahead with it?
What the team really needs at this point is a proof of concept (PoC). But you have to do it right.
What is this PoC thing anyway?
A proof of concept is a crucial part of any cloud project, and it shouldn’t be slapped together just to tick off a checkbox. A PoC can only be successful if both parties agree to put real effort into creating--on the part of the vendor, and examining and testing--on the part of the IT staff--the PoC cloud.A cloud PoC should be a cloud built on a very small scale, but with all important components in place, so the admin and development teams can see -- and more importantly actually, try out -- the cloud. Developers can see how to onboard an application app or two. Tests can be conducted for situations such as instance component failure. Overall the cost is moderate, especially compared to a large deployment, which will require a large financial commitment.
It's important that the PoC is not only created appropriately, but deliberately used. Nobody is served if the PoC cloud is just set up and demoed to management; that can be achieved much easier by demoing the vendor’s cloud environment.
Prerequisites
While the need for a PoC is rarely challenged, conflict over how it is created is common. Customers often think it can be built with three moldy servers from the back room, while vendors want all new hardware.The truth usually lies somewhere in between.
At Mirantis, we recommend a reasonable approach to PoC setup. The servers don’t have to be new or top-of-the-line, but they should be of reasonable specifications, and if they are not new, well tested if--especially if the reason for retiring them is not known. They must also match the requirements from the Mirantis MCP hardware recommendation list. If in doubt about specifications, talking to the vendor is much easier than deploying and then finding out things don’t work.
Preparing the hardware involves ensuring that it is racked and stacked, tested and accessible via IPMI. The customer must also provide for remote access for offsite deployment engineers or a usable workspace for onsite engineers as necessary.
All teams must communicate from the very beginning, and ideally the customer IT crew will be part of the deployment as it happens, at least to the degree their own work schedule allows. After all, if the PoC is successful, they are the ones who will be working with the resulting production cloud.
Deployment and Testing
Once everything is in place, the deployment team starts building. For Mirantis Cloud Platform (MCP), the engineers will build a software model PoC cloud in code. Once finished, this model is a complete representation of the PoC cloud.Engineers can then use the model, together with the foundation node, to deploy all components of the cloud onto the rest of the hardware. Any changes are first made to the model and then deployed in turn, so that the model is always an accurate representation of the actual infrastructure. This is how it works on the large-scale production cloud, so it must work like this on the small scale, too.
Unlike in production, however, the PoC could makes it possible to do destructive testing, enabling the deployment team to show how failed parts of cloud can be rebuilt in short order from the model. Tests should include not only cloud functionality and verification that all requirements have been met, but should also show all involved parties--from administrators to developers to management--how everything works together in real life.
A proof of concept is not a demo conducted by a single person, but a real world, albeit small, cloud environment, showcasing how the subsequent large deployment will ultimately be handled.
The PoC is complete. What now?
The PoC was a success, and the deployment team is hard at work on the large-scale cloud that was designed using the knowledge gained during the PoC.Meanwhile, the PoC cloud is still sitting there. Should you go ahead and dismantle it? I say that’s a waste. Here you have a small cloud that has all of the functionality you expect from your production cloud. The work and effort to create it has been spent, so let’s put it to good use.
Option one is to integrate it into the production environment as staging cloud--after all, you need one anyway! Making use of the PoC cloud means you don’t have to provide extra hardware and effort to set up staging. Changes to production can be tested properly, before they are implemented in production. (This is specifically how the MCP workflow has been designed.)
Option two is to have the deployment team create a new staging cloud together with the production environment, and grow the PoC cloud to a test and development environment. The admin team and the developers should already have an established workflow for this cloud from their time testing the PoC. Keys are in place, and software can be deployed using established methodology.
But which option should you choose? It depends on the hardware.
If the hardware for the PoC is similar to what is being deployed in production, it makes sense to consider the staging option, but if the PoC has been built from well maintained, but older hardware, test/dev should be your first choice. Of course the dev cloud will have to have considerably more compute resources than the tiny PoC cloud, but we can use this as a welcome opportunity to scale out a cloud environment and encounter the workflow and challenges posed by scaling out an environment and overcome them in a safe and low-pressure environment.
Do I need a PoC?
Not all customers need to do a proof of concept. Those who already have some cloud experience often opt to jump into production right away. It is not a bad choice, but in many cases even an experienced team can learn and test useful things in the PoC process.One thing a PoC is not is a waste of time and money. Even in the rare cases where a PoC fails, it is much better to experience that failure with a relatively small financial outlay rather than have a production-ready but unsuitable cloud sitting around, burning money.
And if it is a success, the experience gained, the workflow mechanics learned and the development integration tested will prove invaluable when the production environment is built and goes online.
Besides, as the PoC cloud is repurposed, instead of building a test/dev or staging cloud after the fact, the net financial outlay is in essence minimal.
