AWS' managed cloud services lighten the load for IT
AWS continues to find ways to move up the stack and ease the burden on IT. Take advantage of these services to improve productivity, and stop worrying about low-level maintenance.
AWS largely reduces the maintenance of lower-level software. This frees developers and operations staff to focus on the specific parts of their business that make them unique, such as their UI, business logic and customer-facing apps.
AWS built its cloud infrastructure a dozen years ago to reduce organizational overhead. It identified hardware costs as a major pain point for IT organizations and responded with services such as EC2, Simple Queue Service and S3. Later, it ventured into functions as a service, which eliminated the need to manage OSes, load balancers and even databases. DevOps teams still need to manage Lambda usage, DynamoDB thresholds and links to services such as API Gateway, but overall, infrastructure management is a much simpler task.
Amazon also added tools to offload administrative tasks for those that don't want to go serverless. Ops teams don't need to patch AWS managed cloud services, such as Relational Database Service, Redshift and Elastic Container Service for Kubernetes. Instead, they set a preferred maintenance window, and AWS automatically does it. AWS handles common security vulnerabilities too, so there's no need for an operations crew to monitor security releases for things that are off-the-shelf and not built by the organization.
IT without AWS managed cloud services
Let's say you decide to build a small customer relationship management company without AWS managed cloud services. First, you would need to hire developers to build the system. Even if the code was hosted in a colocation facility with rented VMs, an ops team would need to look at patches to the OS, database and proxy wrapper. Chances are that team would use Apache or Nginx to proxy requests to the code that runs locally, so they'd need something like Chef or Ansible to manage software deployments across multiple VMs. That means yet another package to maintain, and the operations team would have to manage software to support themselves, as well as the developers that need to deploy a new package.
At a minimum, the deployment process would then require two to three additional people, as well as an on-call monitoring crew. The process would likely slow down since developers couldn't push to deploy code without a CI/CD system or monitors in place to verify the changes. The addition of a third-party CI/CD system, such as Jenkins, would create another potential spot for security issues or bug fixes and add another package to a growing list for ops teams.
At some point, you would be notified about a critical security update to the Linux OS, but it may not be safe to apply that update for your Jenkins build, MySQL instances and Apache front-end servers. Instead, you'd have to manually patch and test half the fleet of each instance type before the full changes are rolled out. If something breaks, you'd have to quickly revert and work to find a solution. All of a sudden, an operations team could spend an entire week on a simple bug fix.
Meanwhile, there could be a disclosure about a critical security bug with Npm, which would leave your application vulnerable. Someone could inject arbitrary code into your front-end application by hacking the code repository for RxJS, which your application includes in every single page. Your user login page would then become exposed, and customer information sent to a third-party site. As a result, customers' critical details could be left unprotected, and it could be weeks before anyone notices because the ops team is distracted with a bug that could have been handled entirely by AWS.
Free your team to find application-specific issues
AWS delivers its products to users through a shared responsibility model that delineates who is responsible for what, and customers that use the managed services have to do fewer of these administrative tasks. Of course, IT teams aren't entirely free of responsibilities if they put more of the onus on AWS, as they still need to address security and any other issues that pertain to their applications and data that sits on top of these services.
But without AWS managed cloud services, your operations team has to work harder. Instead of panic and mayhem whenever a new OS vulnerability is detected, my team focuses on other things that may have been impacted. We use tools like Snyk to monitor security issues with our code. And while we still need to worry about scaling, we can plan ahead and click a few buttons to increase capacity in DynamoDB or set up automated rules to automatically scale the platform. If we come up against a hard limit in our AWS account -- such as concurrent AWS Lambda invocations -- we call up AWS support to increase our quotas.
Some IT professionals will argue against the use of AWS managed cloud services, but they're mostly being stubborn. The one scenario where this might make sense is if an organization wants to run entirely on multiple clouds. But that can be incredibly costly, and even then, it's really only an architecture they want rather than one they need. Amazon's uptime history is far better than any other system out there, even Gmail, so it's crazy to think your team can do better. And while my team does use some third-party tools, they're all managed services. My point is this: Unless you're handling all the software maintenance just to prove you can do it, it's best to leave it to the professionals that do that sort of thing for a living.
