This morning I read a very interesting article by Jeff Knupp entitled “How DevOps is Killing the Developer”. In it, Jeff argues that developers are at the top of the technical expertise chain (having the most niche, specific expertise), and as such shouldn’t be distracted spending time doing “DevOps” (or indeed QA, sysadmin, database admin, and so on), which he claims require less specific expertise.
On Tuesday, our Developer Experience Engineer, Chris Alexander, took an in-depth look at services available on the AWS cloud, so I made sure to tag along to watch the big show. The event was hosted at Skills Matter alongside the meetup group LJC: London Java Community. The audience of around 100 people were treated to an evening of: Details of using AWS to scale, and tips and tricks based around infrastructure and platform as a service. #LoveLearning.
The concept of breaking companies and teams into smaller groups in order to progress with units of work relatively independently is by no means a new concept. Even with its recent growth in popularity as a way of scaling teams, Amazon have done it for years, and 3M have been at it for decades.
Nowadays, flat-hierarchy organisation structures are all the rage, especially in the Valley. The concept is appealing for a number of reasons: the right people on the right jobs, the promise of easy scaling of the business as it grows, and work happening closer to the customer to name but a few.
As soon as you begin working on a software project that exceeds a few lines of code, managing changes rapidly becomes trickier. To counter this, developers use version control systems to track changes to folders and files.
These systems typically work by tracking changes to files as individual “commits” of work, which then allow you to build up a file’s current state by looking at its initial state, then the series of changes (or commits) that have affected it since then.
Keeping Your Server Clocks Synced EC2 servers are started in sync with the VM host’s clock. They are also configured to use the OS’s standard time servers – for Amazon Linux AMIs, these are *.amazon.pool.ntp.org, and for Ubuntu it’s *.ubuntu.pool.ntp.org. This is great if your server is on “classic” EC2…
Last week, Amazon launched the ability to turn on per-request logging in Elastic Load Balancers (ELBs). This is a much sought-after feature that many users have been asking about for some time now, and finally it is here.
However, logging is only half of the battle. Once you have the logs you have to do something with them in order to be able to figure out if there are any problems that need addressing or improvements that can be made.
Our current Python client library is quite complex and can be tricky to get your head around; the good news is that soon we will be bringing out version 2, which is much easier to use and comes with much more help content.
While we are putting the final touches on the new version, I want to take a few moments to talk about some of the core concepts of the client library.
Last week I took to our tech blog to outline how we went about implementation for our just-launched Social Sign-in feature. In it, I spoke about a number of implementation issues that came about with the use of OAuth 2. For example:
“…once you have the OAuth 2 access token, all of the [federated auth] services offer completely different APIs for getting hold of data about the user. For this, in the end, we resorted to writing custom implementations for each provider.”
Here at import·io we are heavy users (and big fans) of Amazon CloudFormation. Since we first shipped to production we have used CloudFormation to manage an entire stack of resources which constitute a single instance of the import·io platform.
Since then we have expanded our resources and tooling to make further use of these templates, such as provisioning staging environments and so on.
Yesterday, Google launched a rather unusual new project called DevArt. In conjunction with the Barbican, Google is leveraging the creativity of developers to build some fantastic art, which will be exhibited at the Barbican along with the work of some commissioned artists in their Digital Revolution exhibition.