Yesterday I sat for the AWS Solutions Architect Associate exam and passed! Thanks to the teams at A Cloud Guru and WhizLabs for the training.
So, all credit goes to Colm MacCárthaigh for this one. I think his recent post on Shuffle Sharding is so go it deserves a share and a place on my blog to serve as a reminder for me from time-to-time. This is one way AWS achieves the level of reliability and stability it has for its customers. Some of the methodology can easily be applied to traditional and on-prem infrastructure though as well.
Symptoms Website randomly goes down a few times a week Server stopped responding Network and CPU logs show a small spike, but not enough to lock up a server Stopping and starting the server resolves the problem Details This pattern repeated several weeks until the customer grew tired of rebooting the server. The evidence did not seem to lead to a system issue or network or security security problem such as a denial of service.
Other than the main character being a manager, it is amazing how close this book mirrors my career path so far. This is fiction, but does a good job introducing business and cloud concepts. I would definitely recommend this for anyone in IT. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim My rating: 3 of 5 stars A story that anyone from an IT operations background can relate to.
As I transition to working in “the cloud” more I am embracing the new technologies and methodologies. However, I’m also trying to replicate what I do in on-prem environments when it makes sense. One way I like to collect and analyze data is using NetFlow. NetFlow provides network conversation details at a higher and summarized level. This has led to quicker recovery time on numerous occasions, or avoided issues entirely.
I love packets and tracing issues at a micro level. However, like I stated in Preparing for the Capture you need to know where to capture before you can dig into the bits an bytes. In order to know where to capture you must understand your service/app/network. The best way to do that is to diagram your service.
Performance monitoring is two-fold. There is proactive performance monitoring and reactive investigation. The majority of my posts and case studies reflect the latter. This post is more related to the former. Services on premise typically rely on SLAs, NetFlow, scripts, synthetic transactions and more to provide monitoring and alerting. While some of this is possible in the cloud to keep track of specific pieces, you first need a good foundation by knowing if the underlying technology by your cloud provider is operating as expected.
My career has recently shifted directions. While I still have a passion for network performance and the apps that run on the network, my focus will be directed towards the cloud and the future of application performance. More specifically, I will be specializing in AWS technologies. To start that journey, I achieved the AWS Cloud Practitioner certification. I felt this certification was another test that was well done. It was a good entry level test, but still reinforced the knowledge Amazon feels you need.
- NEWER POSTS
- page 2 of 2