I’m a Lead Cloud Architect within Atos’ OneCloud practice, spending most of my time working with customers on large cloud projects — migrations, build outs of Landing Zones, new deployments of applications. In addition to my day job I’m passionate about supporting people to help them improve their skills, be it people who are fresh out of education, those part way through their careers looking to reskill or people already working in the cloud who want to further their knowledge. To that end in my ‘spare’ time I’ve set-up an AWS focussed community interested in training, certification and working with AWS technologies with our customers, our Atos AWS Coaching Hub.
I’m keen this community doesn’t use certification as the end of the journey, it’s merely the beginning. Within a GSI / MSP organisation it can be difficult for staff to feel confident having only completed some courses and taken certifications to start working on customer projects. I saw this diagram on LinkedIn the other day which I think sums it up fairly well: -
So as well as providing support to each other on assignments I’ve used the AWS Coaching Hub to arrange hands on training where people can get in-depth on AWS services.
Immersion Days are available across a range of topics and at a range of difficulty / experience levels, and these can be delivered by either AWS or AWS Partner Network Partners. Atos are one such partner who can help deliver these with AWS for customers, but equally being a broad community of 100,000+ employees we also have people within our own organisation who benefit from participating in them.
In the past we’ve run a few ad-hoc immersion days as well as gamedays, for 2022 I wanted to curate a more role focussed agenda of events to help encourage people to group around sessions that would support their job role (Architect, Administrator, Developer, Migration Engineer) and prioritise the training time they have available. Each one started with the General Immersion Day, and our migration engineer track continued this week with the Migration Immersion Day, complementing the self-study on platforms like ACloudGuru and certifications that the individuals are undertaking.
We started with some theory talking about making the case for change, doing assessments and creating high level TCO, focussing on the AWS tools and services for doing this. Third party tools can also be used for helping with this, such as the excellent Cloudamize assessment tool from Cloudreach.
We discussed Landing Zones, after all once your project is ‘in flight’, just like a plane, it’s going to need somewhere to land! From an AWS perspective a landing zone is a multi-account architecture to provide separation of concerns / duties across security, logging, networking, billing and such like, then with resource accounts where your workloads are hosted. There’s often debate around how to separate resource accounts, and all good consultants will give you the ‘it depends’ answer, but most of the time I see things split by environment, application, security posture or a combination of these factors. We covered the importance of security within the landing zone, as well as the shared responsibility model, which describes what AWS are responsible for and what you, or your partner(s) are responsible for (diagram below is based on IaaS, AWS take additional responsibility ‘up the stack’ for PaaS and serverless services). Building a landing zone in the past was typically a $250k+ professional services engagement lasting months, but many accelerators exist now. AWS themselves have a Landing Zone as a Service offering, AWS Control Tower, and whilst the foundation of that product are good (SSO, guardrails, config rules, logging) are there, it lacks many services required for enterprise scale customers (VPCs connecting to a Transit Gateway, GuardDuty, Security Hub, CICD for deployment etc.). Atos have created an accelerator to reduce the cost and time to value for Landing Zones, our Digital Cloud Services product , which you can read about on the AWS APN blog.
We covered the importance of people and the new skills required to take advantaged of the amazing technology the AWS cloud brings. Many projects can hit the buffers without the appropriate skills being in place, a problem that’s only be exacerbated by the talent crisis as companies struggle to hire new talent and retain existing talent. Our AWS Coaching Hub is fostering our existing staff to upskill, reskill and get the support needed to become hands on. Cloudreach have launched, in collaboration with AWS, a Talent Academy to address this shortage and nurture candidates from a diverse range of backgrounds to become the next generation of cloud talent, whether starting out, or retraining from another industry. We discussed a few different models of set-up from central Cloud CoE with a more ‘command and control’ type set-up, to delegated authority to business units. In my experience most customers undergoing this organisational transformation start with a central function that sets standards as well as ‘does the doing’ initially, whilst the landing zone is build, pilot applications are migrated etc. Then at some point this team cannot cope with demand and needs to become more of a standards and advisory group, as well as retain the base landing zone, financial management and security services, nurturing and allowing application teams / business units to innovate and iterate to deliver more business value without hitting the buffers because the Cloud CoE can’t cope with demand.
We discussed migration approaches, including AWS MGN for ‘lift and shift’ migrations. This product was an acquisition that’s been rolled into the AWS Console, and was previously known as CloudEndure, something I’ve personally used to move an extremely large customer’s SAP estate in the past.
We then moved on to Database Migration Service (DMS) for both homogenous and heterogenous migrations, and the Schema Conversion Tool (SCT) for heterogenous migrations.
We did some enjoyable labs, if you wanted to attempt them yourselves you can find an overview here. Firstly assessing the ‘on prem’ estate: -
We installed agents on the Linux hosts to install the discover agent: -
curl -o ./aws-discovery-agent.tar.gz https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz
tar -xzf aws-discovery-agent.tar.gz
sudo bash install -r “us-west-2” -k “<AWS key id>” -s “<AWS key secret>”
Once the data collectors were reporting in we were able to see data, visualise and then manipulate the data in Athena to learn about the environment we were discovering.
We then used the AWS MGN service (previously a separate product, Cloud Endure, for those familiar, which has been rolled into the AWS Console) to ‘lift and shift’ the servers into the cloud.
We ended up with a successfully migrated application!
We then migrated the database from running on EC2 on the migrated servers to running in Aurora using DMS
A successfully migrated database to Aurora backing the Wordpress site: -
