top of page
Writer's pictureYogesh Jadhav

Untold story of Cloud-native

Cloud has become an integral part of enterprise strategy. The speed of provisioning infrastructure, a la carte of services, flexibility to scale from local to international regions, and with no upfront capex. While all of these sound exciting, there is a fear of having a dependency on a cloud service provider. Customers are wary of sticking to a single cloud service provider and often raise portability concerns. Quite common in the B2B segment. It is not a surprise, if someone coined - Cloud-native strategy to address this problem.





Often suggestions lead to using open source solutions like Kubernetes, GrafanaPrometheusMinio etc. All of these are worth exploring on the platforms that offer limited options like provisioning compute VMs and block storages (or may be for on-premise). But do they help in public cloud services like AWS and GCP. To understand the problem at its core, it is necessary to list what developers and operations teams deal with on a day-to-day basis.



Containers for application services


- Databases


- Queue, messaging, notification


- Block storage


Edge services. 


- Application Logs


- Infrastructure Observability


- Centralized control pane



Public cloud service providers have built isolated yet integrated services. But there is one catch - the configuration. Security controls, and tweaking service parameters require proprietary configuration. But did you notice


- Hawkeye's view of security controls. 


- A unified interface to manage application lifecycle.


- No need to juggle with credentials (Do you struggle with configuring credentials for Minio, Grafana, and Kubernetes dashboard, or maybe whitelist IP address)



Proprietary configuration is considered as a roadblock to portability. This is where Cloud-native is often perceived as a magic wand to port applications across clouds. But those who are veterans in building applications, supporting them in production, and undergoing security audits can relate to a situation that building a cloud-native application requires a deep understanding of the Enterprise ecosystem. It is not a problem that can be solved by installing helm charts, whitelisting IPs, or making people suffer by doing donkey work. Leverage the services offered by your cloud vendor, use everything available to build the best developer, operations, and consumer experience, and also keep your infosec team happy. 



Portability can be addressed by building infrastructure-specific templates and leveraging design patterns/SOLID principles to switch services used in code. Cloud-native principles focus on leveraging cloud services in the best possible manner to build scalable robust applications and not to adopt a mediocre approach to riddle it with spaghetti configuration and SOPs. Migrations don't happen overnight, it requires a methodical approach with a deep understanding of what is best to deliver an unequivocal experience to both internal and external customers.

10 views0 comments

Komentarze


bottom of page