Blog article category for blog articles on this site covering the areas of DevOps, Cloud Infrastructure, Site Reliability, Technical Writing, Project Management and Commerical Writing along with Event Management and associated areas. 

Image of the journey so far for Maolte extracted from the About page

Maolte Technical Solutions Limited Launch

The next evolution of Maolte is here...

It gives me great pleasure to finally announce the launch of Maolte Technical Solutions Limited trading as Maolte. As part of the Maolte journey, this launch is not only the next logical step to take, it is also a platform for what I think service provision in these areas should be like. It is in essence passion fusing with purpose in the provision of full stack Cloud Infrastructure, Site Reliability, DevOps, Project Management and Writing Services. 

Our service offering is based on solving your technology challenges alongside the fulfilment of your writing needs to bring you a complete solution-based offering. What we do can be broken down into the following areas:

  • DevOps
    • CICD deployments and support
    • Working practices and CICD design 
  • Cloud Infrastructure 
    • Cloud production support and site reliability
    • Technical root cause analysis and major incident management
    • Design and implementation of cloud monitoring solutions
    • Cloud workflow process design 
    • Technical project management and troubleshooting
    • Infrastructure programming and automation
  • Writing 
    • Technical writing for customer-facing document repositories
    • Technical document repository design and implementation against the DITA standard
    • Internal technical documentation and repository design for runbooks and how-to documents 

Whilst a short blog, the milestone is huge as is our desire and ability to provide solutions for your needs. I would be remiss if I did not mention my 4+ years in the cloud industry after I qualified as an engineer supplemented by 15 years in financial operations. 12 of those years are as a first and second-line leader with about 5 years of direct project management experience. My deep learning curve over these 12 years give me very useful perspectives on project leadership, which I implemented successfully on many occasions reaching this point. 

We never know what the future brings, but what is clear is that passion fusing with purpose automatically upgrades the level of quality and care that you would receive as a client. All we need is your challenges and requirements to complete the conversational agenda in your free first consult. Stay tuned for more on infrastructure in this blog along with articles on other areas of interest in the writing and DevOps arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!

Image of AWS Solutions Architect Associate Certificate of John Mulhall

AWS Solutions Architect Associate Certification

The SAA-C02 Journey to certification spells well for AWS's technical future

After completing the SAA-C02 Solutions Architect Associate exam, I can say AWS's technical future is bright once they keep on building upon quality and relevance in their certification programmes. This certification is been replaced by the SAA-C03 Solutions Architect Associate exam in September of this year, which will expand on the massive expansion of AWS services since the SAA-C02 certification was launched. 

If I have the future of Maolte Technical Solutions Limited correctly forecasted in the month of its incorporation, it's my feeling that cloud architecture and associated certifications will strongly feature in my new company's 5-year road map. I have a number of certifications completed at this stage and on this one, I can say that tricky questions are featured in a comprehensive set of areas covered for this exam. My own SAA-C02 journey has yielded the below comments and tips designed to assist the engineer or technologist preparing to certify in this exam. After completing all 65 questions with 12 mins to spare in the 140-minute exam, I completed 2/2 of one incomplete question and reviewed 9/20 flagged questions making one adjustment. I passed with 804/1000 showing me that time management and not topic knowledge was my biggest issue here despite my fragmented focus on preparation this time around. This experience has produced the following list of tips I hope any exam preparer will benefit from.

  • Cover the course content in detail and take notes you can revise pre-doing the practice exams on your preferred vendor's mock exam subscription. Use exam prep tools like AWS Benchmark, which will definitely help.

  • Redo the course labs a few times, which admittedly I did not have time for. I was stuck in between setting up my own company and doing the course

  • Try to have a continuous learning cycle moving through the course in 2-3 day gaps at a max revising the last day's content before covering new content. I had gaps of weeks between leaving my perm job to set up my own company and starting a new course for a contract pitch. This led me to suspend work mid-way on this one which did NOT help at all. Fresh memory linking all the content together is a better idea.

  • When you complete the course content and have your mock exams lined up, try to give yourself about 2 weeks of practice exams having 3-5 days between takes and follow up on what you get wrong to make sure you understand ALL your answers. I normally do that but gave myself 4 days for this part of the exam prep due to time pressures, which was unhelpful in the exam.

  • If people start distracting you on other work tasks, etc within 48 hours of your exam date; just go dark and focus on the exam. I did not and ended up working 12-hour days to cover all the tasks coming out of the woodwork thus going into the exam tired.

  • In the exam, I was nervous and flagged questions I knew but noted nerves prevented me from focusing properly on them. I flagged 6 questions like this and then clicked into gear until around question 34 when I became mentally tired. I tried stretching but should have taken a 30-second meditation to try and refresh myself and then flag as few questions as I needed to throughout the remaining exam. Instead, I hard-charged onwards and flagged 20 questions overall. The questions and answers got wordy so mistakes may have been made and I only had time to review 9/20 flagged questions. Time management is critical to success and the overall exam experience. 

