AWS has announced generally available Graviton (ARM) processors for serverless (cloud native) applications. For those of us implementing a serverless architecture, we now have the option of running our code on either Intel CPU’s, AMD CPUs or Graviton (ARM) CPUs. AWS estimates that running microservices on Graviton2 processors can deliver up to 19% better performance at a 20% lower cost and have a far lower execution time for workloads using multithreading and multiprocessing or that are Input/Output (I/O) intensive. Ultimately - lower execution time means lower costs. For larger serverless workloads you can also specify resources of up to 10GB of RAM and 6 processors (CPU’s).
This is great news, but what are the issues facing us if we’re planning to move to a Cloud Native environment and is this a simple process? To be honest - moving into the realm of ‘Cloud Native’ applications and the concepts and deployment processes associated with containerisation (Docker or Kubenetes) and Microservice Architecture is one fraught with issues.
The first concern a company faces is one of IT skills; Currently there is a limited pool of talented IT professionals who actually have the skills to deploy and maintain ‘Cloud Native’ applications (whether they be deployed as containers or as serverless infrastructure).
The second concern is one where the development teams have adopted containers for their Cloud Native applications but find that application performance is constrained by a lack of system resources which are inadequate for the demand. This issue stems from the lack of interoperability between development teams and the operations teams and poor communication channels. This problem can be mitigated to an extent by the development team relying on AWS Fargate to take care of the required underlying resources.
The third real concern is a financial issue; Traditionally, developers have deployed resources as and when required, without having either insight or oversight into associated costs. Thus, a company could receive a hefty (and unwelcome) surprise at the end of the month.
The fourth concern is one of microservice and container security; The traditional standards associated with implementing intrusion detection/prevention, configuring firewalls and network packet inspection was the purview of the network/operations teams. With the move to Cloud Native by the developer teams all these configurations and standards become more esoteric in nature.
As you can see, adopting a Cloud Native strategy is not an ‘overnight’ process, there are many considerations to consider (and not just the few I have highlighted above). SureSkills is an AWS Authorised Training Partner, and we can assist with the up-skilling of your teams.
If you’re serious about containers on AWS - you’d do well to take advantage of our course: “Running Containers on Amazon Elastic Kubernetes Service”.
To allay fears of cloud native adoption costs running wild – I can highly recommend the course: “Cloud Essentials for Business Leaders - Financial Services” (ref: https://d1.awsstatic.com/training-and-certification/classroom-training/aws-cloud-financial-management-for-builders.pdf)
And finally – if security is a concern (and it should be !) – then join us on the course: “Security Engineering on AWS” (ref: https://d1.awsstatic.com/training-and-certification/classroom-training/security-engineering-on-aws.pdf)
#AWS #SureSkills #Training #IT Skills #BeTomorrowReady
