The benefits of working in the cloud – from improved productivity to reduced costs – are well known by enterprises. But maximising those advantages isn’t always simple.
Amazon Web Services (AWS), the subsidiary of the internet retail giant, knows a thing or two about getting the most from the cloud: The US firm accounts for almost half of the world’s public-cloud infrastructure and has “millions” of business customers around the world.
Speaking yesterday at AWS Transformation Day in London, UK, AWS’ head of enterprise strategy Philip Potloff outlined a four-part strategy for working smarter in the cloud.
“It typically starts because the enterprise or business has a new vision, a big vision: We’re going to become the ‘Amazon of something’,” he said during the AWS Transformation Day keynote.
“And that’s great, it’s good to have a big vision. The challenge begins when, in IT, we match that big vision with big execution. And we don’t figure out how to execute small.”
So, what should enterprises do to successfully execute their big cloud-based visions?
Break up the work
Much like any goal, breaking the whole into smaller, more manageable parts is essential.
“Breaking up the work is more than a technical shift to microservices if you have a monolithic architecture,” explained Potloff. “But actually it’s taking your software development lifecycle, your infrastructure provisioning process, and it’s breaking it up into smaller units where you can deliver value more frequently.”
In one example, Potloff said a bank claimed to have 66,000 application in their architecture, but a “good portion of them” had been abandoned.
This is common among businesses, said Potloff, which tends to result in businesses having to “start over” and build a new architecture.
“And that is much more work in the long run than actually just continuing to transform – even legacy mainframe applications.”
In the case of service directory Yelp, they had built up a lot of ‘technical debt’ – false economy in software development – and got to a point where they had incompatible architectures and multiple systems thrown together.
The State of Technology This Week
“They got to a point where they had a million lines of code, in a single monolith that was running not only their customer base, but also their businesses. And rather than taking the ‘execute big’ approach, they said, we’re actually going to execute small here.”
This involved “peeling off pieces of functionality one by one”.
So, what are the benefits of breaking up the work? According to Potloff, businesses can deliver “more value more frequently” and “reduce the blast radius for risk, because the amount of change is smaller”.
Invest in your workforce
The power of diverse perspectives and abilities in a team is crucial to solving big problems, whether it’s engineers, business leaders, developers – or rugby players.
According to former England captain Will Carling, a guest speaker at AWS Transformation Day, the key to getting the most from diverse teams is communication.
Whether it’s writing code or making tackles, there can be different levels of ability in the team. Communication is key in managing this, said Carling – even if that involves difficult conversations.
“I think lots of teams, and lots of leaders, avoid those uncomfortable conversations, uncomfortable meetings. I think when we avoid them, we give up the chance to be as good as we could be.”
Ensuring that the workforce is always equipped with the right skills for working with the cloud is also vital, with constant reskilling offering the benefit of being able to work with more agility.
Aligning teams around customer value, not systems, also puts businesses closer to customers, said AWS.
Carling added that instilling confidence in team members is important:
“You’ve got to make sure that that your players are confident. I think that’s something that we underestimate hugely as people. And rugby players are big physical specimens, but they’re riddled with the same insecurities that we all are. I used to spend probably 80% of my time building confidence. And I think that’s the same in the workplace.”
Automate your bureaucracy
Projects can often be held up by unnecessary layers of bureaucracy that bog down work. AWS said this can be solved by replacing this gatekeeping with automatic controls. The aim is to make the business lean and shorten time span from creating ideas to implementing them and reducing overall cycle time.
In short, it’s ensuring that finished means actually releasing the product.
“If you’re a leader, and you have a team that you expect to be releasing every iteration and they’re not, then either you as a leader or someone on your leadership team goes to every sprint [the time period for specific work to be done], every retrospective and expect a demo, something working in a deployed environment.
“And boy that changes things. Initially, teams hate you. Because they’re not focusing on new feature development. Instead, they’re working on the deployability and scalability of their applications.
“They’re automating the bureaucracy that exists that everyone ignores or hands off to someone at an integration phase. But boy, once they’ve actually tackled that particular issue and dealt with the deployability and scalability, teams move way faster.”
Build it in, don’t bolt it on
Finally, taking a security-first approach can prevent or limit the crippling damage that often comes with a cyberattack. The concept – also known as DevSecOps – means that security and compliance should be embedded into everything – not added as an afterthought at the end of the product lifecycle.
This involves ensuring security and reliability is everyone’s job.
Assuming attack and failures will happen can help businesses ensure their “blast radius” remains small when it does happen.
Businesses should also explore what happens in “diminished capacity scenarios” as a result of a cyberattack or technical failure.
Potloff gave the example of foreign exchange company Travelex. When it moved to the cloud, it added an extra level of security by deploying separate containers for storing financial money transfers.
“But every 24 hours, those containers were destroyed and replaced with new security credentials.
“So, if anything were to happen in that 24-hour period, the most impact it could have – their blast radius for risk – was within that 24 hour period.”
By taking a security-first stance, systems will be more flexible and resilient, added Potloff.