In the previous blog, we looked the advantages of cloud-based deployments. Today, we’re going to talk about what that really means, including the practical implications, the burden on your team, and risks that are involved.
It was several years ago when I first used the term DevOps in a software context. (In case you forgot, DevOps is a set of practices that automates the processes between software development and IT teams so that they can build, test, and release software faster and more reliably.)
So, when AWS was released about 10 years ago, I was optimistic, idealistic, and definitely unrealistic when I assumed that DevOps problems would never exist. Why? Because of cloud’s presumed unlimited scalability, availability, and guaranteed uptime, all of which would be available at a very low cost (and charged per second).
Now that reality has set in, we know that a single customer with a single action can bring your entire app or website to a screeching halt. Furthermore, the impact extends beyond that one customer to all your other customers on that instance.
The same scenario is true for bugs and updates. In an on-premises situation, you might have one customer down. But in the cloud, everybody is down. This is where the phrase “continuous uptime” has a new meaning.
Downtime. It’s your worst nightmare, in many respects–it can cost you customers, credibility and revenue. You’ve experienced it yourself, when using Google Docs, Skype or Slack. And these outages happen to cloud-based apps, in spite of the fact that those companies have hundreds of people completely dedicated to avoiding downtime.
As you grow larger, security risks will also likely increase. We’re not just talking showing the wrong customer data in a multi-tenancy scenario. (This actually happened to me last week with TicketMaster. While trying to unsubscribe, I was shown someone else’s customer data and was not able to unsubscribe.) But the bigger you become, the more of an interesting target you become to hackers and can be at higher risk for cyberattacks.
Another risk you probably haven’t considered is the “assumed” responsibilities your customer could blame you for. What if you are suddenly responsible from the electricity consumption of your AWS to the browser version and internet connection speed of your customer’s end user? We hear stories everyday of our customers’ users with broken IE browser versions from 2000, expecting our customers to fix it for them!
Then there are new data privacy and compliance regulation headaches. It is becoming a bigger responsibility where you, as an ISV, are now responsible for complying with all local rules and regulations. Take the GDPR in the EU, for example, with “the right to be forgotten” as part of the legislation. This “right to be forgotten” is not just an unsubscribe function–it means you are responsible for ensuring that all user information and all their transactional records are deleted from all your systems, including from your data backup system. Most ISVs don’t understand that even if you are not located in the EU, if one of your customer’s customer is, the GDPR rules must be enforced. Most ISVs don’t want to acknowledge this type of daunting regulation nor acknowledge that more of these global compliance mandates are likely to follow.
All of these factors can have a significant impact on your costs. There are many known examples of where the “Holy Grail” of the Cloud turned out to be huge losses per individual customer instead of the dream of healthy recurring revenue.
To try and mitigate some of the most severe issues we just described, you’re invited to try our QAPaaS stack. We designed it to assure a seamless process for continuous development-to-deployment practices, specifically to help ISVs like you with complex/large applications.
Contact me for a demo or trial.