Hey I'm Lou! I'm a Cloud Native Software Engineer From London. I created The Dev Coach to make it easier for Software Engineers to get into Cloud Native. I also publish the Cloud Native Software Engineering Newsletter to try and keep you as up-to-date as possible. When I'm not writing you can usually find me picking up heavy things and putting them down, or riding two wheels (sometimes with an engine, sometimes not).
Yesterday, as I read an article on DEV, titled: “forget web development, become a cloud developer instead!” I punched the air: yes! The author, Moneer, put into words something I’d been talking about for some time, but never wrote down.
Getting a job in web development isn’t getting easier. The bootcamp factories churn out graduates and the entry-level market is saturated. Add to this that the web development world hasn’t moved much recently, so there’s no hot tech to leverage. But that’s where cloud tech presents an amazing opportunity.
By the end of this article you’ll understand why learning cloud skills is the unique opportunity which will separate you from other graduates and ultimately land you a job.
What is good, friends! We are back with another issue of the Cloud Native Software Engineering Newsletter. Today we’ll be taking a look back over August and the latter parts of July 2020. Sound good? Let’s jump to it…
When it comes to operating Lambda, we often want to configure alarms to alert us when things aren’t running smoothly. Naturally our first choice for Lambda alarms is CloudWatch, the default monitoring service that comes with AWS.
CloudWatch gives us some custom metrics out-of-the-box, such as: errors and invocation rates. But there are some problems we run into when setting up alarms based directly on these metrics.
By the end of this article you’ll understand why alarms based on default AWS Lambda Metrics can cause difficulty, how AWS Metric Math helps us to apply “context” in our alarms and make them more effective, and how to setup an alarm using metric math to calculate an error rate percentage.
It’s that time again, to go through another month of cloud news, topics and interesting articles. So grab yourself a coffee (or whatever), and let’s dig in.
To begin I must note that this months newsletter is a little behind schedule. Tardiness is definitely not something I will be making a habit from. That being said, the world is in an odd place right now and I’m definitely not the only one feeling the impacts.
However, the silver lining of the delay is that this months newsletter is packed with curious happenings, of which I’m quite excited to share. The newsletter this month is a real mixed bag, from high profile outages up to new communities popping up.
Error handling can be a confusing topic — for a long time I struggled to understand error handling myself. I found the whole topic quite mystical and daunting. I ended up subscribed to the school of thought: “let the error throw and pray”. But, over time, I learned there are simple, easy to understand strategies for error handling that lead to noticeably better results than hope alone!
By the end of the article you’ll understand how to structure an application to handle errors effectively, achieve more understanding of the application, deliver better error messages and have an easier time debugging.
Recently I find myself in the position of applying monitoring to existing software applications quite often. Whilst I have been applying the monitoring tools, I noticed that I follow the same steps each time…
Which got me thinking: “Could you create a ‘recipe’ or ‘cookbook’ for how to apply monitoring to an existing software application?”. I set to work writing this article, and I can conclude, the answer is: yes!
By the end of this article you’ll know the 5 steps you should take when setting up monitoring on an existing service.
Are you creating a lambda function? Are you currently debugging wondering where you can access the output of your console.log entries?
Understanding how logs work is a common confusion area when working with AWS Lambda. Today, we’re going to clear up the confusion and get your hands on your AWS Lambda logs so that you can start to debug your Lambda function.
By the end of this article you’ll understand how and where console.log output goes from an AWS Lambda function, and also how to debug your AWS Lambda setup if you’re still not seeing log output.
This past month I’ve given the website a new lick of CSS paint. That’s a new body new font and a simpler white design. Let me know what you think! And in other news this month I started officially writing up reader questions, and writing up cloud book summaries (more on both of these later on). But now it’s time to take a look through the happenings of May 2020 within the cloud world.
1 Sentence Summary: Building Microservices allows us the opportunity to tackle software complexity and deliver faster; if (and it’s a big if) we build our services right: choosing the right tech, interfaces and integration patterns.
Microservices are a way of breaking down applications into their parts so that businesses can deliver the components separately, experiment with distinct technology stacks and create clear boundaries between business logic.
But building microservices isn’t easy an easy task. With microservices you need to consider many things, such as: how (and where) you split the services, how they talk to each other (integration) and what data they share.
It’s in-vogue at the moment to debate on the virtues of Microservices vs. Monoliths. But ultimately they’re just two different architectural patterns that solve different use cases. Ideally you should understand both patterns.