Our top four takeaways from AWS Re:Invent
In early December, the Las Vegas Strip was awash with over 60,000 technology professionals for AWS’ Re:Invent showcase event.
IT strategists, engineers, modern platform leads, enterprise architects and CIOs attended over 3,000 presentations (mostly led by AWS partners and customers) as well as meeting other customers that utilize AWS services.
Virtual Clarity was in attendance; we have whittled down our extensive learnings into four key areas:
1. Complexity, Abstraction and Cost:
AWS’ catalog of service offerings continues to grow, bringing with it an ever-increasing depth and level of complexity. In turn, the choices and consequences one has to consider when building a cloud environment also become more complex and far reaching. Whereas building an AWS environment was, in reality, rather more straightforward than building an on-premises environment (due to the limited options), for many enterprises, an AWS environment built from scratch today can be a very complex thing indeed.
There are a couple of particular consequences
- The skills needed to plan, build and manage an enterprise AWS environment are getting more diverse and specialized, making it unlikely to find a single person with all the required expertise
- Proactive management of cost, in a cloudy world, with ever more chargeable moving parts, is also becoming truly difficult
AWS has recognized this to some extent and is accelerating the delivery of managed services that abstract away from the underlying components (think Lightsail, Fargate, Sagemaker, etc.). Remember though that this abstraction also reduces the ‘tuneability’ of environments.
2. Solution Architectures:
Containers were a hot topic at this year’s event, particularly Kubernetes. AWS has definitely recognized that the debate is done, and Kubernetes has become the de-facto winner of the container orchestration game. AWS ECS continues to exist and be developed, but for how long?
Attendees were encouraged to think about using what AWS are calling ‘modern applications’, which are:
- structured as microservices
- making use of serverless services such as Aurora and Lambda for scalability and low cost
- decoupling abstractions using message queues
- using appropriate data storage and manipulation to fit each specific workload use case
These new lightly-coupled architectures encourage simple abstractions that are easy to develop and test. These are being promoted by all the CSPs, but they are also binding customers to specific cloud providers as they make ever greater use of proprietary services and APIs.
Machine learning was also being pushed hard by AWS. In addition to announcements in core technology (including optimized inference hardware), the focus now is on improving the developer experience e.g. SageMaker Studio is being promoted as the first integrated development environment for machine learning. AWS is fighting hard to build mindshare over Google in the machine learning and data science spaces.
Notably, AWS Outposts are now a reality and signal that AWS has finally acknowledged the demand for hybrid environments (and also the commercial sense in extending the use of AWS services into legacy data centers). Unlike Google Cloud’s Anthos, Outposts are fully managed by AWS.
People don’t tend to think of AWS as being in the hardware business, but of course it is – AWS has long designed its own data center hardware to enable it to build a manageable and cost-effective cloud platform. Increasingly, however, it is making and evolving proprietary hardware directly usable by customers (“Inferentia” chips for machine learning, “Graviton” ARM processors, etc).
Ultimately, these advances are about enabling workload efficiency – whether that is the ability to significantly increase performance at the same cost (highly relevant for machine learning training), or to shrink costs through license optimization (e.g. some of these are very relevant for COTS applications that charge on a per-core basis, meaning licensing costs can be more than halved by a switch to a specific compute service).
4. Learning from others:
As usage of cloud services is now very much mainstream, and is extending even into traditionally conservative industries such as financial services, it is becoming rather easier to find others who have faced similar challenges to your own organization and to learn from them rather than repeating their mistakes. Some of the key general lessons we see (and have been through ourselves) are:
- Be clear about why you are moving to cloud - Finding out that the solution your engineers have built for you won’t actually deliver the value you need is not a good thing for any project
- Make sure that someone owns the overall solution - ‘Too many cooks’ generally results in either a lack of timely decisions or conflicting ones, neither of which is helpful
- It may be ‘cloud’, but it isn’t magic - Engineers need time to deal with the emerging complexity
- ‘Agile’ does not mean “no requirements” - Many organizations are making use of modern cloud platforms as part of a shift to becoming more responsive; too many, however, don’t grasp that speed comes from doing things better rather than from just not doing things