A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.
RMA Group
Journey to the Cloud - Getting Things Straight
Alex Konnaris
One of the greatest takeaways I gained from university was not a perceived passport to greater things but, the ability to approach technical challenges with common sense. This might seem obvious but in a highly technical landscape we often “can’t see the forest for the trees” and miss the opportunity for a simple solution due to over-thinking of the problem. As leaders of IT, we are faced with the challenge of selecting solutions to problems that match the needs of the businesses that we work in, or work with. Most often, we also need to have a keen eye on the costs of those solutions which means keeping the solutions as simple as possible.
How do we follow the KISS methodology of ‘Keep it Simple Stupid’ and select simple solutions to complex problems?
For our journey to the cloud we should start off with getting things straight with our beliefs of what cloud is and what it is not. Due to the terminology used in cloud computing, we will find that there is confusion both internally in our organizations and externally in the market. But what is most important is to establish for ourselves and those around us, a common picture. My perception of cloud will differ from others, as well as having some common ground. First there are the five commonly accepted characteristics where we must be able to:
• Provision resources ourselves without the need for human contact with the vendor, example through a web-based application.
• Access our services over networks, such as the internet and through various computing devices, example desktops or mobilephones.
• Select whether the resources are exclusive to us, in one location or spread over multiple locations and multi-tenant.
• Easily and quickly, scale up and down our resources to meet our requirements or demands.
• Know at any time what resources we are consuming and their health, to an appropriate level of accuracy.
I would add two more criteria to these before we can establish what infrastructure can be called cloud:
• Resiliency is paramount; there must be no single point of failure in our landscape and therefore redundancy in the server, storage, and networks layers.
As leaders of it, we are faced with the challenge of selecting solutions to problems that match the needs of the businesses that we work in, or work with
• Virtualization must be employed to separate the physical hardware from whichever software service layer is being consumed.
Without these five important characteristics and the two additional criteria, it would be all too easy for any service to be labeled or rebranded as cloud, without providing any real cloud benefits.
Now we must tackle the buzz-words, we can start with service models. Some more traditional services have always had service models ranging from Do it Yourself (DIY) to Do it for Me (DIFM), and cloud is no exception:
• Do it Yourself (DIY): very simply, handle everything ourselves – yes, it can be done!
• Infrastructure as a Service (IaaS): Server, Network, Storage, and Operating System (OS) may be handled for us, example Virtual Firewall or Virtual Private Server
• Platform as a Service (PaaS): IaaS is handled for us, plus middleware and runtime may be handled for us, eg Database Server, Application Server, or Web Server
• Software as a Service (SaaS): IaaS and PaaS is handled for us, we just configure and run the applications provided, eg Web-based Application or Mobile Application.
And now perhaps the most difficult definitions, the Deployment Models, where most confusion occurs:
• Private Cloud deployment is the most controversial to define because a more traditional definition is that it cannot be public facing and must be single-tenant. A less traditional definition is that it has isolated and/ or dedicated resources, giving more control over a wide range of settings or layers, especially those related to security. It is considered the most secure but can also be public facing, on or off premise, self-hosted or handled by a 3rd party.
• Public Cloud deployment is generally multi-tenant and accessed over the internet but depending on the architecture, is not necessarily any less secure than Private Cloud.
• Community Cloud deployment can be either Private Cloud or Public Cloud but is shared for a common purpose.
• Hybrid Cloud deployment is any combination of the above.
We now have come clearer definitions but our selection process will not always be easy, there will be other differences in technical sophistication and service level agreements that need considering. We may also need to challenge traditional thinking, example. high-quality Public Cloud solutions will have strong architecture, continuous feature improvements and significant resources in both security and support— these solutions can be as secure, if not more secure, than Private Cloud or DIY.
By now, we should be getting things straight and be better placed for selecting services that are the best fit for our requirements. Selecting solutions where more of the technical work is done for us might sound perfect but don’t be surprised if these bring higher costs. Having said that, we may require more control or customization of our solution(s), require lower costs, and be willing to handle more work ourselves. In terms of security, hopefully, we are also realizing that, if we get things straight, the journey to the cloud does not have to be a leap of faith.
