So, let’s start by taking a closer look at what we mean when we talk about a cloud-native architecture – this typically revolves around two topics:
But, the one element that is very often overlooked in this discussion is the application runtime environment – the container runtime, the data stores as well as messaging and application integration infrastructure. This layer holds quite some complexity and the effort for maintaining this is often underestimated. You have to deal with high availability, scalability, security and data protection, backup and disaster recovery, as well as continuous patching and upgrading of the components. To operate such an environment at scale requires quite a sophisticated skillset and a lot of experience. Furthermore, the pace of innovation of the runtime environment is accelerating, so your team will need to be fleet-footed to cope with this.
While a private cloud can probably provide the networking, compute and storage infrastructure in an efficient way, most companies will fail when trying to leverage a private cloud to deliver the latest application runtime environments and data stores efficiently at scale.
The public cloud provides a solution for this through managed services for all kinds of application runtime environments, data stores, and middleware functions. For example, the Amazon Elastic Container Service for Kubernetes provides a fully managed Kubernetes cluster in the cloud, the Amazon RDS is a fully managed relational database, and the Amazon Simple Queuing Service provides a completely serverless messaging environment. In such a setup the public cloud provider relieves you of most of the non-functional complexities involved with operating your application. You are no longer operating the application runtime environment, but you are consuming it as a service in the public cloud.
When it comes to the speed of innovation with which new technology is created, the private cloud will fail in keeping up with the pace of the major public cloud providers. The public cloud will allow you to focus on what really makes a difference for your customers – the user experience and the features and functions – and frees more time and resources for innovation, rather than managing backend systems..
Having explored the benefits of the public cloud, let’s take a closer look at what it means for an application to be truly cloud-native.
A truly cloud-native application is built to run on managed services in the public cloud. It does not require any simple compute services and VMs and is purely based on cloud services.
The picture below shows the solution architecture of Infonova SaaS BSS – a pre-integrated, complete-suite BSS delivered as SaaS. With its cloud-native containerized micro-services and open API architecture, all incoming traffic is routed through the API Gateway, the managed Kubernetes service orchestrates the applications that are delivered as containers; the data is stored in the managed relational database service as well as the Elasticsearch service; and the queuing service provides the messaging infrastructure for asynchronous processes. The deployment across multiple availability zones makes sure that the application meets high availability requirements.
This future-proof cloud-native architecture allows our customers to benefit from the robustness and security as well as the scalability and elasticity of the public cloud. It enables us to operate the solution much more efficiently and deliver our services at a better price to our customers. Ultimately it helps CSPs reduce costs, increase automation, accelerate speed to market, while cutting heavy operational and maintenance workload. And as SaaS, it grows as their business grows.
