If there’s any area where the field of computing technology excels, it’s in creating new terminology. And this is especially true when it comes to vendors who sell such technology. Unfortunately, when a business enters into the equation, exact definitions of computing terminology tend to get a bit, well, fuzzy. Cloud-native software is a good example of this because not every solution offering that a vendor says is cloud-native is actually cloud-native. We’ve discussed the topic of cloud-native solutions several times in the past here on TechGenix (see here and more recently here). But from talking with both business customers and software vendors, I still get the impression that not everyone has a clear grasp of what the term cloud-native means. So, to help us understand this terminology better and to gain insight into how one can determine whether a vendor may be hyping their offering to you just a wee bit, I asked Babak Varjavandi, CEO of Nakisa, to share some thoughts on this subject.
Cloud-native software: After the pandemic
I began by asking why cloud solutions are such a big deal today in our (hopefully soon) post-COVID world. “The pandemic has worsened the shortage of technology talent globally,” Babak replied. “More companies are relying on technology for their everyday work. With the higher need for technology in the workplace across all industries, the expertise and skills needed to perform in these roles are becoming increasingly difficult to find. As a result, companies are relying on software solutions and implementing cloud technology to keep systems moving with little-to-no supervision and to automate previously manual tasks. However, not all cloud solutions will help to alleviate the technology talent shortage. Many cloud solutions are simply on-premises or monolithic solutions that have been moved over to the cloud. Therefore they can’t provide the many advantages that a true cloud-native application can bring. If a software is cloud-native, it means that it was built to function and run on the cloud from its inception. For example, since cloud solutions are not behind a customers’ firewall, they become a favorite target for hackers to break into.”
Many cloud solutions are simply on-premises or monolithic solutions that have been moved over to the cloud. Therefore they can’t provide the many advantages that a true cloud-native application can bring.
If cloud-native solutions are the best way going forward, then there needs to be solid processes and tools for developing them. Babak agrees and says, “The good news is that there are best practices available for building a successful cloud-native solution. These best practices, such as microservices and containers and adopting CI/CD process, will allow software vendors to bring innovation faster to their clients in a secure and scalable environment. However, many legacy software vendors are struggling since building a cloud-native application requires a fundamental shift in the design and delivery of their software and requires different expertise than what’s needed to build their on-premises solution. Overall, cloud-native software will offer an easy and seamless transition to more advanced technology, while alleviating the stressors of the technology talent shortage for companies.”
So, if your business is looking for cloud-native software that can meet its present needs, how should one proceed? “For companies that turn to cloud solutions to streamline processes, they must ask vendors if their software is truly cloud-native, or if is it just hosted on the cloud. While these two seem to be similar,” Babak adds, “they are very different.”
Buyer beware
And there in my mind is the crux of the matter: caveat emptor (buyer beware)! If you ask a software vendor if their solution is cloud-native and respond affirmatively, how can you be sure? “Most companies evaluate functionalities that vendors provide,” explains Babak. “However, there must be a specific review of their system architecture to ensure a solution is truly cloud-native. A cloud-native solution is based on microservices where each individual service can be designed, tested, deployed, or replaced without affecting the others. And each service is monitored and can scale separately as the usage of the microservice increases, potentially providing unlimited scalability and failovers for customers. A review of the vendor’s system architecture would help companies identify a true cloud-native solution.”
Some businesses, however, may not feel they have enough in-house expertise to evaluate the architecture of a vendor’s software offering, so I asked him if he could explain in more detail what to look for and he graciously obliged with some diagrams to illustrate.
“As I’ve mentioned,” says Babak, “cloud-native applications can naturally scale depending on customer workload. Cloud-native applications achieve this by implementing robust microservices architecture. The important question is, how is it different from the traditional application? Because for a user, they still go to bowers (or local native client or mobile app) and interact with the application.
“The devil is in the details. Let’s see what happens when the user interacts with the application. In a monolithic application, the request goes to the application. The application is installed on a dedicated server with a database or any other storage.
“As more users use the application, the system gets stressed and in order to accommodate more users, the system must be stopped and resources are added. But eventually, we reach the physical limit of the resources, and scalability becomes a big issue:
“Next step in evolution is to have load-balanced applications. Load balanced monolithic systems solve the availability problem, but upgrades and corrections (bug fixes) cause major downtimes:
Microservices to the rescue
“Microservices architecture solves all of these problems. Microservices are mini-applications that work together using best industry standards like RESTful APIs and asynchronous communication, using state-of-the-art tools like Kubernetes, Kafka, Istio, Prometheus, and Helm, using powerful techniques like canary deployment, circuit breaking, stateless components, micro-frontends, chaos engineering, and immutable infrastructure:
“Microservices scale horizontally, never needing a system restart. They are lightweight, so upgrades and corrections are very fast and seamless. Also, the system does not have to go down because while upgrading, old services can keep running. Furthermore, microservices add networking complexity. How do they share data between microservices, how is security information passed, how long does each service takes, how do you monitor each service resource usage (CPU, memory, etc.)? A service mesh, like Istio, is a way to control how different microservices interact with one another, and a monitoring tool such as Prometheus lets you monitor every resource used by the network.
“We have not talked in detail about database scalability, but from the figure above, it is clear that each microservice holds its own DB. This decomposes the DB into smaller clusters. As a result, DB becomes extremely resilient and distributed too. We discussed the scalability aspect of cloud-native applications, but there are many other benefits like effective monitoring, self-healing, increased security, quality regression prevention, increase in innovation speed, and robust backup/recovery that naturally stems from microservice architecture. In turn, cloud-native applications are observable, resilient, and manageable. This directly increases the quality of applications and the customer experience.”
I’m sure that Babak’s above explanation and diagrams will be helpful for those of our readers whose business can benefit from the advantages that true cloud-native solutions can provide them with. As a final token of thanks to him for giving us some of his valuable time, I asked Babek to tell us briefly about the cloud-native offering of his own company.
“Nakisa’s Lease Accounting and Real Estate solution consists of over 60 microservices. As an example, vendor management and currency management are separate microservices. Vendor management has its own micro-frontend that is called by the end-user, while currency management is only an internal microservice that provides different currency to other microservices. Remember each microservice runs independently in its own container, which is maintained in a Kubernetes pod. A pod can loosely be compared to a server; it is the smallest, most basic deployable object in Kubernetes. There is no question of the benefits that microservices architecture brings, especially for enterprise business-critical applications. However, it should also be noted that microservices also brings many complexities that are foreign to legacy developers that are used to building monolith application. Nakisa uses the 12-factor app methodology to build each microservice. As part of our CI/CD, each change in code triggers an automated build-and-test sequence to ensure that each microservice meets the 12-factor app methodology.”
Sounds pretty cloud-native to me!
Featured image: Shutterstock
