Cloud, cloud and more cloud. It’s everywhere. Still.
Businesses in all sectors around the globe have jumped on the bandwagon; applications, infrastructure and services have been migrated and we’re only surprised when something isn’t available remotely.
It’s not new, it’s not the latest ground-breaking technology, and it’s not even really a buzzword anymore… Because it’s expected to be a part of an organisation’s digital strategy.
So why are we still talking about the cloud? Well, as they say, success lies in the detail. And your cloud’s efficiency needs refinement.
It’s not all sunshine and roses
In 2019 Accenture reported that 40% of businesses surveyed said their cloud initiatives failed to deliver the expected business value, citing complexity and cost as the top reasons. A year later, Deloitte found 40% of businesses surveyed cited data migration and integration as the top challenge in cloud adoption, followed by security (38%) and governance and compliance (36%).
In 2021, Forrester found that 40% of IT leaders said that their organisations had experienced challenges with cloud cost management, with 37% exceeding their cloud budget in the past year, and in a report from Flexera in the same year 76% of surveyed businesses said they had wasted money on unused cloud resources. Actually, 35% of respondents estimated a wastage of at least $100,000 per year.
This is a seemingly worrisome trend: as software engineers get more comfortable with the technology, more organisations are saying that they’re losing money to their cloud. That doesn’t add up…
But what if it’s not a trend, and rather an indication that in the rush to get to the cloud, not enough attention was paid to the intricacies of the set up?
And that’s where the devil lies, in the detail
Have you ever swum in jeans? They weigh you down, tire you out and cause you to exert way more energy than you should. Could you win a race in those jeans when your competitors are suitably attired? Probably not. That’s kind of what it’s like when you deploy applications in the cloud without making sure you’ve set yourself up to win, and that’s where cloud native development comes in.
Cloud native development is the process of building applications specifically for the cloud, taking advantage of cloud infrastructure, platforms and services to better enable elastic scalability, reliability and performance. These work together for more efficient and effective applications in the long run. Importantly, the benefits of cloud native development include cost-efficiency as by optimising resource utilisation and leveraging those cloud-based services, you can reduce your costs, helping to negate the $100,000 wastage those organisations experienced in the Flexera report.
The official definition by the Cloud Native Computing Foundation mentions that cloud native technologies empower organisations to build and run scalable applications in modern, dynamic environments using the likes of containers, service meshes, microservices, immutable infrastructure and declarative APIs. What this all means though is that by using those technologies, the result is loosely coupled systems that are resilient, manageable, observable and, when combined with automation, allow engineers to make high-impact changes frequently, predictably and with minimal toil.
“When you design specifically for the cloud, you’re not only reaping those benefits,” explains Werner de Jager, managed cloud services executive at BBD, “you’re ultimately feeding back a better user experience for your customers”.
David Xavier, solutions architect at BBD agrees with these points but adds that achieving them in practice is only successful when you understand four key points.
What are these points?
“I’ve found that oftentimes people think that just because they’ve moved their infrastructure from one machine to another in the cloud that they’re going to save costs. But that’s not always true. Moving to the cloud isn’t like swapping insurances for a cheaper rate. You have to make the necessary changes to leverage off of the new environment and the benefits it offers” explains Xavier. Ultimately, you need to know where you’re going before you start. “Being on the cloud isn’t the finish line, it’s the start of a journey to scalability, increased efficiency and reduced costs. To get there, leveraging cloud native development and well architected applications can be steppingstones taking you in the right direction.”
Xavier’s second point is that you can’t really achieve cloud native by lifting and shifting to the cloud, you need to rewrite. And for that, comes point three: to meet the finish line and harness the benefits and cost-savings of the cloud, you need the skills to properly architect and design for the cloud. “At BBD, we’ve found the reality is that many of our clients don’t have the required skillsets in their current, inhouse team for cloud native development. And that’s why it’s so advantageous to have a partner possessing those technical expertise who comes in and assists, working with the client to grow their skills.
“It may seem daunting,” remarks De Jager, “but the truth is that it’s good practice to not try and do everything all at once”. “Exactly, my fourth point is that you can set your end goal to be that 100% of your applications and platforms are cloud native, but it’s a journey, and setting achievable milestones is the right way to go” says Xavier. An example is to set your three-year strategy to include being 100% cloud native, but within that, at the end of Year 1, aim for 30%. “Deciding whether you tackle the easiest to rewrite, the most critical, or the ones costing you the most in unnecessary resources depends on a number of factors as well as your current architecture.”
Demonstrating the truth of his points in a recent project, Xavier tells of a UK-based global financial management body who had lifted and shifted their application to an EC2 server in the cloud before engaging BBD. “It needed new user features and wasn’t cloud native so after rewriting it we ended up halving the operating costs of the application.” It’s one small example he goes on to say, but if every application results in lower operating costs, there’s more resources to channel into innovation and high-value work for your team.
Does cloud native mean modernised?
As the rate of technical advancement spurs forward on a seemingly daily basis, modernisation is now critical for businesses looking to take advantage of the efficiencies modern technology, systems and methodologies have to offer. “What is sometimes undervalued however” mentions De Jager, “is that migration and modernisation in the cloud are two separate things. On the one hand, migration is more typically a lift and shift project, and as Xavier mentioned, doesn’t automatically equate to cost savings. Modernisation on the other hand can involve rewriting applications as cloud native or rearchitecting infrastructures to better take advantage of the cost and efficacy benefits you can reap.
Another misconception on the topic of modernisation is the idea that “modernised” means “serverless” or “microservices” but this too isn’t always the case. Some workloads work better in a monolithic architecture. This was definitely the case for Amazon Prime when they recently moved from a distributed microservices architecture to a monolithic one, reducing their infrastructure costs by over 90% in the process! This does not mean however that workloads can’t be modernised to work optimally in the cloud environment they run on. “There is a sweet spot in migration and modernisation that needs to be found for each workload. There’s no such thing as a universal solution to modernise.”
This plays directly into the idea of utilising cloud engineers who have the right skillsets in place. One way of sourcing these partners is to rely on the vetting that the cloud providers such as AWS do. De Jager explains that in his experience hyperscalers like AWS are very selective in awarding these competencies, explaining that “they are very thorough in ensuring that businesses like BBD are highly skilled and have delivered strong solutions in the scope of the competency in question.” In turn, this becomes an added layer of trust that a potential client can have in a cloud enabler holding a cloud-related competency. “It’s important to remember though that not all migration partners are modernisation partners, an important consideration when deciding on how best to start your cloud native journey.”
The big question
So why are we still talking about the cloud? Because at the end of the day, it can bring enormous benefit to organisations and their bottom lines, but only when you focus on the detail. Remember:
- Know where you’re going before you start – the cloud isn’t the goal, leveraging the cloud for scalability, increased efficiency or reduced costs is. And cloud native development may be the path you need to take to get there
- Lifting and shifting does not equal being cloud native
- Not all modernisation means “serverless” or “microservices”
- Every workload in every organisation has its own sweet spot
- Partner with a cloud enablement partner who has the required skillsets
- It’s a journey – set achievable milestones
To sum up, BBD is very aware that not all clients have the ability to modernise in-house, and that the nuances involved in sustainably gaining the benefits the cloud has to offer can be tricky to achieve in practice.
