![\"\"](\"https:\/\/companies.mybroadband.co.za\/bbd\/files\/2023\/05\/Media-Image-2.png\")
<\/p>\n<\/p>\n
Cloud, cloud and more cloud. It\u2019s everywhere. Still. Businesses in all sectors around the globe have jumped on the bandwagon; applications, infrastructure and services have been migrated and we\u2019re only surprised when something isn\u2019t available remotely.<\/p>\n
It\u2019s not new, it\u2019s not the latest ground-breaking technology, and it\u2019s not even really a buzz word anymore… Because it\u2019s expected to be a part of an organisation\u2019s digital strategy.<\/p>\n
So why are we still talking about the cloud? Well, as they say, success lies in the detail. And your cloud\u2019s efficacy needs refinement.<\/p>\n
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%).<\/p>\n
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.<\/p>\n
This is a seemingly worrisome trend: as software engineers get more comfortable with the technology, more organisations are saying that they\u2019re losing money to their cloud. That doesn\u2019t add up\u2026<\/p>\n
But what if it\u2019s 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?<\/p>\n
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\u2019s kind of what it\u2019s like when you deploy applications in the cloud without making sure you\u2019ve set yourself up to win, and that\u2019s where cloud native development comes in.<\/p>\n
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.<\/p>\n
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.<\/p>\n
\u201cWhen you design specifically for the cloud, you\u2019re not only reaping those benefits,\u201d explains Werner de Jager, managed cloud services executive at international software solutions provider, BBD, \u201cyou\u2019re ultimately feeding back a better user experience for your customers\u201d.<\/p>\n
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.<\/p>\n
\u201cI\u2019ve found that oftentimes people think that just because they\u2019ve moved their infrastructure from one machine to another in the cloud that they\u2019re going to save costs. But that\u2019s not always true. Moving to the cloud isn\u2019t 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\u201d explains Xavier. Ultimately, you need to know where you\u2019re going before you start. \u201cBeing on the cloud isn\u2019t the finish line, it\u2019s 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.\u201d<\/p>\n
Xavier\u2019s second point is that you can\u2019t 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. \u201cAt BBD, we\u2019ve found the reality is that many of our clients don\u2019t have the required skillsets in their current, inhouse team for cloud native development. And that\u2019s why it\u2019s so advantageous to have a partner possessing those technical expertise who comes in and assists, working with the client to grow their skills.<\/p>\n
\u201cIt may seem daunting,\u201d remarks De Jager, \u201cbut the truth is that it\u2019s good practice to not try and do everything all at once\u201d. \u201cExactly, 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\u2019s a journey, and setting achievable milestones is the right way to go\u201d 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%. \u201cDeciding 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.\u201d<\/p>\n
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. \u201cIt needed new user features and wasn\u2019t cloud native so after rewriting it we ended up halving the operating costs of the application.\u201d It\u2019s one small example he goes on to say, but if every application results in lower operating costs, there\u2019s more resources to channel into innovation and high-value work for your team.<\/p>\n
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. \u201cWhat is sometimes undervalued however\u201d mentions De Jager, \u201cis 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\u2019t automatically equate to cost savings. \u00a0Modernisation 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.<\/p>\n
Another misconception on the topic of modernisation is the idea that \u201cmodernised\u201d means \u201cserverless\u201d or \u201cmicroservices\u201d but this too isn\u2019t 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\u2019t be modernised to work optimally in the cloud environment they run on. \u201cThere is a sweet spot in migration and modernisation that needs to be found for each workload. There\u2019s no such thing as a universal solution to modernise.\u201d<\/p>\n
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 \u201cthey 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.\u201d In turn, this becomes an added layer of trust that a potential client can have in a cloud enabler holding a cloud-related competency. \u201cIt\u2019s 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.\u201d<\/p>\n
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:<\/p>\n
To sum up, De Jager says that 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. \u201cTo help, we\u2019d like to extend an offer to companies in the market who have migrated and are looking to modernise and optimise their environments with a free 30-minute consultation with our cloud experts.\u201d<\/p>\n