What level of transformation do you need to put in place to adopt cloud native? What will it mean for your developers, budget, skills, etc.?
What level of transformation do you need to put in place to adopt cloud native? What will it mean for your developers, budget, skills, etc.? It is questions like these that shape the approach a company might take to cloud-native adoption. If they have minimal cloud-native experience, they must also consider what kind of provider they need to work with as they rapidly kick-start their cloud-native journey with a low CapEx.
Our report ‘Cloud native comes of age’ reveals that, although a small number of ‘leader’ firms already develop at least 20% of their new applications in the cloud (and 43% on average), for the majority, the cloud-native journey is only just getting under way. It will require a new mindset and, clearly, a new development approach with new skills. At Sogeti, we help our customers understand how to embed a culture of agile in the application lifecycle and what its impact on their Minimal Viable Product (MVP) will be.
Release fast, release often
In a cloud-native sprint-based scenario, your developers are thinking fast, releasing at speed, and the whole rhythm of the project is the opposite of traditional waterfall project methodology. It’s a very different world to what they are used to and when asked to compare several types of challenges in adopting cloud native, the respondents to our ‘Cloud native comes of age’ survey rated skills as the most significant, cited by 70%, closely followed by cultural issues. People have to unlearn how they’ve previously worked and they mustn’t be afraid to fail.
Designing with failure in mind might appear to be a strange way to think about infrastructure, but with cloud native everyone has to understand the concept of ‘fail fast’, whereby it’s far quicker and cheaper to fix containerized functionality than to begin the entire development process again in waterfall mode. And we’re talking about just days or weeks, as opposed to a traditional six-month waterfall development cycle.
That’s because cloud-native development is about frequent small releases of new software functionalities and new services, as opposed to the waterfall model of discrete design, build, and run phases lasting a few months or more, before culminating in a product release of the entire unit of software. Essentially, features such as microservices and containerization within a cloud-native development model mean that application failures are much easier to contain and fix.
The value of fail fast
This fail fast thinking sits at the heart of cloud native, but it can be difficult to adjust to. That’s one of the reasons why we run workshops with our clients to demonstrate the value of accepting a higher tolerance of failure. We use these workshops to show our clients what it means to be agile, to look at the technology, and to better understand the set-up of a cloud-native team and the need for collaborative working between developers, architects and IT operations.
We have also developed a DevOps simulation game in partnership with GamingWorks and often use this approach to help our clients experiment with the concepts of agile and cloud native in a DevOps environment. In it they simulate a cloud-native application journey, in which they start with a business challenge, consider what apps might help to solve it, work through the DevOps process, organize workloads and assign roles, understand new behavioral requirements, identify small iterations (MVP, prioritization), and address any barriers to launch. It’s a great way to explore cloud native in the context of a DevOps delivery model and its impact on a company’s ways of working and speed-to-market.
Recover quickly in a cloud-native mode
Finally, I am interested in what one of the contributors to the ‘Cloud native comes of age’ report has to say on this subject. A leading light in the world of cloud native, Matt Stine is a principal architect at US-based software and services company Pivotal. He asserts that cloud-native leaders encourage failure, saying: “Instead of trying to prevent mistakes, they optimize for the ability to respond, around a metric of mean time to recovery. If we can recover from anything very quickly, then it doesn’t really matter if we fail.”
Like me, Matt is clearly an advocate of accepting failure as part of the continuous cloud-native development cycle. With the ability to change a single microservice within a new app or service, organizations can scale quickly, whilst rapidly containing and addressing failures, and this reduces their technology and business risk.
A compelling business case
The impact on a company’s bottom line can be significant, as our ‘Cloud native comes of age’ report reveals. Of the ‘leader’ group – those that are the most mature in their adoption of cloud native – 84% report that moving to cloud native has helped them to both increase revenue and reduce development and operating costs. Need I say more?
To find out more or arrange a workshop, please contact Clemens Reijnen.