Why geographically-distributed SRE teams?
In today’s hyper-connected technological world, there is a need for geographically widespread technical teams to facilitate global growth. Businesses that scale to this level need global teams to handle that reach. However, as development teams continue to ramp, it quickly becomes infeasible for them to solve operational problems while also scaling the product. That’s where SREs, whose primary job is to develop software to solve operational problems, come in. Investing in geographically-distributed (GD) SRE teams is key to achieve the goal of scaling a business or product to a global audience.
In part one of this series, we discussed some of the key principles to consider when developing geographically distributed (GD) SRE teams. Similar to the first article, we’re leveraging the journey of LinkedIn’s SRE team as the point of reference for the topics discussed here in part two. Within this post, we’ll discuss growth planning, the challenges associated with being part of a remote team, and some of the unexpected advantages geographically distributed SRE teams can offer.
There are many articles out there about being an effective remote worker. Most of them focus on the basics, like building the ideal home office, following strategies for effective video conferencing, managing cabin fever, avoiding becoming a remote developer black box or improving self-discipline, motivation and communication.
But where do you go from there? People often ask me that. Julia Evans at Stripe has done a great job writing about this, and I’d like to give you my take as well.
In ES5 your solution is
_.extend(target, [sources]) from Lodash (or any alternative), and ES2015 introduces
Luckily object spread syntax (an ECMASript proposal at stage 3) is a step forward how to manipulate objects, providing a short and easy to follow syntax.
Node.js 8.10 runtime now available in AWS Lambda
The Lambda programming model for Node.js 8.10 now supports defining a function handler using the async/await pattern.
Asynchronous or non-blocking calls are an inherent and important part of applications, as user and human interfaces are asynchronous by nature. If you decide to have a coffee with a friend, you usually order the coffee then start or continue a conversation with your friend while the coffee is getting ready. You don’t wait for the coffee to be ready before you start talking. These activities are asynchronous, because you can start one and then move to the next without waiting for completion. Otherwise, you’d delay (or block) the start of the next activity.
Asynchronous calls used to be handled in Node.js using callbacks. That presented problems when they were nested within other callbacks in multiple levels, making the code difficult to maintain and understand.
Promises were implemented to try to solve issues caused by “callback hell.” They allow asynchronous operations to call their own methods and handle what happens when a call is successful or when it fails. As your requirements become more complicated, even promises become harder to work with and may still end up complicating your code.
Async/await is the new way of handling asynchronous operations in Node.js, and makes for simpler, easier, and cleaner code for non-blocking calls. It still uses promises but a callback is returned directly from the asynchronous function, just as if it were a synchronous blocking function.
Node 8 support for AWS Lambda is here!
If you’re a serverless developer on Lambda, read on for what you need to know about Node 8. Namely: speed, Async/Await, object rest and spread, and NPX.