Originally posted to ORBIT - our weekly newsletter - back in December. Want content earlier? Sign up now!
As we get closer to the end of the year I’ve been spending time looking at the work we’ve done for customers and the most common questions we’ve received from students in our AWS training sessions. This week I decided to create a list of ‘Resolutions’ for 2019 when it comes to deploying (and/or supporting) solutions on the AWS platform.
The list below is in order of importance (from my perspective) and how we approach all the work we do for customers.
The most important thing you can do next year is to continue learning about the AWS platform. With a platform that is a dynamic as AWS - more than 1,400 changes last year - there is only one way to stay current - that is learning through building solutions on the platform.
At Curious Orbit, we have many ‘side-hustles’ on the go. We’re building automation, products, and services on an on-going basis. Will all these ‘side-hustles’ see the light of day? - probably not, but will we have learned about how to provide more cost-effective, reliable solutions to our customers? Absolutely.
I describe myself as a ‘continuous learner.’ I look for people to join Curious Orbit who are also continuous learners. It’s the only way to excel on this platform - learn more about it.
One last thing I’d like to say about learning - I don’t think learning means 9⁄9 certifications - get them if you would like to - it’s a great goal, but make sure you can back up those certifications (regardless of the number) with experience. Having a certification is only the first part of the puzzle.
We’ve talked about Infrastructure as Code and our chosen method of implementation - CloudFormation - many times on this blog throughout this year (and last). Without a solid everything as code approach, you’re missing out on one of the most powerful tools in your tool belt.
Infrastructure as Code - regardless of how you implement it or what tools you decide to use - allows you to deploy quickly, manage, and update AWS Infrastructure and services programmatically. By reducing all the things into ‘recipes’ and managing those recipes like code, you’re able to move faster, build more reliable solutions which (if done right) are more flexible and can be deployed in any of the AWS Regions available.
If you’d like to see an example of how we did this for Toyota Canada, make sure to check our their customer.
Every opportunity you get to remove manual effort from your AWS deployment is a clear win in my books. Just like my first resolution, automation it makes your solutions more reliable and allows you to scale more easily as your AWS footprint grows.
While I’m a huge fan of automation, I don’t believe you should automate just for the sake of automation. What do I mean by that?
Data Lifecycle Management (DLM) was recently released by AWS and acts as a fantastic example of where, when and how to automate. DLM makes creating (and managing) Elastic Block Store (EBS) volumes in your account easier - you define a policy, set a schedule and AWS takes care of the rest - by the was DLM is supported by CloudFormation.
Before DLM, if you wanted (and you should be) to snapshot your EBS volumes (natively), you had to create something yourself - which usually meant Lambda. DLM means creating something custom is no longer required.
Would I tell you to build a custom Lambda function for EBS snapshots today - no, my recommendation would be to use DLM. You get the benefits of automation, but you offload the work to AWS - that’s a fantastic outcome in my opinion.
What if you have a custom solution in place right now? If it’s just making simple snapshots - then I’d immediately replace it with DLM. If you have something complicated, my suggestion would be to keep it on life support until AWS releases the same (if not better) features - they are known to do that.
Don’t know where to start? Look at the tasks you perform regularly and see if AWS has an option - they did make more than 1,400 changes to the platform last year. If they do than leverage it - if they don’t then get building! You can build CLI scripts, create custom solutions using one of the AWS-provided APIs or build Lambda functions - it’s entirely up to you how you approach automation - just make sure you are actually automating tasks and not creating custom solutions if AWS already has something in place.
One of the early blog posts I created when I started Curious Orbit was about my feelings on Operating Systems. I stand behind those thoughts, and as the AWS platform continues to evolve, it’s becoming ever easier to avoid OS’ in many situations.
Here’s how we approach every engagement with our customers.
First, we take a serverless first approach. If we can build/deliver a solution to the customer using one of the many serverless offerings available on AWS today, we’ll do that first.
If serverless is not an option, then we’ll look at one of the many managed services offerings available and use a combination of those offerings to deliver the solution.
When we’ve explored all of our options, and nothing else is possible, we’ll relent and deploy EC2 instances. This still happens, especially when we’re helping customers migrate an existing solution to AWS, but we’re going to try our best to avoid EC2 at all costs.
Every time, we avoid creating yet another EC2 instance we can drive down the costs of our customer’s deployment and reduce the undifferentiated heavy lifting of managed OS’.
So there you have it, my list of ‘Resolutions’ for 2019 when it comes to deploying (and support) AWS Solutions.
I’d love to hear your list - just reply to this email and let me know what you think - what else should be on my list.
Like what you read? Why not subscribe to the weekly Orbit newsletter and get content before everyone else?