I recently had an interesting conversation with a new hire in sales this week past, when he challenged me on a relatively recently launched product that I was associated with, and its readiness for “the cloud“.
His point was well made, namely that cloud-based applications have been in popular use and availability for somewhere between ten and twenty years, so, why would anyone build something that isn’t by default able to be deployed on the cloud?
Of course, the same questions were being asked when I started out in the industry, but with somewhat different technology pieces. Why would you choose to build and deploy something on a mainframe or a mini computer when everything points to client server technology?
I think I acquitted myself adequately in response to his questions, but it is probably something worthy of a more elaborate evaluation and discussion without getting to specific about the application itself.
Thoughts of a new generation
Naturally, the first assumption that many of a younger generation, perhaps those born after 1988, is that the cloud is some wonderful panacea for businesses to run their applications and that all things on-premise are bad, potentially evil and expensive and most definitively a step backwards. Why would they not want to deploy in the cloud first?
The reality is a little more complex.
Particularly with the advent of GDPR and the recent hacks and ‘losses’ of data that have been facilitated by cloud-based repositories of data, those who have clung on for dear life to the on-premise model of application deployment, feel somewhat vindicated. This clinging though, may have had more to do with their constrained budgets and relative complexity of on-premise solutions accompanied by a legacy of decades of investment in self-owned and managed on-premise solutions.
This is not to say that on-premise systems are in fact more secure or resilient. It simply states that when the applications and repositories are exposed to the internet and likely managed by faceless offshore third parties. There is the perception that the number of possible data thieves that could attempt to have a run at your systems and test their security might ultimately compromise your data. You only have to look at all the recent malware and ransomware hacks to recognise this is a real present day problem. The number of system services technicians who have commoditized support of applications and don’t get the nuanced importance of a given application, increases business risk exponentially.
Particularly bad, is that many of these would-be data thieves are also faceless and appear to be attacking from even more exotic far away places and demanding to be paid in crypto currency or are just being downright malicious.
What this little deviation then suggests, is that not all data repositories are necessarily well placed to be placed in a cloud accessible location. The choice of on-premise vs. the cloud is sometimes veiled by many other factors that have nothing to do with the technology itself at all but are rooted in other characteristics of the software developing organization or the prospect.
Technically speaking…
An application that is browser based is not, as many would suppose, naturally a candidate for cloud deployment. This may be somewhat of a surprise to hear, but the reason for this is tied into the point made above and several others.
By their nature, applications for deployment to the cloud need to be security hardened and probed for vulnerabilities during the porting process to ensure that the owners and developers of the application can be reassured that the integrity of the application will not be compromised by hackers or miscreants over the web.
Another aspect of applications for the cloud is that they need to support the flavour of the day in terms of capabilities of the leading cloud hosting vendors, namely, the Amazon Web Services (AWS), Microsoft Azure and Google Cloud vendors. It is not unusual to horse trade hosting partners either so this can be an important aspect of how your application needs to work.
On face value these vendors simply provide a way to surface Windows and other kinds of virtual machines, but in reality, what they bring to the table is a complex array of service options, some of which are more cost effective than others.
Applications are generally deployed to the cloud for the purposes of surfacing accessibility, providing a low cost of ownership and the ability to scale according to demand and needs. The latter, in particular, scaling, depends heavily on application architecture, some applications are monolithic in nature and not optimized for horizontal scaling.
Applications that have very specific ‘asks’ in terms of configuration, may offer constrained options in terms of their ability to successfully attain the “cloud-enabled-application” label.
The scope of the application typically covers everything from how the application is deployed, to how it needs to be configured for use, the data repositories that underpin it, how users are provisioned and gain authorization and are authenticated. Then, from a purely administrative stand-point, how is the application metered, monitored, audited and activity, usage and events logged.
Building a checklist
When the application is deployed on the infrastructure of your favorite hosting service, how does it deploy?
Is the application in fact monolithic or made up of discrete and logically compartmentalized elements, engines, services and microservices and logical pieces that can be switched on or off and isolated from other pieces for replacement or upgrade as and when required? All the ‘aa’s come to mind here, Licensing, Software, Platform, Data, Infrastructure, Security and so on.
You can think of this as being not unlike being able to change the components of an aeroplane while it is in flight. While this is not aligned with an older way of building applications it is almost certainly considered the preferred architecture of more contemporary applications that claim to be built for the cloud computing era.
A good cloud architected application typically allows multi-tenancy, but this is not necessarily a prerequisite if the intent is for the application to only ever be used by one enterprise – you can consider though, that a tenant could be as simple as HR vs Sales vs Accounting – although perhaps all part of the same business, each of these business units has their own needs and wants and their own data and possibly even their own operational budgets for systems.
Another element is the concept of ‘elasticity’. As the name suggests, it is a pliable stretchiness in the deployment options. If you want your application to scale, it needs to be able to span multiple virtual machines and possibly even data centre infrastructure for resiliency and performance, it should probably even be designed with non-dedicated ‘serverless’ infrastructure in mind. All of this in support of performance, scaling and high availability as well as reduced risk.
So, as you can tell, there is quite a lot to this whole cloud enabled application business. It is something that during your sales cycle with any vendor, you will want to dig into and determine more about.
Remember that while the application in front of you may be web enabled, you shouldn’t assume that it is ready for or optimized for deployment in the cloud.
About the author
Clinton Jones has experience in international enterprise technology and business process on four continents and has a focus on integrated enterprise business technologies, business change and business transformation. Clinton also serves as a technical consultant on technology and quality management as it relates to data and process management and governance. In past roles, Clinton has worked for Fortune 500 companies and non-profits across the globe.