March 9th, 2022
6 min
Daniel MüllerInnovating with MACH (Part 3): The Why and How of Going Cloud-Native
Through my previous articles, we looked at why business capabilities should determine microservices and the business value of being truly API-first. This brings us to how companies are modernising through cloud-native technologies. You probably know the jargon; we’ll try to focus on how to use the cloud and not on the cloud services themselves.
What is Cloud-Native Development?
Cloud-native development is agile, behaviour-driven development, using cloud services in whichever way makes sense for an organisation and its culture. The goal is to get businesses wherever they need to go. Scalable applications running in modern, dynamic environments using containers and declarative APIs, preferably orchestrated by Kubernetes. The building blocks use a microservice model, a serverless platform, and the DevOps operating model.
Why should Business drive Cloud-Native Development?
We advise our customers to get rid of a purely IT-driven mindset and always bring a business perspective to each phase of going cloud-native, from planning to decision-making. IT may have the best understanding of the technical implementation. But that doesn’t necessarily include an overall picture of the various functions of an organisation. Try to get into a mode of “Business-impact first” thinking – because today’s technology has no limits, and almost anything that can be dreamt of can be done with a big enough wallet. But there is always a cost risk, so the focus should be on the business value. Any cloud solution should be tailored to the organisation’s background processes and future plans. Keep the end-user’s point of view and the customer experience in mind.
Three Key Business Benefits of Becoming Cloud-Native
Better Customer Experience with DevOps
The “fail fast, fix fast” mantra of DevOps, and the short cycles of CI/CD mean that more robust testing can occur before integrating into the whole application. DevOps practices help organisations deliver apps that require frequent updates in a reliable, seamless, and resource-efficient manner. Even if you are not fundamentally a ‘tech’ company, you can spend more time focusing on development and less worrying about what happens after the update goes live.
Improved Business Continuity with Resilient Cloud Architecture
Going cloud-native is almost always a surefire remedy for the downtime and unavailable services. At Mindcurv, we tell our customers that cloud-native development is about having a competitive advantage and keeping operations lean enough to survive whatever turn the market takes. Employees, products, or services aren’t tied down to physical locations by going the MACH route. With cloud-native, you enable integrated and automated backups, better data security, unifying processes on a single interface, and improving visibility.
Increased Ability to Meet Shifting Market Demands
COVID showed us that agility and speed are critical instruments in turbulent or hypercompetitive markets. Businesses that thrived during the COVID period could respond in hours to sudden changes, meet new customer demands, and deliver what they expected. If you spot an opportunity a moment before a competitor, putting you in a position to snag a key market position, you better have a cloud-native system.
Where does Kubernetes Fit?
Kubernetes comes into the picture if you build a solution based on containers at scale. You need to deploy and scale multiple containers, operate numerous services, and scale them up and down. Here, orchestration becomes crucial, and Kubernetes is the tool of choice if you need it. We often see that having Kubernetes at the core is a good starting point for going cloud-native and reaping its fruits. But are you using Kubernetes for the right reasons? Try to answer the following questions to find out:
- Why are you using Kubernetes? ( “Because everybody else is” is not a good answer!)
- How does it help you to deliver on your user needs?
- Is it a good tool, practice, or method to deliver on a particular user’s needs in this solution? (There’s no “one size fits it all!”)
How to Succeed with Cloud-native?
If you already have years or decades’ worth of background in traditional IT projects and application development, the transition to the cloud will not happen overnight. This needs sweeping change at every level, where you challenge IT, business models, and people’s ways of working. DevOps, agile, and end-to-end development should replace traditional development to get the most out of the cloud. You also need to understand how scale affects costs. I have a 4-phase checklist for you to get started:
Phase 1: Baseline
Kubernetes, managed databases, and a managed message bus are all you need to get started with cloud-native. The idea would be for your development teams to get used to the environment, CI/CD processes, etc. Remember, old habits don’t change overnight. So we make sure to give your team enough space and elbow room to figure out what methodologies work best for them.
Phase 2: Self-services via Templates
We would introduce platform templates managed by a central platform team for spinning up databases, lambdas, etc., in a self-service model. This will be crucial to scaling quickly in the future. Additionally, you must understand that some teams will always stay in phase one simply because a robust Kubernetes environment is all they need. So phase 2 would also be about providing these phase 1 teams with templates for the future.
Phase 3: Setting up Landing Zones
A landing zone is a pre-configured cloud environment – provisioned through code – with a standard set of secured cloud infrastructure, policies, best practices, guidelines, and centrally managed services. A good landing zone would have taken care of security, governance, & compliance, standardised tenancy, identity and access management, and networking. We also set up these landing zones with budgets and access to only certain functionalities, and we would support the infrastructure needs in the initial days. The goal is to limit responsibilities and ensure a smooth transition to a stage where the teams own the infrastructure and get used to deploying and monitoring.
Phase 4: Autonomy & Access for Development Teams
In the final phase of going cloud-native, development teams would have direct access to a defined cloud functionalities and have higher budgets, fixed and monitored by the finance team via automated tooling. Just think of the risks for a moment of starting with phase 4 directly, without going through phases 1, 2, and 3: a very high bill, security issues, and systems going down frequently.
Going cloud-native takes niche skills juggling many moving parts without incurring a high bill. Remember, there is an entry barrier to cross, and it’s up to you to give your team the time and resources for it. You will need additional tooling for deployments, observability, management, and security. You don’t have to start from scratch if you use the B2B Accelerator+, with its Kubernetes accelerator to take you to market faster.
