Every Silver Lining Has Its Cloud
“Cloud first!” is the common cry from CIO offices across the land. All well and good, however, Cloud computing comes in different flavours and the flavour you choose has a significant impact on what that means for your organization. At its most basic, the cloud simply means ‘someone else’s data centre’ but other approaches mean handing over more than just your hardware.
Introduction
“Cloud first!” is the common cry from CIO offices across the land. All well and good, however, ‘Cloud’ computing comes in different flavours and the flavour you choose has a significant impact on what that means for your organization. At its most basic, the cloud simply means “someone else’s data centre” but other approaches mean handing over more than just your hardware.
Entry level ‘Cloud’ can be achieved by migrating from ‘on-premises’ servers to a cloud based hyperscaler. This option is infrastructure as a service ‘IAAS’. This approach is very attractive to companies as it is cheap and flexible. Whilst on the cloud, they can still have control over their systems and what application-level code is running. It is only the underlying hardware that is owned and managed by someone else.
At the other end of the scale there is software as a service (SAAS). In this scenario, the software vendor provides and manages not only the infrastructure but the software as well. So what? You might think, so A LOT! On the upside, you always have the latest code with the newest technology. However, this may come at the cost of a loss of control which some companies may be uncomfortable with.
I am a child of SAP best practice and have spent a lifetime working in controlled environments. To mitigate risk, an IT organization will control the multiple factors:
· What the landscape looks like.
· What changes are made.
· When they are made.
· How they are tested.
· Where their systems and data are located.
Cloud based solutions may not be able to provide the same level of control as the on-premises alternative.
This article aims to highlight some examples of how the on-premises environment provides robustness which may not be possible in the cloud. It also raises some considerations that should go into the mix when choosing your best route forward.
Full System Copies
An application system is more than just code and configuration. It is a complex interaction between these components, the data, the users and their authorizations. Looking at an empty system is like looking at a river without water or wildlife. This reality means that one of the most important tools that IT has in the support of good governance, is the ability to perform “full system copies”.
Whilst some cloud providers will support a full system copy, it is unlikely that you will be able to get all your cloud providers to make a copy at the exact point in time preserving integrity across your copied landscape.
Full system copies have several important uses:
Replica Production Systems For Testing
A common risk-mitigation strategy is to have a very recent copy of production which is used to test any changes, both technically and functionally, before the change is made to production. If something goes wrong when moving updates into the copy system, there is an opportunity to correct the issue. In extremis, the change might be pulled altogether and never reach production.
Regular ‘copy backs’ from production to the test systems mean that any testing is performed against the latest data, the latest users and with their latest authorizations, not just the latest software updates.
Additional Transport Tracks
Should it be necessary, a project specific system can be ‘spun up’ and the transport track be managed in parallel with business as usual. This means that the project can proceed without the risk that code changed by the project can inadvertently be moved to production with a bug-fix.
Experimental systems outside of the transport track
It is very common for organizations to have a ‘sandpit’ environment where architects and developers can trial solution options without changing any of the systems in the core transport track. This allows the optimum solution to be found with no risk.
Back-Ups
Good practice dictates that a back-up will be taken before a major change is performed to a system. Should anything go wrong during that change, the system can be scrapped and rebuilt from the back-up. The back-up is a critical safety net. N.B. back-ups are different from ‘disaster recovery’ which is an important feature in its own right.
Landscape Complexity
Most organizations that I have attended have a five-tier environment (sandbox, development, quality assurance, pre-production and production).
The recommendation for many SAAS cloud options is a two-tier landscape; production and ‘Non-prod’.
This approach may work in a stand-alone and low-change environment. However, where there are numerous teams working on shared developments, the risks increase.
Where there is interaction between on-premises solutions and SAAS solutions, having different landscapes across interacting systems can be hard to manage. (Do you point your single non-prod SAAS system to your development on-premises system where new objects are being created or to the test environment where the data is better?).
It is possible to have more systems in the SAAS landscape, however, this dilutes the value proposition.
Watch Out For Licensing and Authorisations
SAAS non-prod systems might enforce different license types in non-prod to what a user would have in production. This alone can make a test-system copy-back extremely challenging. If user provisioning comes from a third-party tool, there is a risk that this activity would have to be adjusted in the non-prod environment and that would compromise testing.
Software Release Cycles
In the on-premises environment, you can choose which upgrades and patches you want to apply and when. Updating the sandpit environment first means you can trial them without even touching your production track.
With SAAS environments, you get software updates whether you want them or not. It may be possible to opt for an “early-adopter” environment, however, typically this only gives you a fixed period of time to identify issues before the changes hit all your core environments.
Nobody is Perfect
Software vendors test their code before they release it (obviously), but this testing is done in their own environment. This testing does not (and cannot) take into consideration every type of customer use-case or data constellation. If a customer has a situation that the vendor has not anticipated and a bug appears, then it is a matter of raising an incident and hoping that a fix will be provided within the necessary timeframe. There is always a risk that the vendor will say that this usage is not supported, in which case an alternative solution must be found – but not having any control about when the problem hits production means that the pressure is all on you.
Integration and Migration
The modern heterogeneous systems landscape means that, as well as how well a system does its job, a close eye should be kept on how easy it is to integrate with the wider environment: How easy is to get data into? How well does it communicate with other systems during transaction processing? How readily can I get at the data that it generates? How easily can I exit if a better deal comes along? Ensuring you have the right answers to these questions at the outset will save big headaches later on.
Penetration Testing
In an on-premises environment securing your data is comparatively easy. As all the machines are in the basement you can seal them off from the world. Once you have embraced best-of-breed solutions in multiple cloud environments there is a greater potential for vulnerabilities. Unless you want to be leakier than a Bundeswehr Webex, you need to perform your IT Health Checks.
Server Location
Again, with an on-premises set up you know where your data is. Down the stairs, third door on the left. When you go to the cloud, careful attention must be paid to where your service provider hosts its servers. The EU’s GDPR led the charge but there are now numerous countries with their own equivalent to it. The penalties for getting it wrong are eye-watering.
Maturity And Risk
The risk involved is inversely proportional to the maturity of the product. A mature product will have fewer changes and therefore carry less risk. This risk can come in different forms from the number of bugs to changes in vendor direction which leave you with technical debt. This is equally true for on-premises and cloud products but there are many more ‘new kids on the block’ in the Cloud.
Pricing and Costs
One of the key advantages of the cloud is its flexibility. The crude ‘man buy machine, man use machine’ scenario of on-premises infrastructure is replaced by a plethora of payment and service options. The bang for your buck should be much bigger. There is just one word of caution: Multiple services mean multiple services to manage, and the value may be dependent on your ability to size and run systems efficiently. Unlike a machine in the basement which has a light flashing when it is on, Cloud services can be running and eating credits without any obvious indication… until the bill arrives.
Shifting Sands
(Credit: Simon Rotherham)
Another consideration is that the promises made by SAAS vendors have life spans of their own. The User Experience or applications your user base is used to might be improved as part of an upgrade giving your organization an unexpected change management "opportunity". The white listed API's that you have built your integrations to other applications may no longer be white listed or available post upgrade, giving you an "opportunity" to "improve your integration". Those apps you have relied on for the past couple of years may be enhanced to add features you don't require and remove the functionality you do. The "opportunities" are endless!
Conclusion
‘Fail fast’ is a great adage for an internet start-up, however, where established corporate IT systems are concerned, this isn’t necessarily the best approach. Cloud based tools offer many benefits but there are pitfalls and risks.
Different sectors will be prepared to take different levels of risk. Governments, weapons manufacturers, aviation and pharmaceuticals, for example, are likely to be at the more cautious end of the spectrum. Having said this, different business processes within an organization may have different risk tolerances.
Hopefully this article has provided some food for thought and I hope it will be useful when considering your cloud strategy. Do contact me or see our website: https://www.nac-it.com/ for more information.
Please do share your views. If there is anything you think I have missed or have wrong, its not too late to update and improve this.