The previous articles of the ‘Innovating with MACH’ series looked at how business capabilities should determine microservices and the business value of being truly API-first. This brings us to how companies are modernizing through cloud-native technologies. Of course, you would have heard plenty of jargon, but in this article, we’ll try to focus on how you use the cloud and not on the cloud services themselves.
What is Cloud-Native Development?
Cloud-native development is agile, behavior-driven development, using cloud services in whichever way that makes sense organizationally and culturally to get you to wherever you need to go. I refer to 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 organization. Try to get into a mode of “Business-impact first” thinking – because today’s technology virtually 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 organization’s background processes and future plans. You need to keep the end-user’s point of view and the customer experience in mind. The key is to get answers to what you want to achieve and how the business will move forward. This ensures that the cloud-native implementation supports the strategic goals of the organization.
3 Key Business Benefits of Becoming Cloud-Native
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. Often, we see that having Kubernetes at the core is already 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 is not going to happen overnight. This needs sweeping change at every level, where you challenge IT and 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 on your way to becoming 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, standardized 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 here 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 set of 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, 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. In the next installment of the ‘MACH Powered Innovation’ series, we’ll take a look at the business benefits of headless architectures.
Author
Daniel Mueller
Senior Solutions Architect