The SAA-C03 from this September on will be similarly structured but on a wider range of AWS services, making the above tips valid in your pursuit of this certification. There is no doubt in my mind, that these exams make us better AWS engineers, admins and architects so why not move on your certification path today! Stay tuned for more on infrastructure in this blog along with articles on other areas of interest in the writing and DevOps arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!

AWS Resource Access Manager

AWS Resource Access Manager

Why Infrastructure Resource Sharing is not always a good idea...

One of the more recent service offerings that have confused some former colleagues of mine is AWS Resource Access Manager, also known as AWS RAM. After looking into it, I think the benefits do make life easier in sharing resources around Transit Gateway, App Registries, CodeBuild, Licence Manager plus more.

Whilst sharing EC2 Image Builder (no more Packer if you don't want it), or AWS Glue features for data projects can only be added to the list of amazing graces AWS has offered us via AWS RAM, there are aspects to AWS RAM that should come with a 'handle with care' sign on them. Anybody who copied AMIs (Amazon Machine Image) over regions will tell you it's a multistage snapshotting job that can be tedious when the number of AMIs is substantial. AWS RAM is your friend and you can share cross-region, cross-account components, AMIs, and more allowing access and not replication to solve your resource needs. The granular detail is also shared with AWS Glue shares where Data Catalogs and meta sharing can be done in the same manner allowing a Glue object to be shared no matter if it's a catalog, database or table. After finishing a data project recently, I can only salute the usefulness of this feature when thinking about design and how tables in particular are shared between regions and accounts. Embraced fully, the architecture on data mesh projects can get a real shot in the arm from AWS RAM in the management of project resources in development all the way to production. 

Looking through the services list, I came to a grinding halt at subnets. The sharing of subnets for some reason has been seen as a good idea to allow multi-region/account sharing using AWS Organizations. It can allow a subnet on account 1 (dev) to be shared with account 2 (prod) once there are no prohibiting Service Control Policies (SCPs) at the AWS Organizations account level. Imagine the scenario, you deploy EC2 instances in the subnet in account 1 (dev) and have deployed a database to the shared subnet in account 2 (prod) for reasons that should be considered very bad practice. With AWS RAM, it's possible. Whilst viewing the account 1 (dev) subnet, you cannot see the database in account 2 (prod). If you log into one of those dev EC2 instances in account 1 (dev) subnet, you can ping the database in account 2 (prod) and bypass all subnet access control rules, VPC controls, etc that you may have configured for your production database. This is an example of why AWS RAM should be handled with due care and caution. 

Don't get me wrong, overall I think it's a great idea from AWS and certainly worth exploring when you are looking at horizontals like Datamesh projects for example that greatly benefit from AWS RAM. Like all things new and great, handling them with care is always a good idea and prevents those gotchya moments that often overtake us when we least expect it. Stay tuned for more on infrastructure in this blog along with articles on other areas of interest in the writing and DevOps arenas. To not miss out on any updates on my availability, tips on related areas or anything of interest to all, sign up for one of my newsletters in the footer of any page on Maolte. I look forward to us becoming pen pals!