Home » Blog » Are you a Cloud Native organization?
While looking for your unique way to create a Cloud Native organization, don’t miss the customer value perspective. However, It requires dismantling and disarming some complex transformation disadvantages typical to Cloud Native.
What does it mean to be a Cloud Native company in 2022? What solutions, standards, and practices should this approach consist of?
It would be best to answer each part of this question individually. As some general definitions, you can find them here: https://glossary.cncf.io/. Cloud Native is based on such concepts and ideas as containerization, microservices, APIs, IaS, Continuous Delivery, Continuous Deployment, Continuous Integration, and DevOps, to name a few. Its solution designates like Kubernetes, OpenShift, Docker, Terraform, and many others.
However, besides technical terms and discussions, we have to define this issue in more business-oriented and strategic terms. Thus, the key message for 2022 is:
…to start this organizational, procedural and technological transformation, even though you begin with basic, insufficient assets?
First, the potential of the cloud is virtually unlimited (resources on-demand, automation of software delivery processes, etc.) There’s a significant number of companies planning digital expansion, not restricted by integration limitations. And just about all companies want to be up-to-date with modern tech and benefit from the quick progress of cloud-based solutions and tools that might be applied to current and future business needs and concepts. Cloud solutions are also more secure and versatile – most modern tools are available for the cloud (including open-source, community-driven projects). Cloud Native readiness allows you to benefit from all of these advantages.
Second, it’s almost always cost-effective. However, Cloud Native needs Cloud Awareness. Each company needs to forge its effectiveness plan to avoid the shallows and traps. Mindbox team helped many organizations avoid them.
And last but not least, being Cloud Native equals being environmentally friendly (you don’t use as many resources as you do when building your own Data Centers).
Most of those Cloud Native pros require skills – precisely – continuous skills upgrade and extension. Going Cloud Native is worth it under this important prerequisite. No tool, method, or solution will work without knowledge of how to use them. This is why Mindbox continuously and methodically transfers its cloud know-how and skills to clients as a part of the conducted projects. This attitude also eliminates the fear of cloud vendor-lock. Skills transfer empowers companies to consider and prepare exit or cross-platform migration plans if necessary.
The scale of Cloud Native undertakings varies between companies and depends on several factors (company size, agility, ability to introduce changes, business model, priorities, etc.). Today, most enterprises use the cloud at least in part and often seek to move more and more data and processes there.
One can easily track Cloud Native Computing Foundation definitions updates or check how others describe this approach. Both motivations and experiences may vary among the organizations depending on business context, maturity, why, and how they move towards the Cloud Native approach.
How we went Cloud Native – a very interesting spectrum of such scenarios was presented by experts invited by Mindbox to the “Cloud Native in Enterprise. Why is it not easy to be quick?” panel. The roads to Cloud Native may start and lead in a very individual way…
A good starting point might appear during the planning phase of new business application deployment. “Discussing a new CRM application adoption, we realized that this time we shouldn’t do it the old way. Why not switch to a more flexible and efficient way, why not learn it and make it a new standard of application deployment?” – said Dariusz Szymański from SGB. Step by step – from research and insights, through the adoption of container approach and successful PoC, up to establishing CI/CD pipelines and spreading the entire set of tools and methods across the company. The Bank created and tested an approach that positioned it “very close” to what might be called a “Cloud Native” “Soon, we realized that by adding just a few elements, we may form an internal standard and transform into a Cloud Native organization, exploring capability to create and put newly produced solutions on the public cloud” – added Dariusz Szymański.
Sometimes the impulse comes from the outside. “We discussed the delivery of a new solution with the vendor. It was a bit surprising at first when we heard that our partner plans to deliver it to us as a container. We didn’t show it, however, but quickly analyzed and prepared our environment for container-based architecture delivery and deployment instead,” – said Michał Ślusarczyk, Crédit Agricole. “And there went forth rumors across the market about our capability to work with containers. Soon we had 4 or 5 projects finalized in our pipeline,” – added Michał Ślusarczyk.
Sometimes it appears that you started the road towards Cloud Native months ago, not defining the ultimate goal – a “Cloud Native Organization.” “We decided to migrate from monolithic framework to microservices architecture first. We started to build microservices without Docker containers – simply creating new apps on existing infrastructure. It was a matter of time for us to start thinking about using Kubernetes. But we didn’t really feel under pressure. It was a gradual adoption of Cloud Native approach elements,” – said Piotr Migowski from Play.
The following three scenarios can summarize these experiences described above. Which one reflects your organization’s unique history? Which road would be best for you if you were about to start?
Have you followed one of these scenarios? Or did you find another way of building a Cloud Native organization?
Perhaps it’s easier to name the common obstacles to Cloud Native adoption. Mindbox discovered the way they are correlated and strengthen each other. The examples of such “toxic twins” you shouldn’t disregard are application complexity and legacy infrastructure, security & risk compliance, and Business Complexity. The other important pair of barriers in going Cloud Native is the “Business-IT Misalignment + Skills Gap” duo.
Lack of performance insights, inadequate orchestration across the teams, and lack of team-building lead to IT-Business Misalignment. Isn’t it a major obstacle for a Cloud Native adoption alone? Companies also face a deficit of cloud-related skills, which might result in a stalemate when this deficit is accompanied by a lack of learning and collaboration culture. This may delay or even put the whole progress to a halt.
How often IT-Biz misalignment happens, isn’t it a typical and a “natural state” of this relationship? It seems to be. But “the times they are a-changing”. In a client-centric, digitally-driven business models, traditional constant war or at least smoldering conflict inter-silo scheme turns out to be an inconvenient and ineffective way of pushing things forward.
The idea is to remove this old order and keep business and IT working together and understanding each other. It is possible because we keep lean into business reality: client-centric approach, customer value approach; quite in opposition to what happened to some technological manifestos of change that are losing their consistency and momentum.
Transformation to Cloud Native/DevOps makes it possible to overcome this natural misalignment.
Each of the transformation stages reduces this misalignment by keeping the teams working together and exchanging information regularly. It helps businesses to understand IT and vice versa. Each department has unique needs, challenges, and pains, and it’s crucial for both to understand one another.
Some sets of competencies – especially in management – are necessary to start Cloud Native transformation: general and vertical knowledge of the cloud landscape (public cloud, VM, tools, frameworks, etc.), urge to introduce changes, accompanied by the well-established knowledge of current company infrastructure and its needs/challenges, as well as knowledge of business needs and strategy. Mindbox helps to assemble the necessary set of skills and competencies reflecting the individual transformation plan.
All the skills necessary to start the Native Cloud transformation can be outsourced. Basically, you need people who know how to move your applications/infrastructure/data to Cloud (Cloud architects, developers, database engineers, DevOps engineers, etc.). With Mindbox, you can start assembling your own internal Cloud Native team – a dynamic, vital group of people and skills reflecting the way the company is dealing with a digitally defined economy. It will be essential to have one on board: to understand and manage your position in this world. To eliminate business – IT misalignment through commonly approved and praised means.
We know that the mainly utilized answer to questions regarding the ultimate shape of Cloud Native transformation is: “it depends”. However, Mindbox people know what it depends on. We will help you make the most fitting choices and decisions moving towards your own Cloud Native model.