Mrityunjay Kumar, VP of Products at Zenoti, discusses what it takes to build a cloud software…
Cloud software is the new norm for business technology. Hosting providers like Amazon, Microsoft, and Google have made it easier than ever to develop and deploy cloud software. Combined with hosting being cost-effective, it’s no surprise all software development is rapidly moving to the cloud.
The trend reminds me of the early days of Visual Basic in the 1990s. Visual Basic made developing desktop software development easy and accessible with its easy-to-use IDE and programming paradigm. In effect, Visual Basic lowered the skill required to become an entry-level programmer. What it didn’t do however was make someone a good programmer and it wasn’t easy to distinguish a good programmer from an average one. I have seen a similar trend in Android programming. IDE has made it so easy to become an average Android developer so rapidly that it has been hard to find a developer who is really good.
Cloud software seems to be on a similar path. The ease of building and deploying a cloud solution has made it easy for many developers to label themselves as cloud developers. It is hard to distinguish a good cloud developer from an average one. This makes it very hard to hire good developers who can design for cloud.
Like any new paradigm, cloud brings its share of limitations and challenges, and a good cloud developer needs the expertise to anticipate and design around them. In this article, I would like to share what my years of developing and deploying cloud solutions have taught me about building cloud software at scale. I have come to believe that cloud development requires a certain kind of DNA which is hard to find in traditional software developers, but it is possible for developers to unlearn their ‘non-cloud approach’ and re-learn how to develop for the cloud.
Before we go any further, let’s define what I mean by “cloud software”.
There are 2 ways of looking at cloud applications:
At Zenoti, we mean the latter – a software designed for the cloud so as to take advantage of cloud’s capabilities and to work around its limitations. We mean a multi-tenant architecture that supports all customers through a single code base and software version. Leveraging cloud for deployment is an important benefit, however, it is not enough.
Traditionally, software companies would build customized versions of their software for customers and deploy it on cloud. We don’t consider this to be a true enterprise cloud for this discussion because it just moves a local system to a cloud environment instead of taking advantage of cloud capabilities.
To build a scalable, mission-critical system on cloud, a developer needs to use cloud as the platform and design for it. Approaching it like a traditional application software will not do.
There are 3 ways of looking at development that highlight the fundamental differences between cloud and traditional development.
Design for resource elasticity – Resources in the cloud are elastic, you can get as much as you want, for the specific time you want it for. Good cloud software should be designed to scale horizontally – start new instances of the software-on-demand to handle the load better – since this is what cloud is good at. Traditional software is designed to scale vertically – add more processing, memory, and storage to an existing set of machines to handle the load better. Such applications can’t scale well on cloud.
To leverage elasticity, a good cloud software should consist of loosely-coupled components that are stateless. They should also be capable of being independently deployed and upgraded. This allows as many instances of a component to be started on multiple virtual machines when there is a high load on the system. This also ensures that system can take a high load in peak season (like Christmas) without deploying costly resources throughout the year.
Design for multi-tenancy – A cloud software needs to bake multi-tenancy into its architecture so that it can ensure there is absolutely no way for data from one customer to become accessible to another. It can’t rely on developers doing the right thing, Also, partitioning techniques should be thought through at design time so that one customer’s data and resource requirements don’t impact another customer’s requirements.
Security, Availability, and Reliability – Given that a public cloud is accessible to everyone, ensuring security requires the utmost care and must be baked into the system architecture. For example, an API development framework needs to bake-in an access control and role-permissions model.
Since a cloud application aggregates all its users into a single code base and version, the system’s reliability and availability requirements are very high. Any small degradation of service is experienced by all the applications’ users, which means the negative effect is multi-fold. Fault-tolerance and recovery need to be built into the system. Cloud infrastructure can fail too, and a good cloud solution needs to design for redundancy and disaster recovery at scale.
Monitoring – Just building software is not enough, real-time monitoring of the cloud application becomes a key part of the software. The system must incorporate monitoring and an alert system in its design. Engineering needs to think about operations in general and system health monitoring in particular when they develop, otherwise, operations can be costly and error-prone. Building (or integrating) rich toolsets for error logging, error analytics, API and system performance monitoring is required for a good cloud software.
Agility with care – The development team and processes must be agile because when the software runs thousands of customers on a single copy of the code, any problem can quickly multiply 1000X. Defects, escalations, enhancement requests all require that have the ability to respond rapidly. Deployment needs to happen regularly and reliably, in weeks rather than months. However, there is no possibility for a cloud application to escape from the motto of a ‘single version for all customers’. So all feature design and defect fixes need to keep all customers in mind. This sometimes may mean forcing change on an otherwise happy customer, as a change in a workflow is needed for a few customers, but will impact every customer. Product Managers and engineering leads need to be very deliberate in their design, without losing agility.
Data-driven decisions – A good cloud software collects data about every interaction a user has with the software. A strong engineering culture leverages this data in making all engineering decisions. This is the only way to ensure that breaking changes can be safely introduced, unused features can be pruned to avoid further waste, a feature with usability issues can be identified before customer complains about it, and overall make good product decisions.
If you are a developer who is used to a traditional software development and want to be a good cloud developer, be ready to unlearn and re-learn a few things. You need to learn about the capabilities cloud platforms provide, cloud architecture that has been proven to scale by large B2C and B2B companies on cloud, and stop thinking about local systems that scale vertically. You also need to start thinking about deployment and monitoring as part of your job profile, and inculcate the culture of ‘agility with care’ and making data-driven decisions. Based on my experience working with great cloud developers and hiring many of them, I can tell you it is hard to let go of some bad habits, but the re-learning is very rewarding and worth the effort. It is hard to change the DNA but it is not impossible.
What applies to developers, applies to technology companies. Organizations that succeed in building a competency in cloud software are the ones that start with cloud software in their DNA; they hire teams with similar DNA and continue to help individuals unlearn and relearn as new hires come on board.
Do you have the cloud DNA?
COVID-19 has been tough on businesses, and you probably had to close the doors without planning. But now, as you…