Simple ways to identify Cloud Native Software Products
Recently, I have come across a query “how to identify if a software product is cloud native”. Many software product companies advertise their product as “Cloud Native” to get better market proposition nowadays, but it is very confusing for buyer (or user) to understand if the product is really cloud native, as advertised. Many of us believe that only a certified cloud architect can assess this using below well architected framework, but this may not be entirely true.
The purpose of this short article is to give an idea on how to identify a cloud native product in simple and logical ways, without having any technical knowledge about cloud technology. This article will be useful for Project Managers, Program Managers, Application Owner, Delivery Managers, Application Architects, Senior Executives etc, who would like to know this without getting into too much of the technical details.
Below are some of the simple & logical ways to identify cloud native software product based on my learnings during multiple AWS certifications and working closely with software product companies & System Integrators.
- Flexibility in Infrastructure cost vs usage: The most important aspect of cloud native product is flexibility in cost with respect to usage. It means the cost of operation of product will change depending upon high or low usage. So, if you ask your product company (or operation team) about cost of infrastructure, you should expect answer something like this “During peak hours (or day time), cost of Infrastructure is 10 Euro/hour and it reduces to 1 Euro/hour during off-peak hours (or in night)”. This means the product is cloud native and it uses flexibility or elasticity of cloud technology. We do not need any technical knowledge to ask this query and any operational team member can answer this. If your cloud native product comes with lot of hardware recommendations and the cost of infrastructure doesn't change flexibly (based on usage load or time), you may understand that the product is not cloud native.
- Ease of creating or shutting down environments: It is well known fact that every organisation needs multiple environments depending upon their policy, roadmap, number of teams, releases, testing cycles etc. You may ask a simple query to your team “how much time does it takes to create or shut down an environment (development or test or production) and how easy it is”. If your team answers that this activity is very easy (no/minimal manual intervention) and takes couple of min/hours, you may say that you are using a cloud native product. This is also useful in saving costs by shutting down non-critical environments and helpful to quickly recover during disaster.
- How much is usage of Infrastructure: You may ask your team to share the usage of infrastructure/components of your applications. If the average usage is less than 30–40%, it means that you are paying 60-70% of your money for unused infrastructure which is actually a waste. The cloud native product should use infrastructure to maximum extent (average usage should be in range of 50–70%). We do not need any cloud knowledge to understand this wastage of money and can use this to assess our cloud native product.
- Downtime: This is the most important benefit of cloud native product for business. If cloud native product takes downtime of couple of hours during any planned deployments, it means that there is no benefit to business even after spending huge money on cloud transformation. So, cloud native product should use appropriate deployment strategy to avoid downtime (or to minimize it to couple of minutes), otherwise no real value of cloud native product is getting passed to business. This will lead to various unpleasant discussions around return on investment, business case failure, loss of revenue etc.
- Ease of Upgrades: This is also one of important parameters as there is very fast development in cloud technology and hence frequent upgrades are necessary. If a product doesn’t have easy way to upgrade its underlying infra/components/applications, the business will have higher downtime per year and it will lead to loss of revenue.
- Ease of removal of Security vulnerabilities: The cloud native products pose greater security risk due to its inherent design and hence there should be a defined approach to handle the security vulnerabilities in a timely & agile way. This is very important to avoid legal claims and loss of reputation. So, if there is undefined and untimely approach for removal of security risks, you may understand that product is not cloud native. The timeline to remove any critical and high security vulnerabilities should generally be around 1 month and 3 months respectively (depends also on nature of business). One of most common excuse from product company on this is “This risk is coming due to 3rd Party and we can not fix it!!”. We need to understand that it is responsibility of product development team to use latest version of 3rd party libraries (or change it, if needed) to ensure there is no risk to business/customers, else we all will be out of business very soon and may not need any cloud native insecure product due to legal implications.
- Observability: There is a well-known saying “if you can’t measure something, you will not be able to improve it”. This is true for cloud native product also. So, if your cloud native product is not having detailed in-built observability mechanism, you may understand the trouble in operation. It will finally lead to violation of business KPIs and dissatisfaction from business/customers.
- Fail-Safe Design: This is widely used term in aircraft industry and means that even if there is failure in one component, it should be safe to operate due to redundancy in design. This approach of fail-safe design increases reliability and ensures the continued operation even in worst case situation. So, if your cloud native product doesnt give this feature and you experience frequent unplanned downtime/outage, it means the product is not cloud native. One of the easiest way to understand this is to open your architecture diagram and ask this question “What will happen if this component fails” repeatedly till you cover every component in your architecture diagram. You should expect to hear terms like Auto healing, auto correction, multi-zone, high availability, serverless, managed services etc from your technical team/architects while they explain how reliable a product is. If you don’t hear these terms, you will be able to know that product still uses “Legacy” design principles.
- Performance: If your cloud native product doesn’t give similar performance during off-peak and peak usage, it means there is inherent flaw in design of the product. There should not be costly hardware recommendations (which is fixed in nature) to achieve performance objectives before you plan performance testing. In fact, a well designed cloud native product will scale up/down without any manual intervention and will perform consistently at any load because the necessary hardware will be added as per the pre-defined operational thresholds at runtime.
- Response time: If your cloud native product takes many seconds to respond to a simple business operation, there is no need to go through any other criteria. This is the most basic criteria and easily explains that product is not at all cloud native. The expectation of a cloud native product is to complete an operation in few hundreds of milli-seconds (around 200–300 milli seconds max, you may add network latency on top of this). Most of cloud infrastrucure responds within double digit of milli-seconds and business operation should also be optimised to perform on similar level. If you get response time of more than 1 second for any simple business operation, this should be the only criteria to reject the product as cloud native, even if it satisfies other parameters mentioned above. We need to understand that customer doesn’t care whether our product is cloud native or how much investment is done in cloud transformation, they will promptly move to other competitors who provide lower waiting time for similar business operation.
Overall, you may not need excellent knowldge of cloud technology to understand if a product is really cloud native. These logical questions can definitely help you to get an overview of quality of cloud native products and to take informed decisions based on your specific line of business. Of course, there are better and detailed ways to understand the architecture of product as per “Pillars of Well Architected Framework”, but you may need a cloud architect to go through the assessment in details and it may be time consuming. My recommendation is to use these logical ways to quickly assess the cloud native products initially and then get into detailed assessment only if the product satisfies most of the criteria mentioned in this article.
If you are still deciding to buy any cloud native product, you may use these queries as first level of checklist during any customer references to get a fair idea about the product.
Thank you for reading this short article, hope you liked it. You may like/subscribe if any of my articles helped you to increase your understanding about cloud technology in a better way.
Happy learning!!
References:
