• Rael Winters, Product Manager at DevOpsGroup


• 15.04.2019 09:30 am
undisclosed

The FinTech cloud race is in full swing, but the million-dollar question for many is ‘how cloud-native should we go?’.

The answer is not straightforward. And it’s further complicated by the fact that nearly everyone you talk to has a different idea about what cloud-native means. Some people believe it’s all about containers and cross-platform portability, but that excludes serverless approaches. Others assume any application purpose-built for the cloud is inherently cloud-native. But what if it fails to fully exploit the platform’s functionality?

Perhaps pinning a definition on cloud-native is just too simplistic and restrictive. I recently came across a book, Cloud Native Architectures, which considers cloud-native as an evolving state. The authors outline a Cloud Native Maturity Model with three axes, which essentially equate to: ‘application design’, ‘infrastructure design and automation’ and ‘the extent to which you embrace cloud vendor services (with associated vendor lock-in)’. Each of these elements has the capacity to develop over time, and to a large extent, they can do so independently of the others. The model neatly accommodates the continual improvement and scalability that are so intrinsic to cloud environments.

This seems like a sensible way to position cloud-native. And it sets a useful framework to address the ‘how cloud-native should we go?’ conundrum.

The perfectionist trap

If you’re considering cloud-native in the context of a cloud migration, the chances are you’ve already tested the water with a few built-in-the-cloud applications. Developers have probably seized the opportunity to leverage modern ways of working, implementing serverless functions and infrastructure as code. They’ll have taken time to develop new skills and get to grips with new technologies.

But ultimately, time is the limiting factor in a migration. When you reach that tipping point and decide to go all-in, there simply isn’t enough time to make everything perfect. If you try to rearchitect the bulk of the estate in one swoop, you’ll end up missing deadlines and blowing the budget. The scale and complexity of the task makes an immediate 100% cloud-native transition unattainable for most.

The happy compromise

‘Done is better than perfect’ is one of the maxims of the moment in digital business. Far from becoming hackneyed, it has enduring relevance, especially in relation to cloud migration and modern business operations.  

In most scenarios, it’s best to develop a medium to long term cloud-native strategy that ensures applications have the capacity, capability and scalability to improve over time. Within this framework, you can work tactically to progress towards an ever-maturing cloud-native state.

For some parts of your application or estate it will make sense to go-big on the cloud-native spectrum sooner rather than later. If they’re close to the core value stream, facilitating better ways of working might deliver major commercial benefits or competitive advantage. Sometimes, relatively straightforward rearchitecting can lead to significant cost-efficiencies. It’s worth expending developer time and effort on priming these applications, because value and return on investment will be quickly realised.

However, when it comes to an all-in migration with more established applications, it’s usually prudent to evolve most of the estate in a simpler, more gradual way. That means taking small steps towards modernisation without going for the full cloud-native treatment.

Often this approach starts with infrastructure-led methods which don’t involve changes to application architecture or user features. Applications might be containerised with Docker or Kubernetes or there could be a shift to PaaS options like Azure Web Apps or AWS’s Elastic Beanstalk. You might even stick with classic VMs, but use an ‘everything-as-code’ approach to redeploy applications into freshly defined, immutable infrastructure.

Some developer input will be needed to keep everything working well in the new environment. But they’ll tinker with the application code to improve reliability, operability and costs, not rearchitect or undertake significant recoding. This enables the existing codebase to be reused in the cloud environment, bypassing the need to dramatically reskill developer teams or adopt new languages or frameworks. However, you do need to be wary of missing features in PaaS offerings and potential vendor lock-in when you use advanced features.

Technology is only half the story

Being cloud-native is about more than technology. A key finding from the most recent Accelerate: State of DevOps report was that the way your product or development teams can access and use cloud services matters far more than any technology choices. There’s a clear predictive link between teams that can embrace all five of the essential characteristics of cloud computing (originally defined by the National Institute of Standards and Technology back in 2011) and organisational growth, profitability and market share. Simply running systems in the cloud is not enough in itself to unlock all the associated benefits. And cultural factors can be a major constraint blocking modern ways of working.

Take ‘on-demand self-service’, one of these essential characteristics. Many teams are blocked from embracing this by well-intentioned but legacy ways of working. Infrastructure and operations teams are often still accountable for spend, security and standards, but don’t have the tooling to govern them in an open, self-service model. So, product teams have to raise tickets to get access to resources, and rapid elasticity is inhibited because operability isn’t considered at the design stage. In this scenario, a platform can scale, but applications often can’t, because they weren’t built with this in mind.

These are surprisingly complex problems to unpick and the root cause is often the project-based funding models that are so engrained in many businesses. But they can be solved. With the on-demand self-service example, a shift in focus from control to curation can help, with operations teams providing safety nets and guardrails rather than barriers and constraints. 

A journey, not a destination

Going cloud-native is the surest way to unlock all the benefits associated with cloud-based platforms, from cost-efficiency to faster throughput. All these things are critical to business success in the digital economy. But for most organisations, it’s not feasible to do it all at once. We’ve developed a whitepaper ‘Focus on the how for large-scale cloud migration success’. It’s free to download and looks at the different paths and considerations to unlock the benefits of cloud.

When you’re developing a cloud strategy, remember two things: cloud-native is a continuum and resources are finite. You need to acknowledge that your work will never be done, but take pride in the fact that you’re continually working towards an enhanced cloud-native state.