Lab environments are a great thing. We can test new products on a small scale platform and demonstrate them as a proof of concept (PoC).
Like many of my fellow bloggers I write down my lab experience in little blog posts that I share with the community. I regularly read blogs and tutorials to keep myself informed about new products and techniques. There is hardly a topic in the field of virtualization that someone hasn’t written something about at some point. This is invaluable, as it gives you a quick introduction to what is usually a complex subject.
When reading my (and other) blog posts, you may get the impression that the described setup procedure follows the simple skip-skip-finish principle. In other words, accept the default values, click three times and the installation is complete. This might be true in the lab, but a real life deployment is miles away from a lab setup.
In the lab many things are simplified to the max according to the KISS principle (keep it simple and stupid). Some of the methods used are not necessarily in compliance with the manufacturer’s recommendations, or are outright forbidden in productive environments.
This means : Having read a tutorial by my favorite blogger [insert name here] does not enable me to transfer what I have learned 1:1 to a real project.
I have had several discussions about this in preliminary project meetings. People have asked why the planning phase takes so much time. They said that (they thought) the product was totally easy to install, as you can read on [insert name here]’s blog.
As a blogger and lab user, I know how to view these posts. They are to be understood as a quick introduction and an easy to understand overview of a new technology. This has very little to do with real world deployments. In this posting, I would like to point this out with the help of a few examples:
Keep it simple and stupid
In the lab or in blog articles, the aim is to break down a complex issue to a comprehensible minimum. For good reason, many extras and details are disregarded.
Passwords
A single and simple password for all services and accounts. What is a total no-go in real life, is practiced by most of us in the lab environment. Why not? One simple password for everything. After all, we are not dealing with a security-critical application. A lab does not contain any sensitive or otherwise interesting information. If it were compromised (what a stupid idea), you would delete it completely and set it up again.
By the way, I would bet that in most lab environments the password VMware1! is used as default. 😉
Firewall
The KISS principle applies again with regard to access control. We allow all access from everywhere in the lab. After all, it’s about proof of concept and not about security (unless you’re testing a firewall).
In real projects, the firewall can become a real challenge. A single port between two VLANs that was accidentally not opened can bring entire deployments to their knees. This is followed by lengthy troubleshooting until the cause is finally found.
Certificates
Self-signed certificates are perfectly fine in the lab. The warning in the browser does not bother and a man-in-the-middle attack is not to be worried about.
In the real world, this looks completely different. There, trusted certification authorities (CA) of the company must be involved. Some CA solutions do not support certificate signing requests (CSR). Generated certificates must then be exported and re-imported in the appropriate format. A funny game.
Redundancy
A singular uplink or a single path to the storage device is usually sufficient for a test. The KISS principle again. What’s the point of uplink redundancy if I only have one switch available anyway?
In productive environments, redundancy is an absolute must. There may not be a single point of failure (SPOF). To achieve this, redundant components are indispensable in each layer. This applies to data, hardware components, power supply, cooling, multipathing for data paths and network connections, etc. This requirement will inevitably increase the complexity of a system.
This complexity brings further challenges in its wake. In the SAN area, redundant storage networks (fabrics) are necessary. In the LAN, aspects such as spine-leaf architecture, link aggregation, spanning tree protocol or routing must be taken into account.
AMPRS
Availability or uptime is closely related to the redundancy discussed earlier. In the lab, the issue is completely insignificant. The system is booted for testing and if there is a technical problem, it is shut down for an indefinite period and repaired.
In production systems, the RAMPS or AMPRS is considered the basis for conceptual design. The acronym stands for:
- Availability
- Manageability
- Performance
- Recoverability
- Security
All five conceptual planning aspects play no role, or at least a subordinate role, in the average lab.
Not supported
I have a lot of flexibility in the lab. Basically, everything that works somehow is allowed. I can use hardware components that are not on the VMware HCL. For example, a budget SSD as a vSAN cache device. This is not a problem in the Lab, since reduced throughput or shorter lifespan are not a real problem.
In production environments, these are critical design aspects. Not only do I have to follow the HCL strictly, but I also have to plan ahead so that the new infrastructure will perform as required.
The Lab as a preparatory step for the project
Even if the laboratory greatly shortens paths and simplifies requirements to a maximum, it is still an important tool for proof of concept (PoC) deployments. Potential pitfalls can be identified at an early stage and workarounds can be found.
Blogposts are also a valuable resource in problem solving and help us in learning from the other people’ experiences.
A good approach is to use information from blogs as the starting point for your own PoC in the lab. With the knowledge and experience gained from these, you are well prepared for the special challenges of real projects.